summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7673.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7673.txt')
-rw-r--r--doc/rfc/rfc7673.txt899
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc7673.txt b/doc/rfc/rfc7673.txt
new file mode 100644
index 0000000..eeb96a8
--- /dev/null
+++ b/doc/rfc/rfc7673.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) T. Finch
+Request for Comments: 7673 University of Cambridge
+Category: Standards Track M. Miller
+ISSN: 2070-1721 Cisco Systems, Inc.
+ P. Saint-Andre
+ &yet
+ October 2015
+
+
+ Using DNS-Based Authentication of Named Entities (DANE)
+ TLSA Records with SRV Records
+
+Abstract
+
+ The DNS-Based Authentication of Named Entities (DANE) specification
+ (RFC 6698) describes how to use TLSA resource records secured by
+ DNSSEC (RFC 4033) to associate a server's connection endpoint with
+ its Transport Layer Security (TLS) certificate (thus enabling
+ administrators of domain names to specify the keys used in that
+ domain's TLS servers). However, application protocols that use SRV
+ records (RFC 2782) to indirectly name the target server connection
+ endpoints for a service domain name cannot apply the rules from RFC
+ 6698. Therefore, this document provides guidelines that enable such
+ protocols to locate and use TLSA records.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7673.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Finch, et al. Standards Track [Page 1]
+
+RFC 7673 TLSA and SRV October 2015
+
+
+Copyright Notice
+
+ Copyright (c) 2015 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Terminology .....................................................4
+ 3. DNS Checks ......................................................4
+ 3.1. SRV Query ..................................................4
+ 3.2. Address Queries ............................................5
+ 3.3. TLSA Queries ...............................................6
+ 3.4. Impact on TLS Usage ........................................6
+ 4. TLS Checks ......................................................7
+ 4.1. SRV Records Only ...........................................7
+ 4.2. TLSA Records ...............................................8
+ 5. Guidance for Protocol Authors ...................................8
+ 6. Guidance for Server Operators ...................................8
+ 7. Guidance for Application Developers .............................9
+ 8. Internationalization Considerations .............................9
+ 9. Security Considerations ........................................10
+ 9.1. Mixed Security Status .....................................10
+ 9.2. Certificate Subject Name Matching .........................10
+ 10. References ....................................................11
+ 10.1. Normative References .....................................11
+ 10.2. Informative References ...................................12
+ Appendix A. Examples ..............................................13
+ A.1. IMAP .......................................................13
+ A.2. XMPP .......................................................13
+ Appendix B. Rationale .............................................14
+ Acknowledgements ..................................................15
+ Authors' Addresses ................................................16
+
+
+
+
+
+
+
+
+Finch, et al. Standards Track [Page 2]
+
+RFC 7673 TLSA and SRV October 2015
+
+
+1. Introduction
+
+ The base DNS-Based Authentication of Named Entities (DANE)
+ specification [RFC6698] describes how to use TLSA resource records
+ secured by DNSSEC [RFC4033] to associate a target server's connection
+ endpoint with its Transport Layer Security (TLS) certificate (thus
+ enabling administrators of domain names to specify the keys used in
+ that domain's TLS servers). Some application protocols locate
+ connection endpoints indirectly via SRV records [RFC2782]. As a
+ result of this indirection, the rules specified in [RFC6698] cannot
+ be directly applied to such application protocols. (Rules for SMTP
+ [RFC5321], which uses MX resource records instead of SRV records, are
+ described in [RFC7672].)
+
+ This document describes how to use DANE TLSA records with SRV
+ records. To summarize:
+
+ o We rely on DNSSEC to secure SRV records that map the desired
+ service, transport protocol, and service domain name to the
+ corresponding target server connection endpoints (i.e., the target
+ server hostnames and port numbers returned in the SRV records for
+ that service type).
+
+ o Although in accordance with [RFC2782] a service domain name can
+ advertise a number of SRV records (some of which might map to
+ connection endpoints that do not support TLS), the intent of this
+ specification is for a client to securely discover connection
+ endpoints that support TLS.
+
+ o The TLSA records for each connection endpoint are located using
+ the transport protocol, port number, and hostname for the target
+ server (not the service domain name).
+
+ o When DNSSEC-validated TLSA records are published for a given
+ connection endpoint, clients always use TLS when connecting (even
+ if the connection endpoint supports cleartext communication).
+
+ o If there is at least one usable TLSA record for a given connection
+ endpoint, the connection endpoint's TLS certificate or public key
+ needs to match at least one of those usable TLSA records.
+
+ o If there are no usable TLSA records for a given connection
+ endpoint, the target server hostname is used as one of the
+ acceptable reference identifiers, as described in [RFC6125].
+ Other reference identifiers might arise through CNAME expansion of
+ either the service domain name or target server hostname, as
+ detailed in [RFC7671].
+
+
+
+
+Finch, et al. Standards Track [Page 3]
+
+RFC 7673 TLSA and SRV October 2015
+
+
+ o If there are no usable TLSA records for any connection endpoint
+ (and thus the client cannot securely discover a connection
+ endpoint that supports TLS), the client's behavior is a matter for
+ the application protocol or client implementation; this might
+ involve a fallback to non-DANE behavior using the public key
+ infrastructure [RFC5280].
+
+2. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this memo are to be interpreted as described in
+ [RFC2119].
+
+ This document uses the definitions for "secure", "insecure", "bogus",
+ and "indeterminate" from Section 4.3 of [RFC4035]. This document
+ uses the acronyms from [RFC7218] for the values of TLSA fields where
+ appropriate.
+
+ Additionally, this document uses the following terms:
+
+ connection endpoint: A tuple of a fully qualified DNS hostname,
+ transport protocol, and port number that a client uses to
+ establish a connection to the target server.
+
+ service domain name: The fully qualified DNS domain name that
+ identifies an application service; corresponds to the term "source
+ domain" from [RFC6125].
+
+ This document uses the term "target server hostname" in place of the
+ term "derived domain" from the so-called CertID specification
+ [RFC6125].
+
+3. DNS Checks
+
+3.1. SRV Query
+
+ When the client makes an SRV query, a successful result will
+ typically be a list of one or more SRV records (or possibly a chain
+ of CNAME/DNAME aliases leading to such a list).
+
+ NOTE: Implementers need to be aware that unsuccessful results can
+ occur because of various DNS-related errors; guidance on avoiding
+ downgrade attacks can be found in Section 2.1 of [RFC7672].
+
+
+
+
+
+
+
+Finch, et al. Standards Track [Page 4]
+
+RFC 7673 TLSA and SRV October 2015
+
+
+ For this specification to apply, the entire chain of DNS RRset(s)
+ returned MUST be "secure" according to DNSSEC validation (Section 5
+ of [RFC4035]). In the case where the answer is obtained via a chain
+ of CNAME and/or DNAME aliases, the whole chain of CNAME and DNAME
+ RRsets MUST also be secure.
+
+ If the SRV lookup fails because the RRset is "bogus" (or the lookup
+ fails for reasons other than no records), the client MUST abort its
+ attempt to connect to the desired service. If the lookup result is
+ "insecure" (or no SRV records exist), this protocol does not apply
+ and the client SHOULD fall back to its non-DNSSEC, non-DANE (and
+ possibly non-SRV) behavior.
+
+ When the lookup returns a "secure" RRset (possibly via a chain of
+ "secure" CNAME/DNAME records), the client now has an authentic list
+ of target server connection endpoints with weight and priority
+ values. It performs server ordering and selection using the weight
+ and priority values without regard to the presence or absence of
+ DNSSEC or TLSA records. It also takes note of the DNSSEC validation
+ status of the SRV response for use when checking certificate names
+ (see Section 4). The client can then proceed to making address
+ queries on the target server hostnames as described in the following
+ section.
+
+3.2. Address Queries
+
+ For each SRV target server connection endpoint, the client makes
+ A and/or AAAA queries, performs DNSSEC validation on the address
+ (A or AAAA) response, and continues as follows, based on the results:
+
+ o If a returned RRSet is "secure", the client MUST perform a TLSA
+ query for that target server connection endpoint, as described in
+ the next section.
+
+ o If no returned RRsets are "secure", the client MUST NOT perform a
+ TLSA query for that target server connection endpoint; the TLSA
+ query will most likely fail or produce spurious results.
+
+ o If the address record lookup fails (a validation status of either
+ "bogus" or "indeterminate"), the client MUST NOT connect to this
+ connection endpoint; instead, it uses the next most appropriate
+ SRV target. This helps prevent downgrade attacks.
+
+
+
+
+
+
+
+
+
+Finch, et al. Standards Track [Page 5]
+
+RFC 7673 TLSA and SRV October 2015
+
+
+3.3. TLSA Queries
+
+ The client SHALL construct the TLSA query name as described in
+ Section 3 of [RFC6698], based on the fields from the SRV record: the
+ port number from the SRV RDATA, the transport protocol from the SRV
+ query name, and the TLSA base domain from the SRV target server
+ hostname.
+
+ For example, the following SRV record for IMAP (see [RFC6186])
+
+ _imap._tcp.example.com. 86400 IN SRV 10 0 9143 imap.example.net.
+
+ leads to the TLSA query shown below:
+
+ _9143._tcp.imap.example.net. IN TLSA ?
+
+3.4. Impact on TLS Usage
+
+ The client SHALL determine if the TLSA records returned in the
+ previous step are usable according to Section 4.1 of [RFC6698]. This
+ affects the use of TLS as follows:
+
+ o If the TLSA response is "secure" and usable, then the client MUST
+ use TLS when connecting to the target server. The TLSA records
+ are used when validating the server's certificate as described in
+ Section 4.
+
+ o If the TLSA response is "bogus" or "indeterminate" (or the lookup
+ fails for reasons other than no records), then the client MUST NOT
+ connect to the target server (the client can still use other SRV
+ targets).
+
+ o If the TLSA response is "insecure" (or no TLSA records exist),
+ then the client SHALL proceed as if the target server had no TLSA
+ records. It MAY connect to the target server with or without TLS,
+ subject to the policies of the application protocol or client
+ implementation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Finch, et al. Standards Track [Page 6]
+
+RFC 7673 TLSA and SRV October 2015
+
+
+4. TLS Checks
+
+ When connecting to a server, the client MUST use TLS if the responses
+ to the SRV and TLSA queries were "secure" as described above. The
+ rules described in the next two sections -- Section 4.2 for cases
+ where there is at least one usable TLSA record, and Section 4.1
+ otherwise -- apply to such secure responses.
+
+4.1. SRV Records Only
+
+ If the client received zero usable TLSA certificate associations, it
+ SHALL validate the server's TLS certificate using the normal PKIX
+ rules [RFC5280] or protocol-specific rules (e.g., following
+ [RFC6125]) without further input from the TLSA records. In this
+ case, the client uses the information in the server certificate and
+ the DNSSEC validation status of the SRV query in its authentication
+ checks. It SHOULD use the Server Name Indication extension (TLS SNI)
+ [RFC6066] or its functional equivalent in the relevant application
+ protocol (e.g., in the Extensible Messaging and Presence Protocol
+ (XMPP) [RFC6120], this is the 'to' address of the initial stream
+ header). The preferred name SHALL be chosen as follows, and the
+ client SHALL verify the identity asserted by the server's certificate
+ according to Section 6 of [RFC6125], using a list of reference
+ identifiers constructed as follows (note again that in RFC 6125 the
+ terms "source domain" and "derived domain" refer to the same things
+ as "service domain name" and "target server hostname" in this
+ document). The examples below assume a service domain name of
+ "im.example.com" and a target server hostname of
+ "xmpp23.hosting.example.net".
+
+ SRV is insecure: The reference identifiers SHALL include the service
+ domain name and MUST NOT include the SRV target server hostname
+ (e.g., include "im.example.com" but not
+ "xmpp23.hosting.example.net"). The service domain name is the
+ preferred name for TLS SNI or its equivalent.
+
+ SRV is secure: The reference identifiers SHALL include both the
+ service domain name and the SRV target server hostname (e.g.,
+ include both "im.example.com" and "xmpp23.hosting.example.net").
+ The service domain name is still the preferred name for TLS SNI or
+ its equivalent (this reduces code complexity and the possibility
+ of interoperability problems).
+
+ In the latter case, the client will accept either identity to ensure
+ compatibility with servers that support this specification as well as
+ servers that do not support this specification.
+
+
+
+
+
+Finch, et al. Standards Track [Page 7]
+
+RFC 7673 TLSA and SRV October 2015
+
+
+4.2. TLSA Records
+
+ If the client received one or more usable TLSA certificate
+ associations, it SHALL process them as described in Section 2.1 of
+ [RFC6698].
+
+ If the TLS server's certificate -- or the public key of the server's
+ certificate -- matches a usable TLSA record with certificate usage
+ DANE-EE, the client MUST ignore validation checks from [RFC5280] and
+ reference identifier checks from [RFC6125]. The information in such
+ a TLSA record supersedes the non-key information in the certificate.
+
+5. Guidance for Protocol Authors
+
+ This document describes how to use DANE with application protocols in
+ which target servers are discovered via SRV records. Although this
+ document attempts to provide generic guidance applying to all such
+ protocols, additional documents for particular application protocols
+ could cover related topics, such as:
+
+ o Fallback logic in the event that a client is unable to connect
+ securely to a target server by following the procedures defined in
+ this document.
+
+ o How clients ought to behave if (1) they do not support SRV lookups
+ or (2) they do support SRV lookups and encounter service domain
+ names that do not offer SRV records.
+
+ o Whether or not the application protocol has a functional
+ equivalent for TLS SNI that is preferred within that protocol.
+
+ o The use of SRV records with additional discovery technologies,
+ such as the use of both SRV records and NAPTR records [RFC3403]
+ for transport selection in the Session Initiation Protocol (SIP).
+
+ For example, [XMPP-DNA] covers such topics for XMPP.
+
+6. Guidance for Server Operators
+
+ To conform to this specification, the published SRV records and
+ subsequent address (A and AAAA) records MUST be secured with DNSSEC.
+ There SHOULD also be at least one TLSA record published that
+ authenticates the server's certificate.
+
+ When using TLSA records with certificate usage DANE-EE, it is not
+ necessary for the deployed certificate to contain an identifier for
+ either the source domain or target server hostname. However,
+ operators need to be aware that servers relying solely on validation
+
+
+
+Finch, et al. Standards Track [Page 8]
+
+RFC 7673 TLSA and SRV October 2015
+
+
+ using certificate usage DANE-EE TLSA records might prevent clients
+ that do not support this specification from successfully connecting
+ with TLS.
+
+ For TLSA records with certificate usage types other than DANE-EE, the
+ certificate(s) MUST contain an identifier that matches:
+
+ o the service domain name (the "source domain" in [RFC6125] terms,
+ which is the SRV query domain), and/or
+
+ o the target server hostname (the "derived domain" in [RFC6125]
+ terms, which is the SRV target hostname).
+
+ Servers that support multiple service domain names (i.e., so-called
+ "multi-tenanted environments") can implement TLS SNI [RFC6066] or its
+ functional equivalent to determine which certificate to offer.
+ Clients that do not support this specification will indicate a
+ preference for the service domain name, while clients that support
+ this specification will indicate the target server hostname.
+ However, the server determines what certificate to present in the TLS
+ handshake; e.g., the presented certificate might only authenticate
+ the target server hostname.
+
+7. Guidance for Application Developers
+
+ Developers of application clients that depend on DANE-SRV often would
+ like to prepare as quickly as possible for making a connection to the
+ intended service, thus reducing the wait time for end users. To make
+ this optimization possible, a DNS library might perform the address
+ queries and TLSA queries in parallel. (Because a TLSA record can be
+ ignored if it turns out that the address record on which it depends
+ is not secure, performing the TLSA queries in parallel with the
+ address queries is not harmful from a security perspective and can
+ yield some operational benefits.)
+
+8. Internationalization Considerations
+
+ If any of the DNS queries are for an internationalized domain name,
+ then they need to use the A-label form [RFC5890].
+
+
+
+
+
+
+
+
+
+
+
+
+Finch, et al. Standards Track [Page 9]
+
+RFC 7673 TLSA and SRV October 2015
+
+
+9. Security Considerations
+
+9.1. Mixed Security Status
+
+ We do not specify that all of the target server connection endpoints
+ for a service domain name need to be consistent in whether they have
+ or do not have TLSA records. This is so that partial or incremental
+ deployment does not break the service. Different levels of
+ deployment are likely if a service domain name has a third-party
+ fallback server, for example.
+
+ The SRV sorting rules are unchanged; in particular, they have not
+ been altered in order to prioritize secure connection endpoints over
+ insecure connection endpoints. If a site wants to be secure, it
+ needs to deploy this protocol completely; a partial deployment is not
+ secure, and we make no special effort to support it.
+
+9.2. Certificate Subject Name Matching
+
+ Section 4 of the TLSA specification [RFC6698] leaves the details of
+ checking names in certificates to higher-level application protocols,
+ though it suggests the use of [RFC6125].
+
+ Name checks are not necessary if the matching TLSA record is of
+ certificate usage DANE-EE. Because such a record identifies the
+ specific certificate (or public key of the certificate), additional
+ checks are superfluous and potentially conflicting.
+
+ Otherwise, while DNSSEC provides a secure binding between the server
+ name and the TLSA record, and the TLSA record provides a binding to a
+ certificate, this latter step can be indirect via a chain of
+ certificates. For example, a certificate usage PKIX-TA TLSA record
+ only authenticates the Certification Authority (CA) that issued the
+ certificate, and third parties can obtain certificates from the same
+ CA. Therefore, clients need to check to see whether or not the
+ server's certificate matches one of the expected reference
+ identifiers to ensure that the certificate was issued by the CA to
+ the server the client expects (naturally, this is in addition to
+ standard certificate-related checks as specified in [RFC5280],
+ including but not limited to certificate syntax, certificate
+ extensions such as name constraints and extended key usage, and
+ handling of certification paths).
+
+
+
+
+
+
+
+
+
+Finch, et al. Standards Track [Page 10]
+
+RFC 7673 TLSA and SRV October 2015
+
+
+10. References
+
+10.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+ specifying the location of services (DNS SRV)", RFC 2782,
+ DOI 10.17487/RFC2782, February 2000,
+ <http://www.rfc-editor.org/info/rfc2782>.
+
+ [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "DNS Security Introduction and Requirements",
+ RFC 4033, DOI 10.17487/RFC4033, March 2005,
+ <http://www.rfc-editor.org/info/rfc4033>.
+
+ [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Protocol Modifications for the DNS Security
+ Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
+ <http://www.rfc-editor.org/info/rfc4035>.
+
+ [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+ Housley, R., and W. Polk, "Internet X.509 Public Key
+ Infrastructure Certificate and Certificate Revocation List
+ (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
+ <http://www.rfc-editor.org/info/rfc5280>.
+
+ [RFC5890] Klensin, J., "Internationalized Domain Names for
+ Applications (IDNA): Definitions and Document Framework",
+ RFC 5890, DOI 10.17487/RFC5890, August 2010,
+ <http://www.rfc-editor.org/info/rfc5890>.
+
+ [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
+ Extensions: Extension Definitions", RFC 6066,
+ DOI 10.17487/RFC6066, January 2011,
+ <http://www.rfc-editor.org/info/rfc6066>.
+
+ [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
+ Verification of Domain-Based Application Service Identity
+ within Internet Public Key Infrastructure Using X.509
+ (PKIX) Certificates in the Context of Transport Layer
+ Security (TLS)", RFC 6125, DOI 10.17487/RFC6125,
+ March 2011, <http://www.rfc-editor.org/info/rfc6125>.
+
+
+
+
+
+Finch, et al. Standards Track [Page 11]
+
+RFC 7673 TLSA and SRV October 2015
+
+
+ [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
+ of Named Entities (DANE) Transport Layer Security (TLS)
+ Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698,
+ August 2012, <http://www.rfc-editor.org/info/rfc6698>.
+
+ [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify
+ Conversations about DNS-Based Authentication of Named
+ Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218,
+ April 2014, <http://www.rfc-editor.org/info/rfc7218>.
+
+ [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based
+ Authentication of Named Entities (DANE) Protocol: Updates
+ and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671,
+ October 2015, <http://www.rfc-editor.org/info/rfc7671>.
+
+ [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via
+ Opportunistic DNS-Based Authentication of Named Entities
+ (DANE) Transport Layer Security (TLS)", RFC 7672,
+ DOI 10.17487/RFC7672, October 2015,
+ <http://www.rfc-editor.org/info/rfc7672>.
+
+10.2. Informative References
+
+ [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
+ Part Three: The Domain Name System (DNS) Database",
+ RFC 3403, DOI 10.17487/RFC3403, October 2002,
+ <http://www.rfc-editor.org/info/rfc3403>.
+
+ [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
+ DOI 10.17487/RFC5321, October 2008,
+ <http://www.rfc-editor.org/info/rfc5321>.
+
+ [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
+ Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
+ March 2011, <http://www.rfc-editor.org/info/rfc6120>.
+
+ [RFC6186] Daboo, C., "Use of SRV Records for Locating Email
+ Submission/Access Services", RFC 6186,
+ DOI 10.17487/RFC6186, March 2011,
+ <http://www.rfc-editor.org/info/rfc6186>.
+
+ [XMPP-DNA] Saint-Andre, P., Miller, M., and P. Hancke, "Domain Name
+ Associations (DNA) in the Extensible Messaging and
+ Presence Protocol (XMPP)", Work in Progress,
+ draft-ietf-xmpp-dna-11, September 2015.
+
+
+
+
+
+
+Finch, et al. Standards Track [Page 12]
+
+RFC 7673 TLSA and SRV October 2015
+
+
+Appendix A. Examples
+
+ In the following, most of the DNS resource data is elided for
+ simplicity.
+
+A.1. IMAP
+
+ ; mail domain
+ _imap._tcp.example.com. SRV 10 0 9143 imap.example.net.
+ example.com. RRSIG SRV ...
+
+ ; target server hostname
+ imap.example.net. A 192.0.2.1
+ imap.example.net. RRSIG A ...
+
+ imap.example.net. AAAA 2001:db8:212:8::e:1
+ imap.example.net. RRSIG ...
+
+ ; TLSA resource record
+ _9143._tcp.imap.example.net. TLSA ...
+ _9143._tcp.imap.example.net. RRSIG TLSA ...
+
+ Mail messages received for addresses at example.com are retrieved via
+ IMAP at imap.example.net. Connections to imap.example.net port 9143
+ that use STARTTLS will get a server certificate that authenticates
+ the name imap.example.net.
+
+A.2. XMPP
+
+ ; XMPP domain
+ _xmpp-client._tcp.example.com. SRV 1 0 5222 im.example.net.
+ _xmpp-client._tcp.example.com. RRSIG SRV ...
+
+ ; target server hostname
+ im.example.net. A 192.0.2.3
+ im.example.net. RRSIG A ...
+
+ im.example.net. AAAA 2001:db8:212:8::e:4
+ im.example.net. RRSIG AAAA ...
+
+ ; TLSA resource record
+ _5222._tcp.im.example.net. TLSA ...
+ _5222._tcp.im.example.net. RRSIG TLSA ...
+
+ XMPP sessions for addresses at example.com are established at
+ im.example.net. Connections to im.example.net port 5222 that use
+ STARTTLS will get a server certificate that authenticates the name
+ im.example.net.
+
+
+
+Finch, et al. Standards Track [Page 13]
+
+RFC 7673 TLSA and SRV October 2015
+
+
+Appendix B. Rationale
+
+ The long-term goal of this specification is to settle on TLS
+ certificates that verify the target server hostname rather than the
+ service domain name, since this is more convenient for servers
+ hosting multiple domains (so-called "multi-tenanted environments")
+ and scales up more easily to larger numbers of service domain names.
+
+ There are a number of other reasons for doing it this way:
+
+ o The certificate is part of the server configuration, so it makes
+ sense to associate it with the target server hostname rather than
+ the service domain name.
+
+ o In the absence of TLS SNI, if the certificate identifies the
+ target server hostname, then it does not need to list all the
+ possible service domain names.
+
+ o When the server certificate is replaced, it is much easier if
+ there is one part of the DNS that needs updating to match, instead
+ of an unbounded number of hosted service domain names.
+
+ o The same TLSA records work with this specification, and with
+ direct connections to the connection endpoint in the style of
+ [RFC6698].
+
+ o Some application protocols, such as SMTP, allow a client to
+ perform transactions with multiple service domain names in the
+ same connection. It is not, in general, feasible for the client
+ to specify the service domain name using TLS SNI when the
+ connection is established, and the server might not be able to
+ present a certificate that authenticates all possible service
+ domain names. See [RFC7672] for details.
+
+ o It is common for SMTP servers to act in multiple roles -- for
+ example, as outgoing relays or as incoming MX servers, depending
+ on the client identity. It is simpler if the server can present
+ the same certificate regardless of the role in which it is to act.
+ Sometimes the server does not know its role until the client has
+ authenticated, which usually occurs after TLS has been
+ established. See [RFC7672] for details.
+
+
+
+
+
+
+
+
+
+
+Finch, et al. Standards Track [Page 14]
+
+RFC 7673 TLSA and SRV October 2015
+
+
+ This specification does not provide an option to put TLSA records
+ under the service domain name, because that would add complexity
+ without providing any benefit; security protocols are best kept
+ simple. As described above, there are real-world cases where
+ authenticating the service domain name cannot be made to work, so
+ there would be complicated criteria regarding when service domain
+ name TLSA records might be used and when they cannot. This is all
+ avoided by putting the TLSA records under the target server hostname.
+
+ The disadvantage is that clients that do not complete DNSSEC
+ validation must, according to [RFC6125] rules, check the server
+ certificate against the service domain name, since they have no other
+ way to authenticate the server. This means that SNI support or its
+ functional equivalent is necessary for backward compatibility.
+
+Acknowledgements
+
+ Thanks to Mark Andrews for arguing that authenticating the target
+ server hostname is the right thing, and that we ought to rely on
+ DNSSEC to secure the SRV lookup. Thanks to Stephane Bortzmeyer,
+ James Cloos, Viktor Dukhovni, Ned Freed, Olafur Gudmundsson, Paul
+ Hoffman, Phil Pennock, Hector Santos, Jonas Schneider, and Alessandro
+ Vesely for helpful suggestions.
+
+ Carl Wallace completed an insightful review on behalf of the Security
+ Directorate.
+
+ Ben Campbell, Brian Haberman, and Alvaro Retana provided helpful
+ feedback during IESG review.
+
+ The authors gratefully acknowledge the assistance of Olafur
+ Gudmundsson and Warren Kumari as the working group chairs and Stephen
+ Farrell as the sponsoring Area Director.
+
+ Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for
+ employing him during his work on earlier draft versions of this
+ document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Finch, et al. Standards Track [Page 15]
+
+RFC 7673 TLSA and SRV October 2015
+
+
+Authors' Addresses
+
+ Tony Finch
+ University of Cambridge Information Services
+ Roger Needham Building
+ 7 JJ Thomson Avenue
+ Cambridge CB3 0RB
+ United Kingdom
+
+ Phone: +44 797 040 1426
+ Email: dot@dotat.at
+ URI: http://dotat.at/
+
+
+ Matthew Miller
+ Cisco Systems, Inc.
+ 1899 Wynkoop Street, Suite 600
+ Denver, CO 80202
+ United States
+
+ Email: mamille2@cisco.com
+
+
+ Peter Saint-Andre
+ &yet
+
+ Email: peter@andyet.com
+ URI: https://andyet.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Finch, et al. Standards Track [Page 16]
+