< draft-osterweil-dane-ipsec-02.txt   draft-osterweil-dane-ipsec-03.txt >
DANE E. Osterweil DANE E. Osterweil
Internet-Draft G. Wiley Internet-Draft G. Wiley
Intended status: Standards Track T. Okubo Intended status: Standards Track T. Okubo
Expires: September 25, 2015 R. Lavu Expires: January 7, 2016 R. Lavu
A. Mohaisen A. Mohaisen
VeriSign, Inc. VeriSign, Inc.
March 24, 2015 July 6, 2015
Opportunistic Encryption with DANE Semantics and IPsec: IPSECA Opportunistic Encryption with DANE Semantics and IPsec: IPSECA
draft-osterweil-dane-ipsec-02 draft-osterweil-dane-ipsec-03
Abstract Abstract
The query/response transactions of the Domain Name System (DNS) can This document defines a new Domain Name System (DNS) resource record
disclose valuable meta-data about the online activities of DNS' type called the IPSECA RR that is used to associate an X.509
users. The DNS Security Extensions (DNSSEC) provide object-level certificate or a public key to an Internet Protocol Security (IPsec)
security, but do not attempt to secure the DNS transaction itself. gateway in a similar manner TLSA RR is used in the DNS-based
For example, DNSSEC does not protect against information leakage, and Authentication of Named Entities (DANE) protocol does that for
only protects DNS data until the last validating recursive resolver. Transport Layer Security (TLS) in order to make the credential
Stub resolvers are vulnerable to adversaries in the network between discovery easier through DNS and to allow credential discovery to be
themselves and their validating resolver ("the last mile"). This performed in a secure manner leveraging DNS Security Extensions
document details a new DANE-like DNS Resource Record (RR) type called (DNSSEC). Among the issues addressed in this draft is the danger of
IPSECA, and explains how to use it to bootstrap DNS transactions IP address spoofing that can be a liability to IPsec endpoints. It
through informing entries in IPsec Security Policy Databases (SPDs) is important to note that the "right destination" in this document is
and to subsequently verifying Security Associations (SAs) for OE strictly defined by the response of the DNS and does not attest to
IPsec tunnels. the identity of the organization or the ownership of the IP address
space. The identity of the organization shall be attested in an
X.509 certificate issued by a certification authority if desired and
the ownership of the IP address space shall be attested by other
mechanisms such as Towards A Secure Routing System (TASRS)
architecture or Resource Public Key Infrastructure (RPKI).
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 7, 2016.
This Internet-Draft will expire on September 25, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. What IPSECA Adds to DNSSEC Transactions . . . . . . . . . 4 1.1. What IPSECA Adds to DNSSEC Transactions . . . . . . . . . 5
1.2. IP-Centric IPsec Tunnel Discovery Using IPSECKEY . . . . . 4 1.2. IP-Centric IPsec Tunnel Discovery Using IPSECKEY . . . . . 6
1.3. Service-Centric IPsec Tunnel Discovery Using IPSECA 1.3. Service-Centric IPsec Tunnel Discovery Using IPSECA
and DANE . . . . . . . . . . . . . . . . . . . . . . . . . 5 and DANE . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. The IPSECA Resource Record . . . . . . . . . . . . . . . . . . 6 2. The IPSECA Resource Record . . . . . . . . . . . . . . . . . . 8
2.1. IPSECA RDATA Wire Format . . . . . . . . . . . . . . . . . 7 2.1. IPSECA RDATA Wire Format . . . . . . . . . . . . . . . . . 8
2.1.1. The Usage Field . . . . . . . . . . . . . . . . . . . 7 2.1.1. The Usage Field . . . . . . . . . . . . . . . . . . . 8
2.1.2. The Selector Field . . . . . . . . . . . . . . . . . . 7 2.1.2. The Selector Field . . . . . . . . . . . . . . . . . . 9
2.1.3. The Matching Field . . . . . . . . . . . . . . . . . . 8 2.1.3. The Matching Field . . . . . . . . . . . . . . . . . . 9
2.1.4. The Certificate Assocation Data Field . . . . . . . . 8 2.1.4. The Certificate Association Data Field . . . . . . . . 9
2.2. IPSECA RR Presentation Format . . . . . . . . . . . . . . 9 2.2. IPSECA RR Presentation Format . . . . . . . . . . . . . . 10
2.3. Domain Names used for IPSEC Records . . . . . . . . . . . 9 2.3. Domain Names used for IPSEC Records . . . . . . . . . . . 10
2.4. IPSECA RR Examples . . . . . . . . . . . . . . . . . . . . 9 2.4. IPSECA RR Examples . . . . . . . . . . . . . . . . . . . . 10
2.4.1. OE to a DNS Name Server Example . . . . . . . . . . . 9 2.4.1. OE to a DNS Name Server Example . . . . . . . . . . . 11
3. Operational Considerations . . . . . . . . . . . . . . . . . . 11 3. Operational Considerations . . . . . . . . . . . . . . . . . . 12
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5.1. Interactions . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Interactions . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Last Mile Security Analysis . . . . . . . . . . . . . . . 12 5.2. Last Mile Security Analysis . . . . . . . . . . . . . . . 14
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . . 14 7.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Name Server OE Configuration Example . . . . . . . . 15 Appendix A. Name Server OE Configuration Example . . . . . . . . 17
Appendix B. Recursive Resolver OE Configuration Example . . . . . 16 Appendix B. Recursive Resolver OE Configuration Example . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
The query/response transactions of the Domain Name System (DNS) This document defines a new Domain Name System (DNS) [RFC1035]
[RFC1035] can disclose valuable meta-data about the online activities resource record type called the IPSECA RR that is used to associate
of DNS' users. The DNS Security Extensions' (DNSSEC's) [RFC4033], an X.509 certificate or a public key to an Internet Protocol Security
[RFC4034], [RFC4035] core services (integrity, source authenticity, (IPsec) gateway in a similar manner TLSA RR is used in the DNS-based
and secure denial of existence) are designed to secure data in DNS Authentication of Named Entities (DANE) protocol [RFC6698] does that
transactions by providing object-level security, but do not attempt for Transport Layer Security (TLS) [RFC5248]
to secure the DNS transaction itself. For example, DNSSEC does not
attempt to protect the confidentiality of DNS transactions, does not
protect data outside of the RRsets (including the DNS header, OPT
record, etc.), and its DNS-specific protections expose opportunities
for adversaries to identify DNS traffic, eavesdrop on DNS messages,
and target DNS and its meta-data for attacks. As a result, a clever
adversary may target just DNS traffic, discover the nature of a
user's online browsing (from fully qualified domain names), interfere
with the delivery of specific messages (though the DNS objects are
not forgeable), or even attack "the last mile," between a resolver
and a remote validating recursive resolver.
For example, the information leakage exposed by observing DNSSEC The benefit of associating an X.509 certificate or a public key to an
transactions, could enable an adversary to not only learn what Second IPsec gateway is twofold. One is to make the credential discovery
Level Domains (SLDs) a user is querying (such as their bank, a easier through DNS: a protocol that is widely adopted throughout the
funding agency, a security contractor, etc.), but could also inspect Internet and mechanism that is publicly available. The other is to
the fully qualified domain name(s) to learn the specific hosts allow credential discovery to be performed in a secure manner
visited, or in the case of certain DNS-based chat programs, leveraging DNS Security Extensions (DNSSEC) [RFC4033], [RFC4034],
information about ongoing conversations. [RFC4035]. DNSSEC protects the authenticity and integrity of the
signed DNS response, which plays an instrumental role in assuring
that the gateway is connecting to the right destination and is using
the the appropriate Internet Key Exchange Protocol Version 2 (IKEv2)
[RFC5996] credentials to establish the tunnel.
In addition, DNSSEC's design only protects DNS data until the last It is important to note that the "right destination" in this document
validating recursive resolver. If a client issues DNS queries from a is strictly defined by the response of the DNS and does not attest to
stub resolver to a remote DNSSEC-aware resolver, then the network the identity of the organization or the ownership of the IP address
between these two ("the last mile") can be leveraged by an adversary space. The identity of the organization shall be attested in a X.509
to spoof responses, drop traffic, etc. certificate issued by a certification authority if desired and the
ownership of the IP address space shall be attested by other
mechanisms such as Towards A Secure Routing System (TASRS) [TASRS]
architecture or Resource Public Key Infrastructure (RPKI) [RFC6810].
Clearly, these limitations do not invalidate the benefits of DNSSEC. In addition to the fact that the combination of DNS and DNSSEC will
DNSSEC still protects the actual DNS objects, protects against cache provide a secure and robust foundation for IPsec to perform
poisoning attacks, and more. Rather, these limitations simply opportunistic encryption, it also provides an alternative for those
illustrate that there is more at stake than just valid DNS data. who wish to deploy opportunistic encryption for IPsec but have
difficulty getting the sub-delegation for the reverse DNS. By
removing the obstacle, this mechanism will allow more entities to
effectively and efficiently enable opportunistic encryption for their
IPsec facilities. In other words, IPSECA RR will maximize the "Fax
Effect" for IPsec opportunistic encryption.
This document details the motivation for, the synergy from, and a This document details the motivation for, the synergy from, and a
protocol to advertise and verify security credentials that can be protocol to advertise and verify security credentials that can be
used to verify Opportunistic Encryption (OE) IPsec [RFC4301], used to verify Opportunistic Encryption (OE) IPsec [RFC4301],
[RFC6071] tunnels for DNS transactions. Securing DNS transactions in [RFC6071] tunnels for DNS transactions. Securing DNS transactions in
this way is both necessary and sufficient for providing this way is both necessary and sufficient for providing
confidentiality of many types of DNS-transaction meta data, which can confidentiality of many types of DNS-transaction meta data, which can
betray user privacy. This document details a new DANE-like [RFC6698] betray user privacy. This document details a new DANE-like [RFC6698]
DNS Resource Record (RR) type called IPSECA, and explains how to use DNS Resource Record (RR) type called IPSECA, and explains how to use
it to bootstrap entries in IPsec Security Policy Databases (SPDs) and it to bootstrap entries in IPsec Security Policy Databases (SPDs) and
skipping to change at page 4, line 24 skipping to change at page 5, line 25
services that are running on the same IP address. This can become services that are running on the same IP address. This can become
complicated if certificates are learned solely by the IP addresses of complicated if certificates are learned solely by the IP addresses of
networked-services. This gap is inherently overcome during networked-services. This gap is inherently overcome during
certificate discovery in DANE protocols by the concept of "Service certificate discovery in DANE protocols by the concept of "Service
Address Records," [I-D.draft-ogud-dane-vocabulary]. These Security Address Records," [I-D.draft-ogud-dane-vocabulary]. These Security
Associations are defined by, and discovered by, domain names rather Associations are defined by, and discovered by, domain names rather
than just IP addresses. [RFC6698] standardizes a way for security than just IP addresses. [RFC6698] standardizes a way for security
associations of certificates to be made with service domains for TLS, associations of certificates to be made with service domains for TLS,
rather than just IP addresses. As one of the underlying facilities rather than just IP addresses. As one of the underlying facilities
of DANE's approach to certificate verification, this adds a necessary of DANE's approach to certificate verification, this adds a necessary
enhancement to IPsec certificate learning over approaches that are enhancement to certificate learning in IPsec, over approaches that
based solely on IP addresses in DNS (such as described in [RFC4025] are based solely on IP addresses in DNS (such as described in
and [RFC4322]). [RFC4025] and [RFC4322]).
The advantages of using DANE for IPsec OE also include other The advantages of using DANE for IPsec OE also include other
simplifications that the DANE protocol inherently offers all of its simplifications that the DANE protocol inherently offers all of its
protocols. Such as, the automatic deauthorization of certificates protocols. Such as, the automatic de-authorization of certificates
that happens when they are removed from a DNS zone, which may (under that happens when they are removed from a DNS zone, which may (under
many circumstances) obviate the need for extensive use of revocation many circumstances) obviate the need for extensive use of revocation
mechanisms (OCSP [RFC6960] or CRL [RFC5280]). Details of these mechanisms (OCSP [RFC6960] or CRL [RFC5280]). Details of these
relative trade offs is described in more detail in [DANE_SATIN12]. relative trade offs is described in more detail in [DANE_SATIN12].
Once a certificate is learned from DANE, it should be periodically
rechecked, but without out-of-band maintenance, the association will
remain valid until its X.509 signature (if certain Usage Types that
include PKIX validation are used) expires.
It is also noteworthy that DANE offers flexibility that is not It is also noteworthy that DANE offers flexibility that is not
available in IP-centric certificate discovery and IP-centric OE available in IP-centric certificate discovery and IP-centric OE
[RFC4322], while still being backwards compatible with them. That [RFC4322], while still being backwards compatible with them. That
is, while users can use IPSECA records to map OE IPsec tunnels to is, while users can use IPSECA records to map OE IPsec tunnels to
service names, they can also use IPSECA records in their reverse DNS service names, they can also use IPSECA records in their reverse DNS
zone in a similar fashion to the IPSECKEY [RFC4025] record used in zone in a similar fashion to the IPSECKEY [RFC4025] record used in
[RFC4322]. However, while this document illustrates an example usage [RFC4322]. However, while this document illustrates an example usage
of DANE with IPsec OE, any specification for how the IPSECA resource of DANE with IPsec OE, any specification for how the IPSECA resource
record MUST get used with OE is beyond the scope of this document. record MUST get used with OE is beyond the scope of this document.
skipping to change at page 5, line 28 skipping to change at page 6, line 35
customers are almost certainly not allowed to annotate the reverse customers are almost certainly not allowed to annotate the reverse
DNS zone for their providers. DNS zone for their providers.
1.3. Service-Centric IPsec Tunnel Discovery Using IPSECA and DANE 1.3. Service-Centric IPsec Tunnel Discovery Using IPSECA and DANE
The suggested usage of this document is to aid in discovering where The suggested usage of this document is to aid in discovering where
OE IPsec tunnels exist, and to act as an out of band verification OE IPsec tunnels exist, and to act as an out of band verification
substrate that can validate the certificates received during IPsec substrate that can validate the certificates received during IPsec
key exchange. For example, if a DNS caching recursive resolver is key exchange. For example, if a DNS caching recursive resolver is
configured to attempt OE IPsec tunnels to DNS name servers (using a configured to attempt OE IPsec tunnels to DNS name servers (using a
specific key exchange protocol, like [RFC2409], [RFC5996], etc.), specific key exchange protocol, like [RFC5996], etc.), then when it
then when it receives a referral it SHOULD query name servers for receives a referral it SHOULD query name servers for corresponding
corresponding IPSECA resource records. (we discuss the format of the IPSECA resource records. (we discuss the format of the resource
resource record and domain names below in Section 2). When an IPSECA record and domain names below in Section 2). When an IPSECA record
record is discovered by a resolver, that resolver SHOULD follow its is discovered by a resolver, that resolver SHOULD follow its
configurations and setup an SPD entry, in order to signal its IPsec configurations and setup an SPD entry, in order to signal its IPsec
layer to attempt to attempt to establish an SA. Note, this document layer to attempt to attempt to establish an SA. Note, this document
does not specify a new, or any modifications to any existing, IPsec does not specify a new, or any modifications to any existing, IPsec
key exchange protocols. Rather, after adding an SPD and after a key exchange protocols. Rather, after adding an SPD and a successful
successful tunnel establishment, the credentials used for the tunnel establishment, the credentials used for the Security
Security Association with the name server SHOULD be cross-checked Association with the name server SHOULD be cross-checked with the
with the IPSECA resource record(s). IPSECA resource record(s).
We note that simply adding PAD entries with the IPSECA keys and
identifying them with IP addresses so that the traditional IPSEC
implementations work would result in several security issues. In
particular, each zone answering a forward A and IPSEC lookups could
give their keys for an arbitrary IP address that they are bound to,
allowing to intercept some else's tunnel. To address this issue, we
require that a resource certification mechanisms (such as Towards A
Secure Routing System (TASRS) [TASRS] architecture or Resource Public
Key Infrastructure (RPKI) [RFC6810]) be used. In particular, a
verifiable certification of the association of a resource with an A
record would limit the ability of an adversary from publishing such
answers to an IPSEC lookup. We note that this does not only address
this security issue, but also marginalizes other issues associated
with the many-to-one mapping from DNS domain names to IP addresses.
When using IPSECA resource records to verify OE tunnels, clients MUST When using IPSECA resource records to verify OE tunnels, clients MUST
perform full DNSSEC validation of the DNSSEC chain of trust that perform full DNSSEC validation of the DNSSEC chain of trust that
leads to IPSECA RRs. As specified in [RFC6698]: leads to IPSECA RRs. As specified in [RFC6698]:
"A [IPSECA] RRSet whose DNSSEC validation state is secure MUST be "A [IPSECA] RRSet whose DNSSEC validation state is secure MUST be
used as a certificate association for [IPsec] unless a local used as a certificate association for [IPsec] unless a local
policy would prohibit the use of the specific certificate policy would prohibit the use of the specific certificate
association in the secure TLSA RRSet. association in the secure TLSA RRSet.
skipping to change at page 7, line 23 skipping to change at page 8, line 33
/ Certificate Association Data / / Certificate Association Data /
/ / / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
Figure 1 Figure 1
2.1.1. The Usage Field 2.1.1. The Usage Field
The meaning, semantics, and interpretation of the Usage field of the The meaning, semantics, and interpretation of the Usage field of the
IPSECA resource record follow the specification described in Section IPSECA resource record follow the specification described in Section
2.1 of [I.D.draft-ietf-dane-registry-acronyms]: 2.1 of [RFC7218]:
+-------+----------+--------------------------------+-----------+ +-------+----------+--------------------------------+-----------+
| Value | Acronym | Short Description | Reference | | Value | Acronym | Short Description | Reference |
+-------+----------+--------------------------------+-----------+ +-------+----------+--------------------------------+-----------+
| 0 | PKIX-TA | CA constraint | [RFC6698] | | 0 | PKIX-TA | CA constraint | [RFC6698] |
| 1 | PKIX-EE | Service certificate constraint | [RFC6698] | | 1 | PKIX-EE | Service certificate constraint | [RFC6698] |
| 2 | DANE-TA | Trust anchor assertion | [RFC6698] | | 2 | DANE-TA | Trust anchor assertion | [RFC6698] |
| 3 | DANE-EE | Domain-issued certificate | [RFC6698] | | 3 | DANE-EE | Domain-issued certificate | [RFC6698] |
| 4-254 | | Unassigned | | | 4-254 | | Unassigned | |
| 255 | PrivCert | Reserved for Private Use | [RFC6698] | | 255 | PrivCert | Reserved for Private Use | [RFC6698] |
+-------+----------+--------------------------------+-----------+ +-------+----------+--------------------------------+-----------+
Table 1: TLSA Certificate Usages Table 1: TLSA Certificate Usages
2.1.2. The Selector Field 2.1.2. The Selector Field
The meaning, semantics, and interpretation of the Selector field of The meaning, semantics, and interpretation of the Selector field of
the IPSECA resource record follow the specification described in the IPSECA resource record follow the specification described in
Section 2.2 of [I.D.draft-ietf-dane-registry-acronyms]: Section 2.2 of [RFC7218]:
+-------+---------+--------------------------+-----------+ +-------+---------+--------------------------+-----------+
| Value | Acronym | Short Description | Reference | | Value | Acronym | Short Description | Reference |
+-------+---------+--------------------------+-----------+ +-------+---------+--------------------------+-----------+
| 0 | Cert | Full certificate | [RFC6698] | | 0 | Cert | Full certificate | [RFC6698] |
| 1 | SPKI | SubjectPublicKeyInfo | [RFC6698] | | 1 | SPKI | SubjectPublicKeyInfo | [RFC6698] |
| 2 | DANE-TA | Trust anchor assertion | [RFC6698] | | 2-254 | | Unassigned | |
| 3-254 | | Unassigned | |
| 255 | PrivSel | Reserved for Private Use | [RFC6698] | | 255 | PrivSel | Reserved for Private Use | [RFC6698] |
+-------+---------+--------------------------+-----------+ +-------+---------+--------------------------+-----------+
Table 2: TLSA Selectors Table 2: TLSA Selectors
2.1.3. The Matching Field 2.1.3. The Matching Field
The meaning, semantics, and interpretation of the Matching field of The meaning, semantics, and interpretation of the Matching field of
the IPSECA resource record follow the specification described in the IPSECA resource record follow the specification described in
Section 2.3 of [I.D.draft-ietf-dane-registry-acronyms]: Section 2.3 of [RFC7218]:
+-------+-----------+--------------------------+-----------+ +-------+-----------+--------------------------+-----------+
| Value | Acronym | Short Description | Reference | | Value | Acronym | Short Description | Reference |
+-------+-----------+--------------------------+-----------+ +-------+-----------+--------------------------+-----------+
| 0 | Full | No hash used | [RFC6698] | | 0 | Full | No hash used | [RFC6698] |
| 1 | SHA2-256 | 256 bit hash by SHA2 | [RFC6698] | | 1 | SHA2-256 | 256 bit hash by SHA2 | [RFC6698] |
| 2 | SHA2-512 | 512 bit hash by SHA2 | [RFC6698] | | 2 | SHA2-512 | 512 bit hash by SHA2 | [RFC6698] |
| 3-254 | | Unassigned | | | 3-254 | | Unassigned | |
| 255 | PrivMatch | Reserved for Private Use | [RFC6698] | | 255 | PrivMatch | Reserved for Private Use | [RFC6698] |
+-------+-----------+--------------------------+-----------+ +-------+-----------+--------------------------+-----------+
Table 3: TLSA Matching Types Table 3: TLSA Matching Types
2.1.4. The Certificate Assocation Data Field 2.1.4. The Certificate Association Data Field
The meaning, semantics, and interpretation of the Certificate The meaning, semantics, and interpretation of the Certificate
Association Data field of the IPSECA resource record follow the Association Data field of the IPSECA resource record follow the
specification of the same field in the TLSA resource record, specification of the same field in the TLSA resource record,
described in Section 2.1.4 of [RFC6698]: described in Section 2.1.4 of [RFC6698]:
"This field specifies the 'certificate association data' to be "This field specifies the 'certificate association data' to be
matched. These bytes are either raw data (that is, the full matched. These bytes are either raw data (that is, the full
certificate or its SubjectPublicKeyInfo, depending on the certificate or its SubjectPublicKeyInfo, depending on the
selector) for matching type 0, or the hash of the raw data for selector) for matching type 0, or the hash of the raw data for
skipping to change at page 9, line 38 skipping to change at page 10, line 42
addresses). addresses).
Any custom configured tunnels and port mappings may result local Any custom configured tunnels and port mappings may result local
policies that use their own domain name format. Such custom OE policies that use their own domain name format. Such custom OE
tunnels are non-standard, and may not be discoverable by other tunnels are non-standard, and may not be discoverable by other
relying parties. relying parties.
2.4. IPSECA RR Examples 2.4. IPSECA RR Examples
Because the IPSECA record is intended to be associated with a Service Because the IPSECA record is intended to be associated with a Service
Address Records, it (implicitly) can also be associated with an IP Address Records, it can (implicitly) also be associated with an IP
address (through the reverse DNS). A few illustrative mappings are address through the reverse DNS. A few illustrative mappings are
presented here as examples. These domain name / resource record presented here as examples. Note that these domain name / resource
mappings are not necessarily intended to update the processing of record mappings are not necessarily intended to update the processing
protocols like IKEv1 [RFC2409], IKEv2 [RFC5996], etc. or other OE of protocols like IKEv1 [RFC2409], IKEv2 [RFC5996], etc. or other OE
protocols [RFC4322]. Rather, these mappings are intended to serve as protocols [RFC4322]. Rather, these mappings are intended to serve as
examples of IPsec tunnels, and their proper configuration. They MAY examples of IPsec tunnels, and their proper configuration. Those
be used in verifying Security Associations, but a protocol to do this mappings MAY be used in verifying Security Associations. However, we
is beyond the scope of this document. note that a specific protocol to do the verification is beyond the
scope of this document.
We note that there are several issues associated with using forward
DNS in the following examples. In particular, a malicious actor may
intercept a tunnel by showing a key for an association with an A
record to an arbitrary initiator. We note that this is more of a
foundational problem addressed by Internet Number Resource
Certification. Systems proposed to address this include the Resource
Public Key Infrastructure (RPKI), and others.
2.4.1. OE to a DNS Name Server Example 2.4.1. OE to a DNS Name Server Example
Suppose a DNS zone example.com is served by the name servers Suppose a DNS zone example.com is served by the name servers
ns1.example.com and ns2.example.com. If the zone operators want to ns1.example.com and ns2.example.com. If the zone operators want to
advertise their willingness to offer OE to their name servers using advertise their willingness to offer OE to their name servers using
IKEv2 [RFC5996], then the following domain names MUST be placed under IKEv2 [RFC5996], then the following domain names MUST be placed under
the example.com zone (the contents of the resource records, below, the example.com zone (the contents of the resource records, below,
are exemplary only and MAY have whatever values a zone operator are exemplary only and MAY have whatever values a zone operator
chooses): chooses):
skipping to change at page 12, line 24 skipping to change at page 13, line 35
protections, like TLS [RFC5246]. Any combination of these types of protections, like TLS [RFC5246]. Any combination of these types of
protections offer both defense-in-depth (securing transactions at protections offer both defense-in-depth (securing transactions at
multiple levels) and offer security practitioners a larger mosaic of multiple levels) and offer security practitioners a larger mosaic of
security tools from which to construct and maintain their security security tools from which to construct and maintain their security
postures. postures.
5.1. Interactions 5.1. Interactions
This document requires that all fully qualified domain names This document requires that all fully qualified domain names
[RFC1035] must be secured by DNSSEC. This includes domains in the [RFC1035] must be secured by DNSSEC. This includes domains in the
reverse tree of DNS (which represent IP addresses). reverse tree of DNS (which represent IP addresses). An important
question in this context is whether an unvalidated IPSECA record
would be better than nothing. In other words, would it be better to
tolerate failed validation or even unsigned (non-DNSSEC) IPSECA
records than to refuse to allow a connection? Permitting the use of
unsigned records introduces a vector for downgrade attacks.
The use of IPSECA resource records does not constitute a source of The use of IPSECA resource records does not constitute a source of
information leakage. Rather, it provides a mechanism to help bolster information leakage. Rather, it provides a mechanism to help bolster
confidentiality, by obfuscating DNS transactions. confidentiality, by obfuscating DNS transactions.
Expressing tunnel endpoints through DNS may allow adversaries a Expressing tunnel endpoints through DNS may allow adversaries a
vehicle to learn where OE is being offered by name servers. However, vehicle to learn where OE is being offered by name servers. However,
OE tunnels to these name servers will only be attempted if querying OE tunnels to these name servers will only be attempted if querying
resolvers are configured to attempt IPsec. As a result, adversaries resolvers are configured to attempt IPsec. As a result, adversaries
may be able to learn of potential tunnel endpoints, but if they aim may be able to learn of potential tunnel endpoints, but if they aim
skipping to change at page 13, line 33 skipping to change at page 15, line 4
queries than configuration requests. So, queries than configuration requests. So,
W_cfg(T) = 1, and W_rDNS(T) >> W_cfg(T). W_cfg(T) = 1, and W_rDNS(T) >> W_cfg(T).
However, consider the attack window when using OE: {W(T)}. If the However, consider the attack window when using OE: {W(T)}. If the
initial configuration includes a DNSKEY trust anchor that can be used initial configuration includes a DNSKEY trust anchor that can be used
to verify DNSSEC data that corresponds to a resolver's corresponding to verify DNSSEC data that corresponds to a resolver's corresponding
reverse zone (i.e., the IPSECA RR under in-addr.arpa or ip6.arpa), reverse zone (i.e., the IPSECA RR under in-addr.arpa or ip6.arpa),
then {W_cfg(T)} = 1 and {W_rDNS(T)} = 0. Therefore, since W_rDNS(T) then {W_cfg(T)} = 1 and {W_rDNS(T)} = 0. Therefore, since W_rDNS(T)
>> W_cfg(T) and {W_rDNS(T)} = 0, then by the transitive property, >> W_cfg(T) and {W_rDNS(T)} = 0, then by the transitive property,
W(T) >> {W(T)}. W(T) >> {W(T)}.
While this protocol is designed to enable best effort encryption for
IPsec without any prearrangement between entities, this mechanism
does not attempt to provide authentication. Entities that are
security conscious may choose to undergo an authentication and
verification process at a certification authority to obtain a
certificate that attests to the organization's identity. Entities
that are concerned about the IP resource ownership or route origin
may consider adopting an additional mechanism that is designed for
that purpose.
6. Acknowledgements 6. Acknowledgements
The editors would like to express their thanks for the early support The editors would like to express their thanks for the early support
and insights given by Danny McPherson. and insights given by Danny McPherson.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
skipping to change at page 14, line 21 skipping to change at page 15, line 47
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005. RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005. Extensions", RFC 4035, March 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced
Mail System Status Codes", BCP 138, RFC 5248, June 2008.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS) of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, August 2012. Protocol: TLSA", RFC 6698, August 2012.
[RFC6810] Bush, R. and R. Austein, "The Resource Public Key
Infrastructure (RPKI) to Router Protocol", RFC 6810,
January 2013.
[RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify
Conversations about DNS-Based Authentication of Named
Entities (DANE)", RFC 7218, April 2014.
7.2. Informative References 7.2. Informative References
[DANE_SATIN12] [DANE_SATIN12]
Osterweil, E., Kaliski, B., Larson, M., and D. McPherson, Osterweil, E., Kaliski, B., Larson, M., and D. McPherson,
"Reducing the X.509 Attack Surface with DNSSEC's DANE", "Reducing the X.509 Attack Surface with DNSSEC's DANE",
Proceedings of Securing and Trusting Internet Names, SATIN Proceedings of Securing and Trusting Internet Names, SATIN
'12, March 2012. '12, March 2012.
[I-D.draft-ogud-dane-vocabulary] [I-D.draft-ogud-dane-vocabulary]
Gudmundsson, O., "Harmonizing how applications specify Gudmundsson, O., "Harmonizing how applications specify
DANE-like usage", October 2013. DANE-like usage", October 2013.
[I.D.draft-ietf-dane-registry-acronyms]
Gudmundsson, O., "Adding acronyms to simplify DANE
conversations", January 2014.
[IPSEC_APPEAL] [IPSEC_APPEAL]
Osterweil, E. and D. McPherson, "IPsec's Appeal: Osterweil, E. and D. McPherson, "IPsec's Appeal:
Protecting DNS Under the Covers", Verisign Labs Technical Protecting DNS Under the Covers", Verisign Labs Technical
Report #1130006 Revision 1, January 2013. Report #1130006 Revision 1, January 2013.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997. RFC 2131, March 1997.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998. (IKE)", RFC 2409, November 1998.
skipping to change at page 15, line 37 skipping to change at page 17, line 23
[RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and
Internet Key Exchange (IKE) Document Roadmap", RFC 6071, Internet Key Exchange (IKE) Document Roadmap", RFC 6071,
February 2011. February 2011.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP", Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, June 2013. RFC 6960, June 2013.
[TASRS] Osterweil, E. and D. McPherson, "TASRS: Towards a Secure
Routing System Through Internet Number Resource
Certification", Verisign Labs Technical Report #1130009
Revision 1, February 2013.
Appendix A. Name Server OE Configuration Example Appendix A. Name Server OE Configuration Example
<STUBBED OUT SECTION> <STUBBED OUT SECTION>
NAME SERVER SIDE NAME SERVER SIDE
o Config SPD to accept connections from any on port 53 only o Config SPD to accept connections from any on port 53 only
o Zones add IPSECA RRs for each NS domain name and configure DNSSEC: o Zones add IPSECA RRs for each NS domain name and configure DNSSEC:
<examples> <examples>
 End of changes. 30 change blocks. 
110 lines changed or deleted 168 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/