--- /dev/null
+
+draft 11
+
+3.1.2 - Para 4 (records with Sel Full(0) are discouraged)
+==> There's a matching type Full but not such a Selector type.
+ Should this be "Cert(0), or Matching Type Full(0)" ?
+ Suspect the latter.
+
+3.1.2 Needs a para added regarding certificate date verification,
+ to contrast with the requirement to NOT check for
+ DANE-EE defined in 3.1.1
logging or causing an error, due to the internal use of bool_lax
instead of bool when processing it.
+JH/02 Add EXPERIMENTAL_DANE, allowing for using the DNS as trust-anchor for
+ server certificates when making smtp deliveries.
+
Exim version 4.84
-----------------
dns_csa_search_limit integer 5 main 4.60
dns_csa_use_reverse boolean true main 4.60
dns_dnssec_ok integer -1 main 4.82
+dns_dane_ok integer -1 main 4.83
dns_ipv4_lookup boolean false main 3.20
dns_qualify_single boolean true smtp
dns_retrans time 0s main 1.60
--- /dev/null
+
+
+
+
+DANE V. Dukhovni
+Internet-Draft Unaffiliated
+Intended status: Standards Track W. Hardaker
+Expires: February 18, 2015 Parsons
+ August 17, 2014
+
+
+ Updates to and Operational Guidance for the DANE Protocol
+ draft-ietf-dane-ops-06
+
+Abstract
+
+ This memo clarifies and updates the DANE TLSA protocol based on
+ implementation experience since the publication of the original DANE
+ specification in [RFC6698]. It also contains guidance for DANE
+ implementers and operators.
+
+Status of This Memo
+
+ This Internet-Draft is submitted in full conformance with the
+ provisions of BCP 78 and BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF). Note that other groups may also distribute
+ working documents as Internet-Drafts. The list of current Internet-
+ Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ This Internet-Draft will expire on February 18, 2015.
+
+Copyright Notice
+
+ Copyright (c) 2014 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.
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 1]
+\f
+Internet-Draft DANE operations August 2014
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. DANE TLSA Record Overview . . . . . . . . . . . . . . . . . . 4
+ 2.1. Example TLSA record . . . . . . . . . . . . . . . . . . . 6
+ 3. DANE TLS Requirements . . . . . . . . . . . . . . . . . . . . 6
+ 4. Certificate-Usage-Specific DANE Updates and Guidelines . . . 7
+ 4.1. Certificate Usage DANE-EE(3) . . . . . . . . . . . . . . 7
+ 4.2. Certificate Usage DANE-TA(2) . . . . . . . . . . . . . . 8
+ 4.3. Certificate Usage PKIX-EE(1) . . . . . . . . . . . . . . 11
+ 4.4. Certificate Usage PKIX-TA(0) . . . . . . . . . . . . . . 12
+ 4.5. Opportunistic Security and PKIX usages . . . . . . . . . 12
+ 5. Service Provider and TLSA Publisher Synchronization . . . . . 13
+ 6. TLSA Base Domain and CNAMEs . . . . . . . . . . . . . . . . . 15
+ 7. TLSA Publisher Requirements . . . . . . . . . . . . . . . . . 16
+ 7.1. Key rollover with fixed TLSA Parameters . . . . . . . . . 17
+ 7.2. Switching to DANE-TA from DANE-EE . . . . . . . . . . . . 18
+ 7.3. Switching to New TLSA Parameters . . . . . . . . . . . . 18
+ 7.4. TLSA Publisher Requirements Summary . . . . . . . . . . . 19
+ 8. Digest Algorithm Agility . . . . . . . . . . . . . . . . . . 19
+ 9. General DANE Guidelines . . . . . . . . . . . . . . . . . . . 20
+ 9.1. DANE DNS Record Size Guidelines . . . . . . . . . . . . . 21
+ 9.2. Certificate Name Check Conventions . . . . . . . . . . . 21
+ 9.3. Design Considerations for Protocols Using DANE . . . . . 23
+ 10. Interaction with Certificate Transparency . . . . . . . . . . 23
+ 11. Note on DNSSEC Security . . . . . . . . . . . . . . . . . . . 24
+ 12. Summary of Updates to RFC6698 . . . . . . . . . . . . . . . . 25
+ 13. Security Considerations . . . . . . . . . . . . . . . . . . . 26
+ 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
+ 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
+ 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
+ 16.1. Normative References . . . . . . . . . . . . . . . . . . 27
+ 16.2. Informative References . . . . . . . . . . . . . . . . . 28
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
+
+1. Introduction
+
+ [RFC6698] specifies a new DNS resource record "TLSA" that associates
+ a public certificate or public key of a trusted leaf or issuing
+ authority with the corresponding TLS transport endpoint. These DANE
+ TLSA records, when validated by DNSSEC, can be used to augment or
+ replace the trust model of the existing public Certification
+ Authority (CA) Public Key Infrastructure (PKI).
+
+ [RFC6698] defines three TLSA record fields with respectively 4, 2 and
+ 3 currently specified values. These yield 24 distinct combinations
+ of TLSA record types. This many options have lead to implementation
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 2]
+\f
+Internet-Draft DANE operations August 2014
+
+
+ and operational complexity. This memo will recommend best-practice
+ choices to help simplify implementation and deployment given these
+ plethora of choices.
+
+ Implementation complexity also arises from the fact that the TLS
+ transport endpoint is often specified indirectly via Service Records
+ (SRV), Mail Exchange (MX) records, CNAME records or other mechanisms
+ that map an abstract service domain to a concrete server domain.
+ With service indirection there are multiple potential places for
+ clients to find the relevant TLSA records. Service indirection is
+ often used to implement "virtual hosting", where a single Service
+ Provider transport endpoint simultaneously supports multiple hosted
+ domain names. With services that employ TLS, such hosting
+ arrangements may require the Service Provider to deploy multiple
+ pairs of private keys and certificates with TLS clients signaling the
+ desired domain via the Server Name Indication (SNI) extension
+ ([RFC6066], section 3). This memo provides operational guidelines
+ intended to maximize interoperability between DANE TLS clients and
+ servers.
+
+ In the context of this memo, channel security is assumed to be
+ provided by TLS or DTLS. The Transport Layer Security (TLS)
+ [RFC5246] and Datagram Transport Layer Security (DTLS) [RFC6347]
+ protocols provide secured TCP and UDP communication over IP. By
+ convention, "TLS" will be used throughout this document and, unless
+ otherwise specified, the text applies equally well to the DTLS
+ protocol. Used without authentication, TLS provides protection only
+ against eavesdropping through its use of encryption. With
+ authentication, TLS also provides integrity protection and
+ authentication, which protect the transport against man-in-the-middle
+ (MITM) attacks.
+
+ Other related documents that build on [RFC6698] are
+ [I-D.ietf-dane-srv] and [I-D.ietf-dane-smtp-with-dane]. In
+ Section 12 we summarize the updates this document makes to [RFC6698].
+
+1.1. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ [RFC2119].
+
+ The following terms are used throughout this document:
+
+ Service Provider: A company or organization that offers to host a
+ service on behalf of a Customer Domain. The original domain name
+ associated with the service often remains under the control of the
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 3]
+\f
+Internet-Draft DANE operations August 2014
+
+
+ customer. Connecting applications may be directed to the Service
+ Provider via a redirection resource record. Example redirection
+ records include MX, SRV, and CNAME. The Service Provider
+ frequently provides services for many customers and must carefully
+ manage any TLS credentials offered to connecting applications to
+ ensure name matching is handled easily by the applications.
+
+ Customer Domain: As described above, a client may be interacting
+ with a service that is hosted by a third party. We will refer to
+ the domain name used to locate the service prior to any
+ redirection, as the "Customer Domain".
+
+ TLSA Publisher: The entity responsible for publishing a TLSA record
+ within a DNS zone. This zone will be assumed DNSSEC-signed and
+ validatable to a trust anchor, unless otherwise specified. If the
+ Customer Domain is not outsourcing their DNS service, the TLSA
+ Publisher will be the customer themselves. Otherwise, the TLSA
+ Publisher is sometimes the operator of the outsourced DNS service.
+
+ public key: The term "public key" is short-hand for the
+ subjectPublicKeyInfo component of a PKIX [RFC5280] certificate.
+
+ SNI: The "Server Name Indication" (SNI) TLS protocol extension
+ allows a TLS client to request a connection to a particular
+ service name of a TLS server ([RFC6066], section 3). Without this
+ TLS extension, a TLS server has no choice but to offer a PKIX
+ certificate with a default list of server names, making it
+ difficult to host multiple Customer Domains at the same IP-
+ addressed based TLS service endpoint (i.e., "secure virtual
+ hosting").
+
+ TLSA parameters: In [RFC6698] the TLSA record is defined to consist
+ of four fields. The first three of these are numeric parameters
+ that specify the meaning of the data in fourth and final field.
+ To avoid language contortions when we need to distinguish between
+ the first three fields that together define a TLSA record "type"
+ and the fourth that provides a data value of that type, we will
+ call the first three fields "TLSA parameters", or sometimes just
+ "parameters" when obvious from context.
+
+2. DANE TLSA Record Overview
+
+
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 4]
+\f
+Internet-Draft DANE operations August 2014
+
+
+ DANE TLSA [RFC6698] specifies a protocol for publishing TLS server
+ certificate associations via DNSSEC [RFC4033] [RFC4034] [RFC4035].
+ The DANE TLSA specification defines multiple TLSA RR types via
+ combinations of numeric values of the first three fields of the TLSA
+ record (i.e. the "TLSA parameters"). The numeric values of these
+ parameters were later given symbolic names in [RFC7218]. These
+ parameters are:
+
+ The Certificate Usage field: Section 2.1.1 of [RFC6698] specifies 4
+ values: PKIX-TA(0), PKIX-EE(1), DANE-TA(2), and DANE-EE(3). There
+ is an additional private-use value: PrivCert(255). All other
+ values are reserved for use by future specifications.
+
+ The selector field: Section 2.1.2 of [RFC6698] specifies 2 values:
+ Cert(0), SPKI(1). There is an additional private-use value:
+ PrivSel(255). All other values are reserved for use by future
+ specifications.
+
+ The matching type field: Section 2.1.3 of [RFC6698] specifies 3
+ values: Full(0), SHA2-256(1), SHA2-512(2). There is an additional
+ private-use value: PrivMatch(255). All other values are reserved
+ for use by future specifications.
+
+ We may think of TLSA Certificate Usage values 0 through 3 as a
+ combination of two one-bit flags. The low-bit chooses between trust
+ anchor (TA) and end entity (EE) certificates. The high bit chooses
+ between PKIX, or public PKI issued, and DANE, or domain-issued trust
+ anchors:
+
+ o When the low bit is set (PKIX-EE(1) and DANE-EE(3)) the TLSA
+ record matches an EE certificate (also commonly referred to as a
+ leaf or server certificate.)
+
+ o When the low bit is not set (PKIX-TA(0) and DANE-TA(2)) the TLSA
+ record matches a trust anchor (a Certification Authority) that
+ issued one of the certificates in the server certificate chain.
+
+ o When the high bit is set (DANE-TA(2) and DANE-EE(3)), the server
+ certificate chain is domain-issued and may be verified without
+ reference to any pre-existing public certification authority PKI.
+ Trust is entirely placed on the content of the TLSA records
+ obtained via DNSSEC.
+
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 5]
+\f
+Internet-Draft DANE operations August 2014
+
+
+ o When the high bit is not set (PKIX-TA(0) and PKIX-EE(1)), the TLSA
+ record publishes a server policy stating that its certificate
+ chain must pass PKIX validation [RFC5280] and the DANE TLSA record
+ is used to signal an additional requirement that the PKIX
+ validated server certificate chain also contains the referenced CA
+ or EE certificate.
+
+ The selector field specifies whether the TLSA RR matches the whole
+ certificate (Cert(0)) or just its subjectPublicKeyInfo (SPKI(1)).
+ The subjectPublicKeyInfo is an ASN.1 DER encoding of the
+ certificate's algorithm id, any parameters and the public key data.
+
+ The matching type field specifies how the TLSA RR Certificate
+ Association Data field is to be compared with the certificate or
+ public key. A value of Full(0) means an exact match: the full DER
+ encoding of the certificate or public key is given in the TLSA RR. A
+ value of SHA2-256(1) means that the association data matches the
+ SHA2-256 digest of the certificate or public key, and likewise
+ SHA2-512(2) means a SHA2-512 digest is used. Of the two digest
+ algorithms, for now only SHA2-256(1) is mandatory to implement.
+ Clients SHOULD implement SHA2-512(2), but servers SHOULD NOT
+ exclusively publish SHA2-512(2) digests. The digest algorithm
+ agility protocol defined in Section 8 SHOULD be used by clients to
+ decide how to process TLSA RRsets that employ multiple digest
+ algorithms. Server operators MUST publish TLSA RRsets that are
+ compatible with digest algorithm agility.
+
+2.1. Example TLSA record
+
+ In the example TLSA record below:
+
+ _25._tcp.mail.example.com. IN TLSA PKIX-TA Cert SHA2-256 (
+ E8B54E0B4BAA815B06D3462D65FBC7C0
+ CF556ECCF9F5303EBFBB77D022F834C0 )
+
+ The TLSA Certificate Usage is DANE-TA(2), the selector is Cert(0) and
+ the matching type is SHA2-256(1). The last field is the Certificate
+ Association Data Field, which in this case contains the SHA2-256
+ digest of the server certificate.
+
+3. DANE TLS Requirements
+
+ [RFC6698] does not discuss what versions of TLS are required when
+ using DANE records. This document specifies that TLS clients that
+ support DANE/TLSA MUST support at least TLS 1.0 and SHOULD support
+ TLS 1.2. TLS clients and servers using DANE SHOULD support the
+ "Server Name Indication" (SNI) extension of TLS.
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 6]
+\f
+Internet-Draft DANE operations August 2014
+
+
+4. Certificate-Usage-Specific DANE Updates and Guidelines
+
+ The four Certificate Usage values from the TLSA record, DANE-EE(3),
+ DANE-TA(2), PKIX-EE(1) and PKIX-TA(0), are discussed below.
+
+4.1. Certificate Usage DANE-EE(3)
+
+ In this section the meaning of DANE-EE(3) is updated from [RFC6698]
+ to specify that peer identity matching and that validity interval
+ compliance is based solely on the TLSA RRset properties. We also
+ extend [RFC6698] to cover the use of DANE authentication of raw
+ public keys [I-D.ietf-tls-oob-pubkey] via TLSA records with
+ Certificate Usage DANE-EE(3) and selector SPKI(1).
+
+ Authentication via certificate usage DANE-EE(3) TLSA records involves
+ simply checking that the server's leaf certificate matches the TLSA
+ record. In particular, the binding of the server public key to its
+ name is based entirely on the TLSA record association. The server
+ MUST be considered authenticated even if none of the names in the
+ certificate match the client's reference identity for the server.
+
+ Similarly, with DANE-EE(3), the expiration date of the server
+ certificate MUST be ignored. The validity period of the TLSA record
+ key binding is determined by the validity interval of the TLSA record
+ DNSSEC signatures.
+
+ With DANE-EE(3) servers that know all the connecting clients are
+ making use of DANE, they need not employ SNI (i.e., the may ignore
+ the client's SNI message) even when the server is known under
+ multiple domain names that would otherwise require separate
+ certificates. It is instead sufficient for the TLSA RRsets for all
+ the domain names in question to match the server's primary
+ certificate. For application protocols where the server name is
+ obtained indirectly via SRV, MX or similar records, it is simplest to
+ publish a single hostname as the target server name for all the
+ hosted domains.
+
+ In organizations where it is practical to make coordinated changes in
+ DNS TLSA records before server key rotation, it is generally best to
+ publish end-entity DANE-EE(3) certificate associations in preference
+ to other choices of certificate usage. DANE-EE(3) TLSA records
+ support multiple server names without SNI, don't suddenly stop
+ working when leaf or intermediate certificates expire, and don't fail
+ when a server operator neglects to include all the required issuer
+ certificates in the server certificate chain.
+
+ TLSA records published for DANE servers SHOULD, as a best practice,
+ be "DANE-EE(3) SPKI(1) SHA2-256(1)" records. Since all DANE
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 7]
+\f
+Internet-Draft DANE operations August 2014
+
+
+ implementations are required to support SHA2-256, this record type
+ works for all clients and need not change across certificate renewals
+ with the same key. This TLSA record type easily supports hosting
+ arrangements with a single certificate matching all hosted domains.
+ It is also the easiest to implement correctly in the client.
+
+ Another advantage of "DANE-EE(3) SPKI(1)" (with any suitable matching
+ type) TLSA records is that they are compatible with the raw public
+ key TLS extension specified in [I-D.ietf-tls-oob-pubkey]. DANE
+ clients that support this extension can use the TLSA record to
+ authenticate servers that negotiate the use of raw public keys in
+ place of X.509 certificate chains. Provided the server adheres to
+ the requirements of Section 7, the fact that raw public keys are not
+ compatible with any other TLSA record types will not get in the way
+ of successful authentication. Clients that employ DANE to
+ authenticate the peer server SHOULD NOT negotiate the use of raw
+ public keys unless the server's TLSA RRset includes compatible TLSA
+ records.
+
+ While it is, in principle, also possible to authenticate raw public
+ keys via "DANE-EE(3) Cert(0) Full(0)" records by extracting the
+ public key from the certificate in DNS, this is in conflict with the
+ indicated selector and requires extra logic on clients that not all
+ implementations are expected to provide. Servers SHOULD NOT rely on
+ "DANE-EE(3) Cert(0) Full(0)" TLSA records to publish authentication
+ data for raw public keys.
+
+4.2. Certificate Usage DANE-TA(2)
+
+ This section updates [RFC6698] by specifying a new operational
+ requirement for servers publishing TLSA records with a usage of DANE-
+ TA(2): such servers MUST include the trust-anchor certificate in
+ their TLS server certificate message.
+
+ Some domains may prefer to avoid the operational complexity of
+ publishing unique TLSA RRs for each TLS service. If the domain
+ employs a common issuing Certification Authority to create
+ certificates for multiple TLS services, it may be simpler to publish
+ the issuing authority as a trust anchor (TA) for the certificate
+ chains of all relevant services. The TLSA query domain (TLSA base
+ domain with port and protocol prefix labels) for each service issued
+ by the same TA may then be set to a CNAME alias that points to a
+ common TLSA RRset that matches the TA. For example:
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 8]
+\f
+Internet-Draft DANE operations August 2014
+
+
+ www1.example.com. IN A 192.0.2.1
+ www2.example.com. IN A 192.0.2.2
+ _443._tcp.www1.example.com. IN CNAME tlsa201._dane.example.com.
+ _443._tcp.www2.example.com. IN CNAME tlsa201._dane.example.com.
+ tlsa201._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c14...
+
+ With usage DANE-TA(2) the server certificates will need to have names
+ that match one of the client's reference identifiers (see [RFC6125]).
+ The server SHOULD employ SNI to select the appropriate certificate to
+ present to the client.
+
+4.2.1. Recommended record combinations
+
+ TLSA records with selector Full(0) are NOT RECOMMENDED. While these
+ potentially obviate the need to transmit the TA certificate in the
+ TLS server certificate message, client implementations may not be
+ able to augment the server certificate chain with the data obtained
+ from DNS, especially when the TLSA record supplies a bare key
+ (selector SPKI(1)). Since the server will need to transmit the TA
+ certificate in any case, server operators SHOULD publish TLSA records
+ with a selector other than Full(0) and avoid potential DNS
+ interoperability issues with large TLSA records containing full
+ certificates or keys (see Section 9.1.1).
+
+ TLSA Publishers employing DANE-TA(2) records SHOULD publish records
+ with a selector of Cert(0). Such TLSA records are associated with
+ the whole trust anchor certificate, not just with the trust anchor
+ public key. In particular, the client SHOULD then apply any relevant
+ constraints from the trust anchor certificate, such as, for example,
+ path length constraints.
+
+ While a selector of SPKI(1) may also be employed, the resulting TLSA
+ record will not specify the full trust anchor certificate content,
+ and elements of the trust anchor certificate other than the public
+ key become mutable. This may, for example, enable a subsidiary CA to
+ issue a chain that violates the trust anchor's path length or name
+ constraints.
+
+4.2.2. Trust anchor digests and server certificate chain
+
+ With DANE-TA(2) (these TLSA records are expected to match the digest
+ of a TA certificate or public key), a complication arises when the TA
+ certificate is omitted from the server's certificate chain, perhaps
+ on the basis of Section 7.4.2 of [RFC5246]:
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 9]
+\f
+Internet-Draft DANE operations August 2014
+
+
+ The sender's certificate MUST come first in the list. Each
+ following certificate MUST directly certify the one preceding
+ it. Because certificate validation requires that root keys be
+ distributed independently, the self-signed certificate that
+ specifies the root certification authority MAY be omitted from
+ the chain, under the assumption that the remote end must
+ already possess it in order to validate it in any case.
+
+ With TLSA Certificate Usage DANE-TA(2), there is no expectation that
+ the client is pre-configured with the trust anchor certificate. In
+ fact, client implementations are free to ignore all locally
+ configured trust anchors when processing usage DANE-TA(2) TLSA
+ records and may rely exclusively on the certificates provided in the
+ server's certificate chain. But, with a digest in the TLSA record,
+ the TLSA record contains neither the full trust anchor certificate
+ nor the full public key. If the TLS server's certificate chain does
+ not contain the trust anchor certificate, DANE clients will be unable
+ to authenticate the server.
+
+ TLSA Publishers that publish TLSA Certificate Usage DANE-TA(2)
+ associations with a selector of SPKI(1) or using a digest-based
+ matching type (not Full(0)) MUST ensure that the corresponding server
+ is configured to also include the trust anchor certificate in its TLS
+ handshake certificate chain, even if that certificate is a self-
+ signed root CA and would have been optional in the context of the
+ existing public CA PKI.
+
+4.2.3. Trust anchor public keys
+
+ TLSA records with TLSA Certificate Usage DANE-TA(2), selector SPKI(1)
+ and a matching type of Full(0) will publish the full public key of a
+ trust anchor via DNS. In section 6.1.1 of [RFC5280] the definition
+ of a trust anchor consists of the following four parts:
+
+ 1. the trusted issuer name,
+
+ 2. the trusted public key algorithm,
+
+ 3. the trusted public key, and
+
+ 4. optionally, the trusted public key parameters associated with the
+ public key.
+
+ Items 2-4 are precisely the contents of the subjectPublicKeyInfo
+ published in the TLSA record. The issuer name is not included in the
+ subjectPublicKeyInfo.
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 10]
+\f
+Internet-Draft DANE operations August 2014
+
+
+ With TLSA Certificate Usage DANE-TA(2), the client may not have the
+ associated trust anchor certificate, and cannot generally verify
+ whether a particular certificate chain is "issued by" the trust
+ anchor described in the TLSA record.
+
+ When the server certificate chain includes a CA certificate whose
+ public key matches the TLSA record, the client can match that CA as
+ the intended issuer. Otherwise, the client can only check that the
+ topmost certificate in the server's chain is "signed by" the trust
+ anchor's public key in the TLSA record. Such a check may be
+ difficult to implement, and cannot be expected to be supported by all
+ clients.
+
+ Thus, servers should not rely on "DANE-TA(2) SPKI(1) Full(0)" TLSA
+ records to be sufficient to authenticate chains issued by the
+ associated public key in the absence of a corresponding certificate
+ in the server's TLS certificate message. Servers SHOULD include the
+ TA certificate in their certificate chain.
+
+ If none of the server's certificate chain elements match a public key
+ specified in a TLSA record, and at least one "DANE-TA(2) SPKI(1)
+ Full(0)" TLSA record is available, clients are encouraged to check
+ whether the topmost certificate in the chain is signed by the
+ provided public key and has not expired, and in that case consider
+ the server authenticated, provided the rest of the chain passes
+ validation including leaf certificate name checks.
+
+4.3. Certificate Usage PKIX-EE(1)
+
+ This Certificate Usage is similar to DANE-EE(3), but in addition PKIX
+ verification is required. Therefore, name checks, certificate
+ expiration, etc., apply as they would without DANE. When, for a
+ given application protocol, DANE clients support both DANE-EE(3) and
+ PKIX-EE(1) usages, it should be noted that an attacker who can
+ compromise DNSSEC can replace these with usage DANE-EE(3) or DANE-
+ TA(2) TLSA records of their choosing, and thus bypass any PKIX
+ verification requirements.
+
+ Therefore, except when applications support only the PKIX Certificate
+ Usages (0 and 1), this Certificate Usage offers only illusory
+ incremental security over usage DANE-EE(3). It provides lower
+ operational reliability than DANE-EE(3) since some clients may not be
+ configured with the required root CA, the server's chain may be
+ incomplete or name checks may fail. PKIX-EE(1) also requires more
+ complex coordination between the Customer Domain and the Service
+ Provider in hosting arrangements. This certificate usage is NOT
+ RECOMMENDED.
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 11]
+\f
+Internet-Draft DANE operations August 2014
+
+
+4.4. Certificate Usage PKIX-TA(0)
+
+ This section updates [RFC6698] by specifying new client
+ implementation requirements. Clients that trust intermediate
+ certificates MUST be prepared to construct longer PKIX chains than
+ would be required for PKIX alone.
+
+ TLSA Certificate Usage PKIX-TA(0) allows a domain to publish
+ constraints on the set of PKIX certification authorities trusted to
+ issue certificates for its TLS servers. This TLSA record matches
+ PKIX-verified trust chains which contain an issuer certificate (root
+ or intermediate) that matches its association data field (typically a
+ certificate or digest).
+
+ As with PKIX-EE(1) case, an attacker who can compromise DNSSEC can
+ replace these with usage DANE-EE(3) or DANE-TA(2) TLSA records of his
+ choosing and thus bypass the PKIX verification requirements.
+ Therefore, except when applications support only the PKIX Certificate
+ Usages (0 and 1), this Certificate Usage offers only illusory
+ incremental security over usage DANE-TA(2). It provides lower
+ operational reliability than DANE-TA(2) since some clients may not be
+ configured with the required root CA. PKIX-TA(0) also requires more
+ complex coordination between the Customer Domain and the Service
+ Provider in hosting arrangements. This certificate usage is NOT
+ RECOMMENDED.
+
+ TLSA Publishers who publish TLSA records for a particular public root
+ CA, will expect that clients will then only accept chains anchored at
+ that root. It is possible, however, that the client's trusted
+ certificate store includes some intermediate CAs, either with or
+ without the corresponding root CA. When a client constructs a trust
+ chain leading from a trusted intermediate CA to the server leaf
+ certificate, such a "truncated" chain might not contain the trusted
+ root published in the server's TLSA record.
+
+ If the omitted root is also trusted, the client may erroneously
+ reject the server chain if it fails to determine that the shorter
+ chain it constructed extends to a longer trusted chain that matches
+ the TLSA record. Thus, when matching a usage PKIX-TA(0) TLSA record,
+ a client SHOULD NOT always stop extending the chain when the first
+ locally trusted certificate is found. If no TLSA records have
+ matched any of the elements of the chain, and the trusted certificate
+ found is not self-issued, the client MUST attempt to build a longer
+ chain in the hope that a certificate closer to the root may in fact
+ match the server's TLSA record.
+
+4.5. Opportunistic Security and PKIX usages
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 12]
+\f
+Internet-Draft DANE operations August 2014
+
+
+ When the client's protocol design is based on Opportunistic Security
+ (OS, [I-D.dukhovni-opportunistic-security]), and authentication is
+ opportunistically employed based on the presence of server TLSA
+ records, it is especially important to avoid the PKIX-EE(1) and PKIX-
+ TA(0) certificate usages. This is because the client has no way to
+ know in advance that it and the server both trust the requisite root
+ CA. Use of authentication in OS needs to be employed only when the
+ client can be confident of success, absent an attack, or an
+ operational error on the server side.
+
+5. Service Provider and TLSA Publisher Synchronization
+
+ Complications arise when the TLSA Publisher is not the same entity as
+ the Service Provider. In this situation, the TLSA Publisher and the
+ Service Provider must cooperate to ensure that TLSA records published
+ by the TLSA Publisher don't fall out of sync with the server
+ certificate used by the Service Provider.
+
+ Whenever possible, the TLSA Publisher and the Service Provider should
+ be the same entity. Otherwise, changes in the service certificate
+ chain must be carefully coordinated between the parties involved.
+ Such coordination is difficult and service outages will result when
+ coordination fails.
+
+ Having the master TLSA record in the Service Provider's zone avoids
+ the complexity of bilateral coordination of server certificate
+ configuration and TLSA record management. Even when the TLSA RRset
+ must be published in the Customer Domain's DNS zone (perhaps the
+ client application does not "chase" CNAMEs to the TLSA base domain),
+ it is possible to employ CNAME records to delegate the content of the
+ TLSA RRset to a domain operated by the Service Provider. Certificate
+ name checks generally constrain the applicability of TLSA CNAMEs
+ across organizational boundaries to Certificate Usages DANE-EE(3) and
+ DANE-TA(2):
+
+ Certificate Usage DANE-EE(3): In this case the Service Provider can
+ publish a single TLSA RRset that matches the server certificate or
+ public key digest. The same RRset works for all Customer Domains
+ because name checks do not apply with DANE-EE(3) TLSA records (see
+ Section 4.1). A Customer Domain can create a CNAME record
+ pointing to the TLSA RRset published by the Service Provider.
+
+ Certificate Usage DANE-TA(2): When the Service Provider operates a
+ private certification authority, the Service Provider is free to
+ issue a certificate bearing any customer's domain name. Without
+ DANE, such a certificate would not pass trust verification, but
+ with DANE, the customer's TLSA RRset that is aliased to the
+ provider's TLSA RRset can delegate authority to the provider's CA
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 13]
+\f
+Internet-Draft DANE operations August 2014
+
+
+ for the corresponding service. The Service Provider can generate
+ appropriate certificates for each customer and use the SNI
+ information provided by clients to select the right certificate
+ chain to present to each client.
+
+ Below are example DNS records (assumed "secure" and shown without the
+ associated DNSSEC information, such as record signatures) that
+ illustrate both of of the above models in the case of an HTTPS
+ service whose clients all support DANE TLS. These examples work even
+ with clients that don't "chase" CNAMEs when constructing the TLSA
+ base domain (see Section 6 below).
+
+ ; The hosted web service is redirected via a CNAME alias.
+ ; The associated TLSA RRset is also redirected via a CNAME alias.
+ ;
+ ; A single certificate at the provider works for all Customer
+ ; Domains due to the use of the DANE-EE(3) Certificate Usage.
+ ;
+ www1.example.com. IN CNAME w1.example.net.
+ _443._tcp.www1.example.com. IN CNAME _443._tcp.w1.example.net.
+ _443._tcp.w1.example.net. IN TLSA DANE-EE SPKI SHA2-256 (
+ 8A9A70596E869BED72C69D97A8895DFA
+ D86F300A343FECEFF19E89C27C896BC9 )
+
+ ;
+ ; A CA at the provider can also issue certificates for each Customer
+ ; Domain, and use the DANE-TA(2) Certificate Usage type to
+ ; indicate a trust anchor.
+ ;
+ www2.example.com. IN CNAME w2.example.net.
+ _443._tcp.www2.example.com. IN CNAME _443._tcp.w2.example.net.
+ _443._tcp.w2.example.net. IN TLSA DANE-TA Cert SHA2-256 (
+ C164B2C3F36D068D42A6138E446152F5
+ 68615F28C69BD96A73E354CAC88ED00C )
+
+ With protocols that support explicit transport redirection via DNS MX
+ records, SRV records, or other similar records, the TLSA base domain
+ is based on the redirected transport end-point, rather than the
+ origin domain. With SMTP, for example, when an email service is
+ hosted by a Service Provider, the Customer Domain's MX hostnames will
+ point at the Service Provider's SMTP hosts. When the Customer
+ Domain's DNS zone is signed, the MX hostnames can be securely used as
+ the base domains for TLSA records that are published and managed by
+ the Service Provider. For example (without the required DNSSEC
+ information, such as record signatures):
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 14]
+\f
+Internet-Draft DANE operations August 2014
+
+
+ ; Hosted SMTP service
+ ;
+ example.com. IN MX 0 mx1.example.net.
+ example.com. IN MX 0 mx2.example.net.
+ _25._tcp.mx1.example.net. IN TLSA DANE-EE SPKI SHA2-256 (
+ 8A9A70596E869BED72C69D97A8895DFA
+ D86F300A343FECEFF19E89C27C896BC9 )
+ _25._tcp.mx2.example.net. IN TLSA DANE-EE SPKI SHA2-256 (
+ C164B2C3F36D068D42A6138E446152F5
+ 68615F28C69BD96A73E354CAC88ED00C )
+
+ If redirection to the Service Provider's domain (via MX or SRV
+ records or any similar mechanism) is not possible, and aliasing of
+ the TLSA record is not an option, then more complex coordination
+ between the Customer Domain and Service Provider will be required.
+ Either the Customer Domain periodically provides private keys and a
+ corresponding certificate chain to the Provider (after making
+ appropriate changes in its TLSA records), or the Service Provider
+ periodically generates the keys and certificates and must wait for
+ matching TLSA records to be published by its Customer Domains before
+ deploying newly generated keys and certificate chains. In Section 6
+ below, we describe an approach that employs CNAME "chasing" to avoid
+ the difficulties of coordinating key management across organization
+ boundaries.
+
+ For further information about combining DANE and SRV, please see
+ [I-D.ietf-dane-srv].
+
+6. TLSA Base Domain and CNAMEs
+
+ When the application protocol does not support service location
+ indirection via MX, SRV or similar DNS records, the service may be
+ redirected via a CNAME. A CNAME is a more blunt instrument for this
+ purpose, since unlike an MX or SRV record, it remaps the entire
+ origin domain to the target domain for all protocols.
+
+ The complexity of coordinating key management is largely eliminated
+ when DANE TLSA records are found in the Service Provider's domain, as
+ discussed in Section 5. Therefore, DANE TLS clients connecting to a
+ server whose domain name is a CNAME alias SHOULD follow the CNAME
+ hop-by-hop to its ultimate target host (noting at each step whether
+ the CNAME is DNSSEC-validated). If at each stage of CNAME expansion
+ the DNSSEC validation status is "secure", the final target name
+ SHOULD be the preferred base domain for TLSA lookups.
+
+ Implementations failing to find a TLSA record using a base name of
+ the final target of a CNAME expansion SHOULD issue a TLSA query using
+ the original destination name. That is, the preferred TLSA base
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 15]
+\f
+Internet-Draft DANE operations August 2014
+
+
+ domain should be derived from the fully expanded name, and failing
+ that should be the initial domain name.
+
+ When the TLSA base domain is the result of "secure" CNAME expansion,
+ the resulting domain name MUST be used as the HostName in SNI, and
+ MUST be the primary reference identifier for peer certificate
+ matching with certificate usages other than DANE-EE(3).
+
+ Protocol-specific TLSA specifications may provide additional guidance
+ or restrictions when following CNAME expansions.
+
+ Though CNAMEs are illegal on the right hand side of most indirection
+ records, such as MX and SRV records, they are supported by some
+ implementations. For example, if the MX or SRV host is a CNAME
+ alias, some implementations may "chase" the CNAME. If they do, they
+ SHOULD use the target hostname as the preferred TLSA base domain as
+ described above (and if the TLSA records are found there, use the
+ CNAME expanded domain also in SNI and certificate name checks).
+
+7. TLSA Publisher Requirements
+
+ This section updates [RFC6698] by specifying a requirement on the
+ TLSA Publisher to ensure that each combination of Certificate Usage,
+ selector and matching type in the server's TLSA RRset MUST include at
+ least one record that matches the server's current certificate chain.
+ TLSA records that match recently retired or yet to be deployed
+ certificate chains will be present during key rollover. Such past or
+ future records must never be the only records published for any given
+ combination of usage, selector and matching type. We describe a TLSA
+ record update algorithm that ensures this requirement is met.
+
+ While a server is to be considered authenticated when its certificate
+ chain is matched by any of the published TLSA records, not all
+ clients support all combinations of TLSA record parameters. Some
+ clients may not support some digest algorithms, others may either not
+ support, or may exclusively support, the PKIX Certificate Usages.
+ Some clients may prefer to negotiate [I-D.ietf-tls-oob-pubkey] raw
+ public keys, which are only compatible with TLSA records whose
+ Certificate Usage is DANE-EE(3) with selector SPKI(1).
+
+
+
+
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 16]
+\f
+Internet-Draft DANE operations August 2014
+
+
+ A consequence of the above uncertainty as to which TLSA parameters
+ are supported by any given client is that servers need to ensure that
+ each and every parameter combination that appears in the TLSA RRset
+ is, on its own, sufficient to match the server's current certificate
+ chain. In particular, when deploying new keys or new parameter
+ combinations some care is required to not generate parameter
+ combinations that only match past or future certificate chains (or
+ raw public keys). The rest of this section explains how to update
+ the TLSA RRset in a manner that ensures the above requirement is met.
+
+7.1. Key rollover with fixed TLSA Parameters
+
+ The simplest case is key rollover while retaining the same set of
+ published parameter combinations. In this case, TLSA records
+ matching the existing server certificate chain (or raw public keys)
+ are first augmented with corresponding records matching the future
+ keys, at least two TTLs or longer before the the new chain is
+ deployed. This allows the obsolete RRset to age out of client caches
+ before the new chain is used in TLS handshakes. Once sufficient time
+ has elapsed and all clients performing DNS lookups are retrieving the
+ updated TLSA records, the server administrator may deploy the new
+ certificate chain, verify that it works, and then remove any obsolete
+ records matching the no longer active chain:
+
+ ; The initial TLSA RRset
+ ;
+ _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
+
+ ; The transitional TLSA RRset published at least 2*TTL seconds
+ ; before the actual key change
+ ;
+ _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
+ _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
+
+ ; The final TLSA RRset after the key change
+ ;
+ _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
+
+ The next case to consider is adding or switching to a new combination
+ of TLSA parameters. In this case publish the new parameter
+ combinations for the server's existing certificate chain first, and
+ only then deploy new keys if desired:
+
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 17]
+\f
+Internet-Draft DANE operations August 2014
+
+
+ ; Initial TLSA RRset
+ ;
+ _443._tcp.www.example.org. IN TLSA 1 1 1 01d09d19c2139a46...
+
+ ; New TLSA RRset, same key re-published as DANE-EE(3)
+ ;
+ _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
+
+7.2. Switching to DANE-TA from DANE-EE
+
+ A more complex involves switching to a trust-anchor or PKIX usage
+ from a chain that is either self-signed, or issued by a private CA
+ and thus not compatible with PKIX. Here the process is to first add
+ TLSA records matching the future chain that is issued by the desired
+ future CA (private or PKIX), but initially with the same parameters
+ as the legacy chain. Then, after deploying the new keys, switch to
+ the new TLSA parameter combination.
+
+ ; The initial TLSA RRset
+ ;
+ _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
+
+ ; A transitional TLSA RRset, published at least 2*TTL before the
+ ; actual key change. The new keys are issued by a DANE-TA(2) CA,
+ ; but for now specified via a DANE-EE(3) association.
+ ;
+ _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
+ _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
+
+ ; The final TLSA RRset after the key change. Now that the old
+ ; self-signed EE keys are not an impediment, specify the issuing
+ ; TA of the new keys.
+ ;
+ _443._tcp.www.example.org. IN TLSA 2 0 1 c57bce38455d9e3d...
+
+7.3. Switching to New TLSA Parameters
+
+ When employing a new digest algorithm in the TLSA RRset, for
+ compatibility with digest agility specified in Section 8 below,
+ administrators should publish the new digest algorithm with each
+ combinations of Certificate Usage and selector for each associated
+ key or chain used with any other digest algorithm. When removing an
+ algorithm, remove it entirely. Each digest algorithm employed should
+ match the same set of chains (or raw public keys).
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 18]
+\f
+Internet-Draft DANE operations August 2014
+
+
+ ; The initial TLSA RRset with EE SHA2-256 associations for two keys.
+ ;
+ _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
+ _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
+
+ ; The new TLSA RRset also with SHA2-512 associations for each key
+ ;
+ _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
+ _443._tcp.www.example.org. IN TLSA 3 1 2 d9947c35089310bc...
+ _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
+ _443._tcp.www.example.org. IN TLSA 3 1 2 89a7486a4b6ae714...
+
+7.4. TLSA Publisher Requirements Summary
+
+ In summary, server operators updating TLSA records should make one
+ change at a time. The individual safe changes are:
+
+ o Pre-publish new certificate associations that employ the same TLSA
+ parameters (usage, selector and matching type) as existing TLSA
+ records, but match certificate chains that will be deployed in the
+ near future. Wait for stale TLSA RRsets to expire from DNS caches
+ before configuring servers to use the new certificate chain.
+
+ o Remove TLSA records matching no longer deployed certificate
+ chains.
+
+ o Extend the TLSA RRset with a new combination of parameters (usage,
+ selector and matching type) that is used to generate matching
+ associations for all certificate chains that are published with
+ some other parameter combination.
+
+ The above steps are intended to ensure that at all times and for each
+ combination of usage, selector and matching type at least one TLSA
+ record corresponds to the server's current certificate chain. No
+ combination of Certificate Usage, selector and matching type in a
+ server's TLSA RRset should ever match only some combination of future
+ or past certificate chains. As a result, no matter what combinations
+ of usage, selector and matching type may be supported by a given
+ client, they will be sufficient to authenticate the server.
+
+8. Digest Algorithm Agility
+
+
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 19]
+\f
+Internet-Draft DANE operations August 2014
+
+
+ While [RFC6698] specifies multiple digest algorithms, it does not
+ specify a protocol by which the TLS client and TLSA record publisher
+ can agree on the strongest shared algorithm. Such a protocol would
+ allow the client and server to avoid exposure to any deprecated
+ weaker algorithms that are published for compatibility with less
+ capable clients, but should be ignored when possible. We specify
+ such a protocol below.
+
+ Suppose that a DANE TLS client authenticating a TLS server considers
+ digest algorithm "BetterAlg" stronger than digest algorithm
+ "WorseAlg". Suppose further that a server's TLSA RRset contains some
+ records with "BetterAlg" as the digest algorithm. Suppose also that
+ the server adheres to the requirements of Section 7 and ensures that
+ each combination of TLSA parameters contains at least one record that
+ matches the server's current certificate chain (or raw public keys).
+ Under the above assumptions the client can safely ignore TLSA records
+ with the weaker algorithm "WorseAlg", because it suffices to only
+ check the records with the stronger algorithm "BetterAlg".
+
+ To make digest algorithm agility possible, all published TLSA RRsets
+ for use with DANE TLS MUST conform to the requirements of Section 7.
+ With servers publishing compliant TLSA RRsets, TLS clients can, for
+ each combination of usage and selector, ignore all digest records
+ except those that employ their notion of the strongest digest
+ algorithm. (The server should only publish algorithms it deems
+ acceptable at all.) The ordering of digest algorithms by strength is
+ not specified in advance; it is entirely up to the TLS client. TLS
+ client implementations SHOULD make the digest algorithm preference
+ ordering a configurable option.
+
+ Note, TLSA records with a matching type of Full(0) that publish an
+ entire certificate or public key object play no role in digest
+ algorithm agility. They neither trump the processing of records that
+ employ digests, nor are they ignored in the presence of any records
+ with a digest (i.e. non-zero) matching type.
+
+ TLS clients SHOULD use digest algorithm agility when processing the
+ DANE TLSA records of an TLS server. Algorithm agility is to be
+ applied after first discarding any unusable or malformed records
+ (unsupported digest algorithm, or incorrect digest length). Thus,
+ for each usage and selector, the client SHOULD process only any
+ usable records with a matching type of Full(0) and the usable records
+ whose digest algorithm is considered by the client to be the
+ strongest among usable records with the given usage and selector.
+
+9. General DANE Guidelines
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 20]
+\f
+Internet-Draft DANE operations August 2014
+
+
+ These guidelines provide guidance for using or designing protocols
+ for DANE.
+
+9.1. DANE DNS Record Size Guidelines
+
+ Selecting a combination of TLSA parameters to use requires careful
+ thought. One important consideration to take into account is the
+ size of the resulting TLSA record after its parameters are selected.
+
+9.1.1. UDP and TCP Considerations
+
+ Deployments SHOULD avoid TLSA record sizes that cause UDP
+ fragmentation.
+
+ Although DNS over TCP would provide the ability to more easily
+ transfer larger DNS records between clients and servers, it is not
+ universally deployed and is still prohibited by some firewalls.
+ Clients that request DNS records via UDP typically only use TCP upon
+ receipt of a truncated response in the DNS response message sent over
+ UDP. Setting the TC bit alone will be insufficient if the response
+ containing the TC bit is itself fragmented.
+
+9.1.2. Packet Size Considerations for TLSA Parameters
+
+ Server operators SHOULD NOT publish TLSA records using both a TLSA
+ Selector of Cert(0) and a TLSA Matching Type of Full(0), as even a
+ single certificate is generally too large to be reliably delivered
+ via DNS over UDP. Furthermore, two TLSA records containing full
+ certificates will need to be published simultaneously during a
+ certificate rollover, as discussed in Section 7.1.
+
+ While TLSA records using a TLSA Selector of SPKI(1) and a TLSA
+ Matching Type of Full(0) (which publish the bare public keys without
+ the overhead of a containing X.509 certificate) are generally more
+ compact, these too should be used with caution as they are still
+ larger than necessary. Rather, servers SHOULD publish digest-based
+ TLSA Matching Types in their TLSA records. The complete
+ corresponding certificate should, instead, be transmitted to the
+ client in-band during the TLS handshake, which can be easily verified
+ using the digest value.
+
+ In summary, the use of a TLSA Matching Type of Full(0) is NOT
+ RECOMMENDED and the use of a digest-based matching type, such as
+ SHA2-256(1) SHOULD be used.
+
+9.2. Certificate Name Check Conventions
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 21]
+\f
+Internet-Draft DANE operations August 2014
+
+
+ Certificates presented by a TLS server will generally contain a
+ subjectAltName (SAN) extension or a Common Name (CN) element within
+ the subject distinguished name (DN). The TLS server's DNS domain
+ name is normally published within these elements, ideally within the
+ subjectAltName extension. (The use of the CN field for this purpose
+ is deprecated.)
+
+ When a server hosts multiple domains at the same transport endpoint,
+ the server's ability to respond with the right certificate chain is
+ predicated on correct SNI information from the client. DANE clients
+ MUST send the SNI extension with a HostName value of the base domain
+ of the TLSA RRset.
+
+ Except with TLSA Certificate Usage DANE-EE(3), where name checks are
+ not applicable (see Section 4.1), DANE clients MUST verify that the
+ client has reached the correct server by checking that the server
+ name is listed in the server certificate's SAN or CN. The server
+ name used for this comparison SHOULD be the base domain of the TLSA
+ RRset. Additional acceptable names may be specified by protocol-
+ specific DANE standards. For example, with SMTP both the destination
+ domain name and the MX host name are acceptable names to be found in
+ the server certificate (see [I-D.ietf-dane-smtp-with-dane]).
+
+ It is the responsibility of the service operator, in coordination
+ with the TLSA Publisher, to ensure that at least one of the TLSA
+ records published for the service will match the server's certificate
+ chain (either the default chain or the certificate that was selected
+ based on the SNI information provided by the client).
+
+ Given the DNSSEC validated DNS records below:
+
+ example.com. IN MX 0 mail.example.com.
+ mail.example.com. IN A 192.0.2.1
+ _25._tcp.mail.example.com. IN TLSA DANE-TA Cert SHA2-256 (
+ E8B54E0B4BAA815B06D3462D65FBC7C0
+ CF556ECCF9F5303EBFBB77D022F834C0 )
+
+ The TLSA base domain is "mail.example.com" and is required to be the
+ HostName in the client's SNI extension. The server certificate chain
+ is required to be be signed by a trust anchor with the above
+ certificate SHA2-256 digest. Finally, one of the DNS names in the
+ server certificate is required to be be either "mail.example.com" or
+ "example.com" (this additional name is a concession to compatibility
+ with prior practice, see [I-D.ietf-dane-smtp-with-dane] for details).
+
+ The semantics of wildcards in server certificates are left to
+ individual application protocol specifications.
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 22]
+\f
+Internet-Draft DANE operations August 2014
+
+
+9.3. Design Considerations for Protocols Using DANE
+
+ When a TLS client goes to the trouble of authenticating a certificate
+ chain presented by a TLS server, it will typically not continue to
+ use that server in the event of authentication failure, or else
+ authentication serves no purpose. Some clients may, at times,
+ operate in an "audit" mode, where authentication failure is reported
+ to the user or in logs as a potential problem, but the connection
+ proceeds despite the failure. Nevertheless servers publishing TLSA
+ records MUST be configured to allow correctly configured clients to
+ successfully authenticate their TLS certificate chains.
+
+ A service with DNSSEC-validated TLSA records implicitly promises TLS
+ support. When all the TLSA records for a service are found
+ "unusable", due to unsupported parameter combinations or malformed
+ associated data, DANE clients cannot authenticate the service
+ certificate chain. When authenticated TLS is dictated by the
+ application, the client SHOULD NOT connect to the associated server.
+ If, on the other hand, the use of TLS is "opportunistic", then the
+ client SHOULD generally use the server via an unauthenticated TLS
+ connection, but if TLS encryption cannot be established, the client
+ MUST NOT use the server. Standards for DANE specific to the
+ particular application protocol may modify the above requirements, as
+ appropriate, to specify whether the connection should be established
+ anyway without relying on TLS security, with only encryption but not
+ authentication, or whether to refuse to connect entirely.
+ Application protocols need to specify when to prioritize security
+ over the ability to connect under adverse conditions.
+
+9.3.1. Design Considerations for non-PKIX Protocols
+
+ For some application protocols (such as SMTP to MX with opportunistic
+ TLS), the existing public CA PKI is not a viable alternative to DANE.
+ For these (non-PKIX) protocols, new DANE standards SHOULD NOT suggest
+ publishing TLSA records with TLSA Certificate Usage PKIX-TA(0) or
+ PKIX-EE(1), as TLS clients cannot be expected to perform [RFC5280]
+ PKIX validation or [RFC6125] identity verification.
+
+ Protocols designed for non-PKIX use SHOULD choose to treat any TLSA
+ records with TLSA Certificate Usage PKIX-TA(0) or PKIX-EE(1) as
+ unusable. After verifying that the only available TLSA Certificate
+ Usage types are PKIX-TA(0) or PKIX-EE(1), protocol specifications MAY
+ instruct clients to either refuse to initiate a connection or to
+ connect via unauthenticated TLS if no alternative authentication
+ mechanisms are available.
+
+10. Interaction with Certificate Transparency
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 23]
+\f
+Internet-Draft DANE operations August 2014
+
+
+ Certificate Transparency (CT) [RFC6962] defines an experimental
+ approach to mitigate the risk of rogue or compromised public CAs
+ issuing unauthorized certificates. This section clarifies the
+ interaction of CT and DANE. CT is an experimental protocol and
+ auditing system that applies only to public CAs, and only when they
+ are free to issue unauthorized certificates for a domain. If the CA
+ is not a public CA, or a DANE-EE(3) TLSA RR directly specifies the
+ end entity certificate, there is no role for CT, and clients need not
+ apply CT checks.
+
+ When a server is authenticated via a DANE TLSA RR with TLSA
+ Certificate Usage DANE-EE(3), the domain owner has directly specified
+ the certificate associated with the given service without reference
+ to any PKIX certification authority. Therefore, when a TLS client
+ authenticates the TLS server via a TLSA certificate association with
+ usage DANE-EE(3), CT checks SHOULD NOT be performed. Publication of
+ the server certificate or public key (digest) in a TLSA record in a
+ DNSSEC signed zone by the domain owner assures the TLS client that
+ the certificate is not an unauthorized certificate issued by a rogue
+ CA without the domain owner's consent.
+
+ When a server is authenticated via a DANE TLSA RR with TLSA usage
+ DANE-TA(2) and the server certificate does not chain to a known
+ public root CA, CT cannot apply (CT logs only accept chains that
+ start with a known, public root). Since TLSA Certificate Usage DANE-
+ TA(2) is generally intended to support non-PKIX trust anchors, TLS
+ clients SHOULD NOT perform CT checks with usage DANE-TA(2) using
+ unknown root CAs.
+
+ A server operator who wants clients to perform CT checks should
+ publish TLSA RRs with usage PKIX-TA(0) or PKIX-EE(1).
+
+11. Note on DNSSEC Security
+
+ Clearly the security of the DANE TLSA PKI rests on the security of
+ the underlying DNSSEC infrastructure. While this memo is not a guide
+ to DNSSEC security, a few comments may be helpful to TLSA
+ implementers.
+
+ With the existing public CA PKI, name constraints are rarely used,
+ and a public root CA can issue certificates for any domain of its
+ choice. With DNSSEC, under the Registry/Registrar/Registrant model,
+ the situation is different: only the registrar of record can update a
+ domain's DS record in the registry parent zone (in some cases,
+ however, the registry is the sole registrar). With many gTLDs, for
+ which multiple registrars compete to provide domains in a single
+ registry, it is important to make sure that rogue registrars cannot
+ easily initiate an unauthorized domain transfer, and thus take over
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 24]
+\f
+Internet-Draft DANE operations August 2014
+
+
+ DNSSEC for the domain. DNS Operators SHOULD use a registrar lock of
+ their domains to offer some protection against this possibility.
+
+ When the registrar is also the DNS operator for the domain, one needs
+ to consider whether the registrar will allow orderly migration of the
+ domain to another registrar or DNS operator in a way that will
+ maintain DNSSEC integrity. TLSA Publishers SHOULD ensure their
+ registrar publishes a suitable domain transfer policy.
+
+ DNSSEC signed RRsets cannot be securely revoked before they expire.
+ Operators should plan accordingly and not generate signatures with
+ excessively long duration periods. For domains publishing high-value
+ keys, a signature lifetime of a few days is reasonable, and the zone
+ should be resigned daily. For domains with less critical data, a
+ reasonable signature lifetime is a couple of weeks to a month, and
+ the zone should be resigned weekly. Monitoring of the signature
+ lifetime is important. If the zone is not resigned in a timely
+ manner, one risks a major outage and the entire domain will become
+ bogus.
+
+12. Summary of Updates to RFC6698
+
+ Authors note: is this section needed? Or is it sufficiently clear
+ above that we don't need to restate things here?
+
+ o In Section 3 we update [RFC6698] to specify a requirement for
+ clients to support at least TLS 1.0, and to support SNI.
+
+ o In Section 4.1 we update [RFC6698] to specify peer identity
+ matching and certificate validity interval based solely on the
+ basis of the TLSA RRset. We also specify DANE authentication of
+ raw public keys [I-D.ietf-tls-oob-pubkey] via TLSA records with
+ Certificate Usage DANE-EE(3) and selector SPKI(1).
+
+ o In Section 4.2 we update [RFC6698] to require that servers
+ publishing digest TLSA records with a usage of DANE-TA(2) MUST
+ include the trust-anchor certificate in their TLS server
+ certificate message. This extends to the case of "2 1 0" TLSA
+ records which publish a full public key.
+
+ o In Section 4.3 and Section 4.4, we explain that PKIX-EE(1) and
+ PKIX-TA(0) are generally NOT RECOMMENDED. With usage PKIX-TA(0)
+ we note that clients may need to processes extended trust chains
+ beyond the first trusted issuer, when that issuer is not self-
+ signed.
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 25]
+\f
+Internet-Draft DANE operations August 2014
+
+
+ o In Section 6, we recommend that DANE application protocols specify
+ that when possible securely CNAME expanded names be used to derive
+ the TLSA base domain.
+
+ o In Section 7, we specify a strategy for managing TLSA records that
+ interoperates with DANE clients regardless of what subset of the
+ possible TLSA record types (combinations of TLSA parameters) is
+ supported by the client.
+
+ o In Section 8, we propose a digest algorithm agility protocol.
+ [Note: This section does not yet represent the rough consensus of
+ the DANE working group and requires further discussion. Perhaps
+ this belongs in a separate document.]
+
+ o In Section 9.1 we recommend against the use of Full(0) TLSA
+ records, as digest records are generally much more compact.
+
+13. Security Considerations
+
+ Application protocols that cannot make use of the existing public CA
+ PKI (so called non-PKIX protocols), may choose not to implement
+ certain PKIX-dependent TLSA record types defined in [RFC6698]. If
+ such records are published despite not being supported by the
+ application protocol, they are treated as "unusable". When TLS is
+ opportunistic, the client may proceed to use the server with
+ mandatory unauthenticated TLS. This is stronger than opportunistic
+ TLS without DANE, since in that case the client may also proceed with
+ a plaintext connection. When TLS is not opportunistic, the client
+ MUST NOT connect to the server.
+
+ Therefore, when TLSA records are used with protocols where PKIX does
+ not apply, the recommended policy is for servers to not publish PKIX-
+ dependent TLSA records, and for opportunistic TLS clients to use them
+ to enforce the use of (albeit unauthenticated) TLS, but otherwise
+ treat them as unusable. Of course, when PKIX validation is supported
+ by the application protocol, clients SHOULD perform PKIX validation
+ per [RFC6698].
+
+14. IANA Considerations
+
+ This specification requires no support from IANA.
+
+15. Acknowledgements
+
+ The authors would like to thank Phil Pennock for his comments and
+ advice on this document.
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 26]
+\f
+Internet-Draft DANE operations August 2014
+
+
+ Acknowledgments from Viktor: Thanks to Tony Finch who finally prodded
+ me into participating in DANE working group discussions. Thanks to
+ Paul Hoffman who motivated me to produce this memo and provided
+ feedback on early drafts. Thanks also to Samuel Dukhovni for
+ editorial assistance.
+
+16. References
+
+16.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "DNS Security Introduction and Requirements", RFC
+ 4033, March 2005.
+
+ [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Resource Records for the DNS Security Extensions",
+ RFC 4034, March 2005.
+
+ [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Protocol Modifications for the DNS Security
+ Extensions", RFC 4035, March 2005.
+
+ [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+ [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, May 2008.
+
+ [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
+ Extension Definitions", RFC 6066, January 2011.
+
+ [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, March 2011.
+
+ [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+ Security Version 1.2", RFC 6347, January 2012.
+
+ [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
+ of Named Entities (DANE) Transport Layer Security (TLS)
+ Protocol: TLSA", RFC 6698, August 2012.
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 27]
+\f
+Internet-Draft DANE operations August 2014
+
+
+ [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify
+ Conversations about DNS-Based Authentication of Named
+ Entities (DANE)", RFC 7218, April 2014.
+
+16.2. Informative References
+
+ [I-D.dukhovni-opportunistic-security]
+ Dukhovni, V., "Opportunistic Security: Some Protection
+ Most of the Time", draft-dukhovni-opportunistic-
+ security-03 (work in progress), August 2014.
+
+ [I-D.ietf-dane-smtp-with-dane]
+ Dukhovni, V. and W. Hardaker, "SMTP security via
+ opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-11
+ (work in progress), August 2014.
+
+ [I-D.ietf-dane-srv]
+ Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-
+ Based Authentication of Named Entities (DANE) TLSA Records
+ with SRV Records", draft-ietf-dane-srv-07 (work in
+ progress), July 2014.
+
+ [I-D.ietf-tls-oob-pubkey]
+ Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and
+ T. Kivinen, "Using Raw Public Keys in Transport Layer
+ Security (TLS) and Datagram Transport Layer Security
+ (DTLS)", draft-ietf-tls-oob-pubkey-11 (work in progress),
+ January 2014.
+
+ [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
+ Transparency", RFC 6962, June 2013.
+
+Authors' Addresses
+
+ Viktor Dukhovni
+ Unaffiliated
+
+ Email: ietf-dane@dukhovni.org
+
+
+ Wes Hardaker
+ Parsons
+ P.O. Box 382
+ Davis, CA 95617
+ US
+
+ Email: ietf@hardakers.net
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 28]
--- /dev/null
+
+
+
+
+DANE V. Dukhovni
+Internet-Draft Two Sigma
+Intended status: Standards Track W. Hardaker
+Expires: November 26, 2014 Parsons
+ May 25, 2014
+
+
+ SMTP security via opportunistic DANE TLS
+ draft-ietf-dane-smtp-with-dane-10
+
+Abstract
+
+ This memo describes a downgrade-resistant protocol for SMTP transport
+ security between Mail Transfer Agents (MTAs) based on the DNS-Based
+ Authentication of Named Entities (DANE) TLSA DNS record. Adoption of
+ this protocol enables an incremental transition of the Internet email
+ backbone to one using encrypted and authenticated Transport Layer
+ Security (TLS).
+
+Status of This Memo
+
+ This Internet-Draft is submitted in full conformance with the
+ provisions of BCP 78 and BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF). Note that other groups may also distribute
+ working documents as Internet-Drafts. The list of current Internet-
+ Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ This Internet-Draft will expire on November 26, 2014.
+
+Copyright Notice
+
+ Copyright (c) 2014 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
+
+
+
+Dukhovni & Hardaker Expires November 26, 2014 [Page 1]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+
+
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 5
+ 1.3. SMTP channel security . . . . . . . . . . . . . . . . . . 6
+ 1.3.1. STARTTLS downgrade attack . . . . . . . . . . . . . . 6
+ 1.3.2. Insecure server name without DNSSEC . . . . . . . . . 7
+ 1.3.3. Sender policy does not scale . . . . . . . . . . . . 7
+ 1.3.4. Too many certification authorities . . . . . . . . . 8
+ 2. Identifying applicable TLSA records . . . . . . . . . . . . . 8
+ 2.1. DNS considerations . . . . . . . . . . . . . . . . . . . 8
+ 2.1.1. DNS errors, bogus and indeterminate responses . . . . 8
+ 2.1.2. DNS error handling . . . . . . . . . . . . . . . . . 11
+ 2.1.3. Stub resolver considerations . . . . . . . . . . . . 11
+ 2.2. TLS discovery . . . . . . . . . . . . . . . . . . . . . . 12
+ 2.2.1. MX resolution . . . . . . . . . . . . . . . . . . . . 13
+ 2.2.2. Non-MX destinations . . . . . . . . . . . . . . . . . 15
+ 2.2.3. TLSA record lookup . . . . . . . . . . . . . . . . . 17
+ 3. DANE authentication . . . . . . . . . . . . . . . . . . . . . 19
+ 3.1. TLSA certificate usages . . . . . . . . . . . . . . . . . 19
+ 3.1.1. Certificate usage DANE-EE(3) . . . . . . . . . . . . 20
+ 3.1.2. Certificate usage DANE-TA(2) . . . . . . . . . . . . 21
+ 3.1.3. Certificate usages PKIX-TA(0) and PKIX-EE(1) . . . . 22
+ 3.2. Certificate matching . . . . . . . . . . . . . . . . . . 23
+ 3.2.1. DANE-EE(3) name checks . . . . . . . . . . . . . . . 23
+ 3.2.2. DANE-TA(2) name checks . . . . . . . . . . . . . . . 23
+ 3.2.3. Reference identifier matching . . . . . . . . . . . . 24
+ 4. Server key management . . . . . . . . . . . . . . . . . . . . 25
+ 5. Digest algorithm agility . . . . . . . . . . . . . . . . . . 26
+ 6. Mandatory TLS Security . . . . . . . . . . . . . . . . . . . 27
+ 7. Note on DANE for Message User Agents . . . . . . . . . . . . 28
+ 8. Interoperability considerations . . . . . . . . . . . . . . . 29
+ 8.1. SNI support . . . . . . . . . . . . . . . . . . . . . . . 29
+ 8.2. Anonymous TLS cipher suites . . . . . . . . . . . . . . . 29
+ 9. Operational Considerations . . . . . . . . . . . . . . . . . 30
+ 9.1. Client Operational Considerations . . . . . . . . . . . . 30
+ 9.2. Publisher Operational Considerations . . . . . . . . . . 30
+ 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31
+ 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 31
+ 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
+ 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
+ 13.1. Normative References . . . . . . . . . . . . . . . . . . 32
+ 13.2. Informative References . . . . . . . . . . . . . . . . . 33
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
+
+
+
+Dukhovni & Hardaker Expires November 26, 2014 [Page 2]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+
+
+1. Introduction
+
+ This memo specifies a new connection security model for Message
+ Transfer Agents (MTAs). This model is motivated by key features of
+ inter-domain SMTP delivery, in particular the fact that the
+ destination server is selected indirectly via DNS Mail Exchange (MX)
+ records and that neither email addresses nor MX hostnames signal a
+ requirement for either secure or cleartext transport. Therefore,
+ aside from a few manually configured exceptions, SMTP transport
+ security is of necessity opportunistic.
+
+ This specification uses the presence of DANE TLSA records to securely
+ signal TLS support and to publish the means by which SMTP clients can
+ successfully authenticate legitimate SMTP servers. This becomes
+ "opportunistic DANE TLS" and is resistant to downgrade and MITM
+ attacks. It enables an incremental transition of the email backbone
+ to authenticated TLS delivery, with increased global protection as
+ adoption increases.
+
+ With opportunistic DANE TLS, traffic from SMTP clients to domains
+ that publish "usable" DANE TLSA records in accordance with this memo
+ is authenticated and encrypted. Traffic from legacy clients or to
+ domains that do not publish TLSA records will continue to be sent in
+ the same manner as before, via manually configured security, (pre-
+ DANE) opportunistic TLS or just cleartext SMTP.
+
+ Problems with existing use of TLS in MTA to MTA SMTP that motivate
+ this specification are described in Section 1.3. The specification
+ itself follows in Section 2 and Section 3 which describe respectively
+ how to locate and use DANE TLSA records with SMTP. In Section 6, we
+ discuss application of DANE TLS to destinations for which channel
+ integrity and confidentiality are mandatory. In Section 7 we briefly
+ comment on potential applicability of this specification to Message
+ User Agents.
+
+1.1. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ [RFC2119].
+
+ The following terms or concepts are used through the document:
+
+ Man-in-the-middle or MITM attack: Active modification of network
+ traffic by an adversary able to thereby compromise the
+ confidentiality or integrity of the data.
+
+
+
+
+Dukhovni & Hardaker Expires November 26, 2014 [Page 3]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+
+
+ secure, bogus, insecure, indeterminate: DNSSEC validation results,
+ as defined in Section 4.3 of [RFC4035].
+
+ Validating Security-Aware Stub Resolver and Non-Validating
+ Security-Aware Stub Resolver:
+ Capabilities of the stub resolver in use as defined in [RFC4033];
+ note that this specification requires the use of a Security-Aware
+ Stub Resolver; Security-Oblivious stub-resolvers MUST NOT be used.
+
+ opportunistic DANE TLS: Best-effort use of TLS, resistant to
+ downgrade attacks for destinations with DNSSEC-validated TLSA
+ records. When opportunistic DANE TLS is determined to be
+ unavailable, clients should fall back to opportunistic TLS below.
+ Opportunistic DANE TLS requires support for DNSSEC, DANE and
+ STARTTLS on the client side and STARTTLS plus a DNSSEC published
+ TLSA record on the server side.
+
+ (pre-DANE) opportunistic TLS: Best-effort use of TLS that is
+ generally vulnerable to DNS forgery and STARTTLS downgrade
+ attacks. When a TLS-encrypted communication channel is not
+ available, message transmission takes place in the clear. MX
+ record indirection generally precludes authentication even when
+ TLS is available.
+
+ reference identifier: (Special case of [RFC6125] definition). One
+ of the domain names associated by the SMTP client with the
+ destination SMTP server for performing name checks on the server
+ certificate. When name checks are applicable, at least one of the
+ reference identifiers MUST match an [RFC6125] DNS-ID (or if none
+ are present the [RFC6125] CN-ID) of the server certificate (see
+ Section 3.2.3).
+
+ MX hostname: The RRDATA of an MX record consists of a 16 bit
+ preference followed by a Mail Exchange domain name (see [RFC1035],
+ Section 3.3.9). We will use the term "MX hostname" to refer to
+ the latter, that is, the DNS domain name found after the
+ preference value in an MX record. Thus an "MX hostname" is
+ specifically a reference to a DNS domain name, rather than any
+ host that bears that name.
+
+ delayed delivery: Email delivery is a multi-hop store & forward
+ process. When an MTA is unable forward a message that may become
+ deliverable later, the message is queued and delivery is retried
+ periodically. Some MTAs may be configured with a fallback next-
+ hop destination that handles messages that the MTA would otherwise
+ queue and retry. In these cases, messages that would otherwise
+ have to be delayed, may be sent to the fallback next-hop
+ destination instead. The fallback destination may itself be
+
+
+
+Dukhovni & Hardaker Expires November 26, 2014 [Page 4]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+
+
+ subject to opportunistic or mandatory DANE TLS as though it were
+ the original message destination.
+
+ original next hop destination: The logical destination for mail
+ delivery. By default this is the domain portion of the recipient
+ address, but MTAs may be configured to forward mail for some or
+ all recipients via designated relays. The original next hop
+ destination is, respectively, either the recipient domain or the
+ associated configured relay.
+
+ MTA: Message Transfer Agent ([RFC5598], Section 4.3.2).
+
+ MSA: Message Submission Agent ([RFC5598], Section 4.3.1).
+
+ MUA: Message User Agent ([RFC5598], Section 4.2.1).
+
+ RR: A DNS Resource Record
+
+ RRset: A set of DNS Resource Records for a particular class, domain
+ and record type.
+
+1.2. Background
+
+ The Domain Name System Security Extensions (DNSSEC) add data origin
+ authentication, data integrity and data non-existence proofs to the
+ Domain Name System (DNS). DNSSEC is defined in [RFC4033], [RFC4034]
+ and [RFC4035].
+
+ As described in the introduction of [RFC6698], TLS authentication via
+ the existing public Certification Authority (CA) PKI suffers from an
+ over-abundance of trusted parties capable of issuing certificates for
+ any domain of their choice. DANE leverages the DNSSEC infrastructure
+ to publish trusted public keys and certificates for use with the
+ Transport Layer Security (TLS) [RFC5246] protocol via a new "TLSA"
+ DNS record type. With DNSSEC each domain can only vouch for the keys
+ of its directly delegated sub-domains.
+
+ The TLS protocol enables secure TCP communication. In the context of
+ this memo, channel security is assumed to be provided by TLS. Used
+ without authentication, TLS provides only privacy protection against
+ eavesdropping attacks. With authentication, TLS also provides data
+ integrity protection to guard against MITM attacks.
+
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires November 26, 2014 [Page 5]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+
+
+1.3. SMTP channel security
+
+ With HTTPS, Transport Layer Security (TLS) employs X.509 certificates
+ [RFC5280] issued by one of the many Certificate Authorities (CAs)
+ bundled with popular web browsers to allow users to authenticate
+ their "secure" websites. Before we specify a new DANE TLS security
+ model for SMTP, we will explain why a new security model is needed.
+ In the process, we will explain why the familiar HTTPS security model
+ is inadequate to protect inter-domain SMTP traffic.
+
+ The subsections below outline four key problems with applying
+ traditional PKI to SMTP that are addressed by this specification.
+ Since SMTP channel security policy is not explicitly specified in
+ either the recipient address or the MX record, a new signaling
+ mechanism is required to indicate when channel security is possible
+ and should be used. The publication of TLSA records allows server
+ operators to securely signal to SMTP clients that TLS is available
+ and should be used. DANE TLSA makes it possible to simultaneously
+ discover which destination domains support secure delivery via TLS
+ and how to verify the authenticity of the associated SMTP services,
+ providing a path forward to ubiquitous SMTP channel security.
+
+1.3.1. STARTTLS downgrade attack
+
+ The Simple Mail Transfer Protocol (SMTP) [RFC5321] is a single-hop
+ protocol in a multi-hop store & forward email delivery process. SMTP
+ envelope recipient addresses are not transport addresses and are
+ security-agnostic. Unlike the Hypertext Transfer Protocol (HTTP) and
+ its corresponding secured version, HTTPS, where the use of TLS is
+ signaled via the URI scheme, email recipient addresses do not
+ directly signal transport security policy. Indeed, no such signaling
+ could work well with SMTP since TLS encryption of SMTP protects email
+ traffic on a hop-by-hop basis while email addresses could only
+ express end-to-end policy.
+
+ With no mechanism available to signal transport security policy, SMTP
+ relays employ a best-effort "opportunistic" security model for TLS.
+ A single SMTP server TCP listening endpoint can serve both TLS and
+ non-TLS clients; the use of TLS is negotiated via the SMTP STARTTLS
+ command ([RFC3207]). The server signals TLS support to the client
+ over a cleartext SMTP connection, and, if the client also supports
+ TLS, it may negotiate a TLS encrypted channel to use for email
+ transmission. The server's indication of TLS support can be easily
+ suppressed by an MITM attacker. Thus pre-DANE SMTP TLS security can
+ be subverted by simply downgrading a connection to cleartext. No TLS
+ security feature, such as the use of PKIX, can prevent this. The
+ attacker can simply disable TLS.
+
+
+
+
+Dukhovni & Hardaker Expires November 26, 2014 [Page 6]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+
+
+1.3.2. Insecure server name without DNSSEC
+
+ With SMTP, DNS Mail Exchange (MX) records abstract the next-hop
+ transport endpoint and allow administrators to specify a set of
+ target servers to which SMTP traffic should be directed for a given
+ domain.
+
+ A PKIX TLS client is vulnerable to MITM attacks unless it verifies
+ that the server's certificate binds the public key to a name that
+ matches one of the client's reference identifiers. A natural choice
+ of reference identifier is the server's domain name. However, with
+ SMTP, server names are obtained indirectly via MX records. Without
+ DNSSEC, the MX lookup is vulnerable to MITM and DNS cache poisoning
+ attacks. Active attackers can forge DNS replies with fake MX records
+ and can redirect email to servers with names of their choice.
+ Therefore, secure verification of SMTP TLS certificates matching the
+ server name is not possible without DNSSEC.
+
+ One might try to harden TLS for SMTP against DNS attacks by using the
+ envelope recipient domain as a reference identifier and requiring
+ each SMTP server to possess a trusted certificate for the envelope
+ recipient domain rather than the MX hostname. Unfortunately, this is
+ impractical as email for many domains is handled by third parties
+ that are not in a position to obtain certificates for all the domains
+ they serve. Deployment of the Server Name Indication (SNI) extension
+ to TLS (see [RFC6066] Section 3) is no panacea, since SNI key
+ management is operationally challenging except when the email service
+ provider is also the domain's registrar and its certificate issuer;
+ this is rarely the case for email.
+
+ Since the recipient domain name cannot be used as the SMTP server
+ reference identifier, and neither can the MX hostname without DNSSEC,
+ large-scale deployment of authenticated TLS for SMTP requires that
+ the DNS be secure.
+
+ Since SMTP security depends critically on DNSSEC, it is important to
+ point out that consequently SMTP with DANE is the most conservative
+ possible trust model. It trusts only what must be trusted and no
+ more. Adding any other trusted actors to the mix can only reduce
+ SMTP security. A sender may choose to further harden DNSSEC for
+ selected high-value receiving domains, by configuring explicit trust
+ anchors for those domains instead of relying on the chain of trust
+ from the root domain. Detailed discussion of DNSSEC security
+ practices is out of scope for this document.
+
+1.3.3. Sender policy does not scale
+
+
+
+
+
+Dukhovni & Hardaker Expires November 26, 2014 [Page 7]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+
+
+ Sending systems are in some cases explicitly configured to use TLS
+ for mail sent to selected peer domains. This requires sending MTAs
+ to be configured with appropriate subject names or certificate
+ content digests to expect in the presented server certificates.
+ Because of the heavy administrative burden, such statically
+ configured SMTP secure channels are used rarely (generally only
+ between domains that make bilateral arrangements with their business
+ partners). Internet email, on the other hand, requires regularly
+ contacting new domains for which security configurations cannot be
+ established in advance.
+
+ The abstraction of the SMTP transport endpoint via DNS MX records,
+ often across organization boundaries, limits the use of public CA PKI
+ with SMTP to a small set of sender-configured peer domains. With
+ little opportunity to use TLS authentication, sending MTAs are rarely
+ configured with a comprehensive list of trusted CAs. SMTP services
+ that support STARTTLS often deploy X.509 certificates that are self-
+ signed or issued by a private CA.
+
+1.3.4. Too many certification authorities
+
+ Even if it were generally possible to determine a secure server name,
+ the SMTP client would still need to verify that the server's
+ certificate chain is issued by a trusted Certification Authority (a
+ trust anchor). MTAs are not interactive applications where a human
+ operator can make a decision (wisely or otherwise) to selectively
+ disable TLS security policy when certificate chain verification
+ fails. With no user to "click OK", the MTAs list of public CA trust
+ anchors would need to be comprehensive in order to avoid bouncing
+ mail addressed to sites that employ unknown Certification
+ Authorities.
+
+ On the other hand, each trusted CA can issue certificates for any
+ domain. If even one of the configured CAs is compromised or operated
+ by an adversary, it can subvert TLS security for all destinations.
+ Any set of CAs is simultaneously both overly inclusive and not
+ inclusive enough.
+
+2. Identifying applicable TLSA records
+
+2.1. DNS considerations
+
+2.1.1. DNS errors, bogus and indeterminate responses
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires November 26, 2014 [Page 8]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+
+
+ An SMTP client that implements opportunistic DANE TLS per this
+ specification depends critically on the integrity of DNSSEC lookups,
+ as discussed in Section 1.3. This section lists the DNS resolver
+ requirements needed to avoid downgrade attacks when using
+ opportunistic DANE TLS.
+
+ A DNS lookup may signal an error or return a definitive answer. A
+ security-aware resolver must be used for this specification.
+ Security-aware resolvers will indicate the security status of a DNS
+ RRset with one of four possible values defined in Section 4.3 of
+ [RFC4035]: "secure", "insecure", "bogus" and "indeterminate". In
+ [RFC4035] the meaning of the "indeterminate" security status is:
+
+ An RRset for which the resolver is not able to determine whether
+ the RRset should be signed, as the resolver is not able to obtain
+ the necessary DNSSEC RRs. This can occur when the security-aware
+ resolver is not able to contact security-aware name servers for
+ the relevant zones.
+
+ Note, the "indeterminate" security status has a conflicting
+ definition in section 5 of [RFC4033].
+
+ There is no trust anchor that would indicate that a specific
+ portion of the tree is secure.
+
+ SMTP clients following this specification SHOULD NOT distinguish
+ between "insecure" and "indeterminate" in the [RFC4033] sense. Both
+ "insecure" and RFC4033 "indeterminate" are handled identically: in
+ either case unvalidated data for the query domain is all that is and
+ can be available, and authentication using the data is impossible.
+ In what follows, when we say "insecure", we include also DNS results
+ for domains that lie in a portion of the DNS tree for which there is
+ no applicable trust anchor. With the DNS root zone signed, we expect
+ that validating resolvers used by Internet-facing MTAs will be
+ configured with trust anchor data for the root zone. Therefore,
+ RFC4033-style "indeterminate" domains should be rare in practice.
+ From here on, when we say "indeterminate", it is exclusively in the
+ sense of [RFC4035].
+
+ As noted in section 4.3 of [RFC4035], a security-aware DNS resolver
+ MUST be able to determine whether a given non-error DNS response is
+ "secure", "insecure", "bogus" or "indeterminate". It is expected
+ that most security-aware stub resolvers will not signal an
+ "indeterminate" security status in the RFC4035-sense to the
+ application, and will signal a "bogus" or error result instead. If a
+ resolver does signal an RFC4035 "indeterminate" security status, this
+ MUST be treated by the SMTP client as though a "bogus" or error
+ result had been returned.
+
+
+
+Dukhovni & Hardaker Expires November 26, 2014 [Page 9]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+
+
+ An MTA making use of a non-validating security-aware stub resolver
+ MAY use the stub resolver's ability, if available, to signal DNSSEC
+ validation status based on information the stub resolver has learned
+ from an upstream validating recursive resolver. In accordance with
+ section 4.9.3 of [RFC4035]:
+
+ ... a security-aware stub resolver MUST NOT place any reliance on
+ signature validation allegedly performed on its behalf, except
+ when the security-aware stub resolver obtained the data in question
+ from a trusted security-aware recursive name server via a secure
+ channel.
+
+ To avoid much repetition in the text below, we will pause to explain
+ the handling of "bogus" or "indeterminate" DNSSEC query responses.
+ These are not necessarily the result of a malicious actor; they can,
+ for example, occur when network packets are corrupted or lost in
+ transit. Therefore, "bogus" or "indeterminate" replies are equated
+ in this memo with lookup failure.
+
+ There is an important non-failure condition we need to highlight in
+ addition to the obvious case of the DNS client obtaining a non-empty
+ "secure" or "insecure" RRset of the requested type. Namely, it is
+ not an error when either "secure" or "insecure" non-existence is
+ determined for the requested data. When a DNSSEC response with a
+ validation status that is either "secure" or "insecure" reports
+ either no records of the requested type or non-existence of the query
+ domain, the response is not a DNS error condition. The DNS client
+ has not been left without an answer; it has learned that records of
+ the requested type do not exist.
+
+ Security-aware stub resolvers will, of course, also signal DNS lookup
+ errors in other cases, for example when processing a "ServFail"
+ RCODE, which will not have an associated DNSSEC status. All lookup
+ errors are treated the same way by this specification, regardless of
+ whether they are from a "bogus" or "indeterminate" DNSSEC status or
+ from a more generic DNS error: the information that was requested
+ cannot be obtained by the security-aware resolver at this time. A
+ lookup error is thus a failure to obtain the relevant RRset if it
+ exists, or to determine that no such RRset exists when it does not.
+
+ In contrast to a "bogus" or an "indeterminate" response, an
+ "insecure" DNSSEC response is not an error, rather it indicates that
+ the target DNS zone is either securely opted out of DNSSEC validation
+ or is not connected with the DNSSEC trust anchors being used.
+ Insecure results will leave the SMTP client with degraded channel
+ security, but do not stand in the way of message delivery. See
+ section Section 2.2 for further details.
+
+
+
+
+Dukhovni & Hardaker Expires November 26, 2014 [Page 10]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+
+
+2.1.2. DNS error handling
+
+ When a DNS lookup failure (error or "bogus" or "indeterminate" as
+ defined above) prevents an SMTP client from determining which SMTP
+ server or servers it should connect to, message delivery MUST be
+ delayed. This naturally includes, for example, the case when a
+ "bogus" or "indeterminate" response is encountered during MX
+ resolution. When multiple MX hostnames are obtained from a
+ successful MX lookup, but a later DNS lookup failure prevents network
+ address resolution for a given MX hostname, delivery may proceed via
+ any remaining MX hosts.
+
+ When a particular SMTP server is securely identified as the delivery
+ destination, a set of DNS lookups (Section 2.2) MUST be performed to
+ locate any related TLSA records. If any DNS queries used to locate
+ TLSA records fail (be it due to "bogus" or "indeterminate" records,
+ timeouts, malformed replies, ServFails, etc.), then the SMTP client
+ MUST treat that server as unreachable and MUST NOT deliver the
+ message via that server. If no servers are reachable, delivery is
+ delayed.
+
+ In what follows, we will only describe what happens when all relevant
+ DNS queries succeed. If any DNS failure occurs, the SMTP client MUST
+ behave as described in this section, by skipping the problem SMTP
+ server, or the problem destination. Queries for candidate TLSA
+ records are explicitly part of "all relevant DNS queries" and SMTP
+ clients MUST NOT continue to connect to an SMTP server or destination
+ whose TLSA record lookup fails.
+
+2.1.3. Stub resolver considerations
+
+ A note about DNAME aliases: a query for a domain name whose ancestor
+ domain is a DNAME alias returns the DNAME RR for the ancestor domain,
+ along with a CNAME that maps the query domain to the corresponding
+ sub-domain of the target domain of the DNAME alias [RFC6672].
+ Therefore, whenever we speak of CNAME aliases, we implicitly allow
+ for the possibility that the alias in question is the result of an
+ ancestor domain DNAME record. Consequently, no explicit support for
+ DNAME records is needed in SMTP software, it is sufficient to process
+ the resulting CNAME aliases. DNAME records only require special
+ processing in the validating stub-resolver library that checks the
+ integrity of the combined DNAME + CNAME reply. When DNSSEC
+ validation is handled by a local caching resolver, rather than the
+ MTA itself, even that part of the DNAME support logic is outside the
+ MTA.
+
+ When a stub resolver returns a response containing a CNAME alias that
+ does not also contain the corresponding query results for the target
+
+
+
+Dukhovni & Hardaker Expires November 26, 2014 [Page 11]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+
+
+ of the alias, the SMTP client will need to repeat the query at the
+ target of the alias, and should do so recursively up to some
+ configured or implementation-dependent recursion limit. If at any
+ stage of CNAME expansion an error is detected, the lookup of the
+ original requested records MUST be considered to have failed.
+
+ Whether a chain of CNAME records was returned in a single stub
+ resolver response or via explicit recursion by the SMTP client, if at
+ any stage of recursive expansion an "insecure" CNAME record is
+ encountered, then it and all subsequent results (in particular, the
+ final result) MUST be considered "insecure" regardless of whether any
+ earlier CNAME records leading to the "insecure" record were "secure".
+
+ Note, a security-aware non-validating stub resolver may return to the
+ SMTP client an "insecure" reply received from a validating recursive
+ resolver that contains a CNAME record along with additional answers
+ recursively obtained starting at the target of the CNAME. In this
+ all that one can say is that some record in the set of records
+ returned is "insecure", but it is possible that the initial CNAME
+ record and a subset of the subsequent records are "secure".
+
+ If the SMTP client needs to determine the security status of the DNS
+ zone containing the initial CNAME record, it may need to issue an a
+ separate query of type "CNAME" that returns only the initial CNAME
+ record. In particular in Section 2.2.2 when insecure A or AAAA
+ records are found for an SMTP server via a CNAME alias, it may be
+ necessary to perform an additional CNAME query to determine whether
+ the DNS zone in which the alias is published is signed.
+
+2.2. TLS discovery
+
+ As noted previously (in Section 1.3.1), opportunistic TLS with SMTP
+ servers that advertise TLS support via STARTTLS is subject to an MITM
+ downgrade attack. Also some SMTP servers that are not, in fact, TLS
+ capable erroneously advertise STARTTLS by default and clients need to
+ be prepared to retry cleartext delivery after STARTTLS fails. In
+ contrast, DNSSEC validated TLSA records MUST NOT be published for
+ servers that do not support TLS. Clients can safely interpret their
+ presence as a commitment by the server operator to implement TLS and
+ STARTTLS.
+
+ This memo defines four actions to be taken after the search for a
+ TLSA record returns secure usable results, secure unusable results,
+ insecure or no results or an error signal. The term "usable" in this
+ context is in the sense of Section 4.1 of [RFC6698]. Specifically,
+ if the DNS lookup for a TLSA record returns:
+
+
+
+
+
+Dukhovni & Hardaker Expires November 26, 2014 [Page 12]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+
+
+ A secure TLSA RRset with at least one usable record: A connection to
+ the MTA MUST be made using authenticated and encrypted TLS, using
+ the techniques discussed in the rest of this document. Failure to
+ establish an authenticated TLS connection MUST result in falling
+ back to the next SMTP server or delayed delivery.
+
+ A Secure non-empty TLSA RRset where all the records are unusable: A
+ connection to the MTA MUST be made via TLS, but authentication is
+ not required. Failure to establish an encrypted TLS connection
+ MUST result in falling back to the next SMTP server or delayed
+ delivery.
+
+ An insecure TLSA RRset or DNSSEC validated proof-of-non-existent TLSA
+ records:
+ A connection to the MTA SHOULD be made using (pre-DANE)
+ opportunistic TLS, this includes using cleartext delivery when the
+ remote SMTP server does not appear to support TLS. The MTA MAY
+ retry in cleartext when delivery via TLS fails either during the
+ handshake or even during data transfer.
+
+ Any lookup error: Lookup errors, including "bogus" and
+ "indeterminate", as explained in Section 2.1.1 MUST result in
+ falling back to the next SMTP server or delayed delivery.
+
+ An SMTP client MAY be configured to require DANE verified delivery
+ for some destinations. We will call such a configuration "mandatory
+ DANE TLS". With mandatory DANE TLS, delivery proceeds only when
+ "secure" TLSA records are used to establish an encrypted and
+ authenticated TLS channel with the SMTP server.
+
+ When the original next-hop destination is an address literal, rather
+ than a DNS domain, DANE TLS does not apply. Delivery proceeds using
+ any relevant security policy configured by the MTA administrator.
+ Similarly, when an MX RRset incorrectly lists a network address in
+ lieu of an MX hostname, if the MTA chooses to connect to the network
+ address DANE TLSA does not apply for such a connection.
+
+ In the subsections that follow we explain how to locate the SMTP
+ servers and the associated TLSA records for a given next-hop
+ destination domain. We also explain which name or names are to be
+ used in identity checks of the SMTP server certificate.
+
+2.2.1. MX resolution
+
+ In this section we consider next-hop domains that are subject to MX
+ resolution and have MX records. The TLSA records and the associated
+ base domain are derived separately for each MX hostname that is used
+ to attempt message delivery. DANE TLS can authenticate message
+
+
+
+Dukhovni & Hardaker Expires November 26, 2014 [Page 13]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+
+
+ delivery to the intended next-hop domain only when the MX records are
+ obtained securely via a DNSSEC validated lookup.
+
+ MX records MUST be sorted by preference; an MX hostname with a worse
+ (numerically higher) MX preference that has TLSA records MUST NOT
+ preempt an MX hostname with a better (numerically lower) preference
+ that has no TLSA records. In other words, prevention of delivery
+ loops by obeying MX preferences MUST take precedence over channel
+ security considerations. Even with two equal-preference MX records,
+ an MTA is not obligated to choose the MX hostname that offers more
+ security. Domains that want secure inbound mail delivery need to
+ ensure that all their SMTP servers and MX records are configured
+ accordingly.
+
+ In the language of [RFC5321] Section 5.1, the original next-hop
+ domain is the "initial name". If the MX lookup of the initial name
+ results in a CNAME alias, the MTA replaces the initial name with the
+ resulting name and performs a new lookup with the new name. MTAs
+ typically support recursion in CNAME expansion, so this replacement
+ is performed repeatedly until the ultimate non-CNAME domain is found.
+
+ If the MX RRset (or any CNAME leading to it) is "insecure" (see
+ Section 2.1.1), DANE TLS need not apply, and delivery MAY proceed via
+ pre-DANE opportunistic TLS. That said, the protocol in this memo is
+ an "opportunistic security" protocol, meaning that it strives to
+ communicate with each peer as securely as possible, while maintaining
+ broad interoperability. Therefore, the SMTP client MAY proceed to
+ use DANE TLS (as described in Section 2.2.2 below) even with MX hosts
+ obtained via an "insecure" MX RRset. For example, when a hosting
+ provider has a signed DNS zone and publishes TLSA records for its
+ SMTP servers, hosted domains that are not signed may still benefit
+ from the provider's TLSA records. Deliveries via the provider's SMTP
+ servers will not be subject to active attacks when sending SMTP
+ clients elect to make use of the provider's TLSA records.
+
+ When the MX records are not (DNSSEC) signed, an active attacker can
+ redirect SMTP clients to MX hosts of his choice. Such redirection is
+ tamper-evident when SMTP servers found via "insecure" MX records are
+ recorded as the next-hop relay in the MTA delivery logs in their
+ original (rather than CNAME expanded) form. Sending MTAs SHOULD log
+ unexpanded MX hostnames when these result from insecure MX lookups.
+ Any successful authentication via an insecurely determined MX host
+ MUST NOT be misrepresented in the mail logs as secure delivery to the
+ intended next-hop domain. When DANE TLS is mandatory (Section 6) for
+ a given destination, delivery MUST be delayed when the MX RRset is
+ not "secure".
+
+
+
+
+
+Dukhovni & Hardaker Expires November 26, 2014 [Page 14]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+
+
+ Otherwise, assuming no DNS errors (Section 2.1.1), the MX RRset is
+ "secure", and the SMTP client MUST treat each MX hostname as a
+ separate non-MX destination for opportunistic DANE TLS as described
+ in Section 2.2.2. When, for a given MX hostname, no TLSA records are
+ found, or only "insecure" TLSA records are found, DANE TLSA is not
+ applicable with the SMTP server in question and delivery proceeds to
+ that host as with pre-DANE opportunistic TLS. To avoid downgrade
+ attacks, any errors during TLSA lookups MUST, as explained in
+ Section 2.1.1, cause the SMTP server in question to be treated as
+ unreachable.
+
+2.2.2. Non-MX destinations
+
+ This section describes the algorithm used to locate the TLSA records
+ and associated TLSA base domain for an input domain not subject to MX
+ resolution. Such domains include:
+
+ o Each MX hostname used in a message delivery attempt for an
+ original next-hop destination domain subject to MX resolution.
+ Note, MTAs are not obligated to support CNAME expansion of MX
+ hostnames.
+
+ o Any administrator configured relay hostname, not subject to MX
+ resolution. This frequently involves configuration set by the MTA
+ administrator to handle some or all mail.
+
+ o A next-hop destination domain subject to MX resolution that has no
+ MX records. In this case the domain's name is implicitly also its
+ sole SMTP server name.
+
+ Note that DNS queries with type TLSA are mishandled by load balancing
+ nameservers that serve the MX hostnames of some large email
+ providers. The DNS zones served by these nameservers are not signed
+ and contain no TLSA records, but queries for TLSA records fail,
+ rather than returning the non-existence of the requested TLSA
+ records.
+
+ To avoid problems delivering mail to domains whose SMTP servers are
+ served by the problem nameservers the SMTP client MUST perform any A
+ and/or AAAA queries for the destination before attempting to locate
+ the associated TLSA records. This lookup is needed in any case to
+ determine whether the destination domain is reachable and the DNSSEC
+ validation status of the chain of CNAME queries required to reach the
+ ultimate address records.
+
+ If no address records are found, the destination is unreachable. If
+ address records are found, but the DNSSEC validation status of the
+ first query response is "insecure" (see Section 2.1.3), the SMTP
+
+
+
+Dukhovni & Hardaker Expires November 26, 2014 [Page 15]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+
+
+ client SHOULD NOT proceed to search for any associated TLSA records.
+ With the problem domains, TLSA queries will lead to DNS lookup errors
+ and cause messages to be consistently delayed and ultimately returned
+ to the sender. We don't expect to find any "secure" TLSA records
+ associated with a TLSA base domain that lies in an unsigned DNS zone.
+ Therefore, skipping TLSA lookups in this case will also reduce
+ latency with no detrimental impact on security.
+
+ If the A and/or AAAA lookup of the "initial name" yields a CNAME, we
+ replace it with the resulting name as if it were the initial name and
+ perform a lookup again using the new name. This replacement is
+ performed recursively.
+
+ We consider the following cases for handling a DNS response for an A
+ or AAAA DNS lookup:
+
+ Not found: When the DNS queries for A and/or AAAA records yield
+ neither a list of addresses nor a CNAME (or CNAME expansion is not
+ supported) the destination is unreachable.
+
+ Non-CNAME: The answer is not a CNAME alias. If the address RRset
+ is "secure", TLSA lookups are performed as described in
+ Section 2.2.3 with the initial name as the candidate TLSA base
+ domain. If no "secure" TLSA records are found, DANE TLS is not
+ applicable and mail delivery proceeds with pre-DANE opportunistic
+ TLS (which, being best-effort, degrades to cleartext delivery when
+ STARTTLS is not available or the TLS handshake fails).
+
+ Insecure CNAME: The input domain is a CNAME alias, but the ultimate
+ network address RRset is "insecure" (see Section 2.1.1). If the
+ initial CNAME response is also "insecure", DANE TLS does not
+ apply. Otherwise, this case is treated just like the non-CNAME
+ case above, where a search is performed for a TLSA record with the
+ original input domain as the candidate TLSA base domain.
+
+ Secure CNAME: The input domain is a CNAME alias, and the ultimate
+ network address RRset is "secure" (see Section 2.1.1). Two
+ candidate TLSA base domains are tried: the fully CNAME-expanded
+ initial name and, failing that, then the initial name itself.
+
+
+
+
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires November 26, 2014 [Page 16]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+
+
+ In summary, if it is possible to securely obtain the full, CNAME-
+ expanded, DNSSEC-validated address records for the input domain, then
+ that name is the preferred TLSA base domain. Otherwise, the
+ unexpanded input-MX domain is the candidate TLSA base domain. When
+ no "secure" TLSA records are found at either the CNAME-expanded or
+ unexpanded domain, then DANE TLS does not apply for mail delivery via
+ the input domain in question. And, as always, errors, bogus or
+ indeterminate results for any query in the process MUST result in
+ delaying or abandoning delivery.
+
+2.2.3. TLSA record lookup
+
+ Each candidate TLSA base domain (the original or fully CNAME-expanded
+ name of a non-MX destination or a particular MX hostname of an MX
+ destination) is in turn prefixed with service labels of the form
+ "_<port>._tcp". The resulting domain name is used to issue a DNSSEC
+ query with the query type set to TLSA ([RFC6698] Section 7.1).
+
+ For SMTP, the destination TCP port is typically 25, but this may be
+ different with custom routes specified by the MTA administrator in
+ which case the SMTP client MUST use the appropriate number in the
+ "_<port>" prefix in place of "_25". If, for example, the candidate
+ base domain is "mx.example.com", and the SMTP connection is to port
+ 25, the TLSA RRset is obtained via a DNSSEC query of the form:
+
+ _25._tcp.mx.example.com. IN TLSA ?
+
+ The query response may be a CNAME, or the actual TLSA RRset. If the
+ response is a CNAME, the SMTP client (through the use of its
+ security-aware stub resolver) restarts the TLSA query at the target
+ domain, following CNAMEs as appropriate and keeping track of whether
+ the entire chain is "secure". If any "insecure" records are
+ encountered, or the TLSA records don't exist, the next candidate TLSA
+ base is tried instead.
+
+ If the ultimate response is a "secure" TLSA RRset, then the candidate
+ TLSA base domain will be the actual TLSA base domain and the TLSA
+ RRset will constitute the TLSA records for the destination. If none
+ of the candidate TLSA base domains yield "secure" TLSA records then
+ delivery MAY proceed via pre-DANE opportunistic TLS. SMTP clients
+ MAY elect to use "insecure" TLSA records to avoid STARTTLS downgrades
+ or even to skip SMTP servers that fail authentication, but MUST NOT
+ misrepresent authentication success as either a secure connection to
+ the SMTP server or as a secure delivery to the intended next-hop
+ domain.
+
+ TLSA record publishers may leverage CNAMEs to reference a single
+ authoritative TLSA RRset specifying a common Certification Authority
+
+
+
+Dukhovni & Hardaker Expires November 26, 2014 [Page 17]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+
+
+ or a common end entity certificate to be used with multiple TLS
+ services. Such CNAME expansion does not change the SMTP client's
+ notion of the TLSA base domain; thus, when _25._tcp.mx.example.com is
+ a CNAME, the base domain remains mx.example.com and this is still the
+ reference identifier used together with the next-hop domain in peer
+ certificate name checks.
+
+ Note, shared end entity certificate associations expose the
+ publishing domain to substitution attacks, where an MITM attacker can
+ reroute traffic to a different server that shares the same end entity
+ certificate. Such shared end entity records SHOULD be avoided unless
+ the servers in question are functionally equivalent (an active
+ attacker gains nothing by diverting client traffic from one such
+ server to another).
+
+ For example, given the DNSSEC validated records below:
+
+ example.com. IN MX 0 mx1.example.com.
+ example.com. IN MX 0 mx2.example.com.
+ _25._tcp.mx1.example.com. IN CNAME tlsa211._dane.example.com.
+ _25._tcp.mx2.example.com. IN CNAME tlsa211._dane.example.com.
+ tlsa211._dane.example.com. IN TLSA 2 1 1 e3b0c44298fc1c149a...
+
+ The SMTP servers mx1.example.com and mx2.example.com will be expected
+ to have certificates issued under a common trust anchor, but each MX
+ hostname's TLSA base domain remains unchanged despite the above CNAME
+ records. Correspondingly, each SMTP server will be associated with a
+ pair of reference identifiers consisting of its hostname plus the
+ next-hop domain "example.com".
+
+ If, during TLSA resolution (including possible CNAME indirection), at
+ least one "secure" TLSA record is found (even if not usable because
+ it is unsupported by the implementation or support is
+ administratively disabled), then the corresponding host has signaled
+ its commitment to implement TLS. The SMTP client MUST NOT deliver
+ mail via the corresponding host unless a TLS session is negotiated
+ via STARTTLS. This is required to avoid MITM STARTTLS downgrade
+ attacks.
+
+ As noted previously (in Section Section 2.2.2), when no "secure" TLSA
+ records are found at the fully CNAME-expanded name, the original
+ unexpanded name MUST be tried instead. This supports customers of
+ hosting providers where the provider's zone cannot be validated with
+ DNSSEC, but the customer has shared appropriate key material with the
+ hosting provider to enable TLS via SNI. Intermediate names that
+ arise during CNAME expansion that are neither the original, nor the
+ final name, are never candidate TLSA base domains, even if "secure".
+
+
+
+
+Dukhovni & Hardaker Expires November 26, 2014 [Page 18]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+
+
+3. DANE authentication
+
+ This section describes which TLSA records are applicable to SMTP
+ opportunistic DANE TLS and how to apply such records to authenticate
+ the SMTP server. With opportunistic DANE TLS, both the TLS support
+ implied by the presence of DANE TLSA records and the verification
+ parameters necessary to authenticate the TLS peer are obtained
+ together. In contrast to protocols where channel security policy is
+ set exclusively by the client, authentication via this protocol is
+ expected to be less prone to connection failure caused by
+ incompatible configuration of the client and server.
+
+3.1. TLSA certificate usages
+
+ The DANE TLSA specification [RFC6698] defines multiple TLSA RR types
+ via combinations of 3 numeric parameters. The numeric values of
+ these parameters were later given symbolic names in
+ [I-D.ietf-dane-registry-acronyms]. The rest of the TLSA record is
+ the "certificate association data field", which specifies the full or
+ digest value of a certificate or public key. The parameters are:
+
+ The TLSA Certificate Usage field: Section 2.1.1 of [RFC6698]
+ specifies 4 values: PKIX-TA(0), PKIX-EE(1), DANE-TA(2), and DANE-
+ EE(3). There is an additional private-use value: PrivCert(255).
+ All other values are reserved for use by future specifications.
+
+ The selector field: Section 2.1.2 of [RFC6698] specifies 2 values:
+ Cert(0), SPKI(1). There is an additional private-use value:
+ PrivSel(255). All other values are reserved for use by future
+ specifications.
+
+ The matching type field: Section 2.1.3 of [RFC6698] specifies 3
+ values: Full(0), SHA2-256(1), SHA2-512(2). There is an additional
+ private-use value: PrivMatch(255). All other values are reserved
+ for use by future specifications.
+
+ We may think of TLSA Certificate Usage values 0 through 3 as a
+ combination of two one-bit flags. The low bit chooses between trust
+ anchor (TA) and end entity (EE) certificates. The high bit chooses
+ between public PKI issued and domain-issued certificates.
+
+ The selector field specifies whether the TLSA RR matches the whole
+ certificate: Cert(0), or just its subjectPublicKeyInfo: SPKI(1). The
+ subjectPublicKeyInfo is an ASN.1 DER encoding of the certificate's
+ algorithm id, any parameters and the public key data.
+
+ The matching type field specifies how the TLSA RR Certificate
+ Association Data field is to be compared with the certificate or
+
+
+
+Dukhovni & Hardaker Expires November 26, 2014 [Page 19]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+
+
+ public key. A value of Full(0) means an exact match: the full DER
+ encoding of the certificate or public key is given in the TLSA RR. A
+ value of SHA2-256(1) means that the association data matches the
+ SHA2-256 digest of the certificate or public key, and likewise
+ SHA2-512(2) means a SHA2-512 digest is used.
+
+ Since opportunistic DANE TLS will be used by non-interactive MTAs,
+ with no user to "press OK" when authentication fails, reliability of
+ peer authentication is paramount. Server operators are advised to
+ publish TLSA records that are least likely to fail authentication due
+ to interoperability or operational problems. Because DANE TLS relies
+ on coordinated changes to DNS and SMTP server settings, the best
+ choice of records to publish will depend on site-specific practices.
+
+ The certificate usage element of a TLSA record plays a critical role
+ in determining how the corresponding certificate association data
+ field is used to authenticate server's certificate chain. The next
+ two subsections explain the process for certificate usages DANE-EE(3)
+ and DANE-TA(2). The third subsection briefly explains why
+ certificate usages PKIX-TA(0) and PKIX-EE(1) are not applicable with
+ opportunistic DANE TLS.
+
+ In summary, we recommend the use of either "DANE-EE(3) SPKI(1)
+ SHA2-256(1)" or "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA records
+ depending on site needs. Other combinations of TLSA parameters are
+ either explicitly unsupported, or offer little to recommend them over
+ these two.
+
+ The mandatory to support digest algorithm in [RFC6698] is
+ SHA2-256(1). When the server's TLSA RRset includes records with a
+ matching type indicating a digest record (i.e., a value other than
+ Full(0)), a TLSA record with a SHA2-256(1) matching type SHOULD be
+ provided along with any other digest published, since some SMTP
+ clients may support only SHA2-256(1). If at some point the SHA2-256
+ digest algorithm is tarnished by new cryptanalytic attacks,
+ publishers will need to include an appropriate stronger digest in
+ their TLSA records, initially along with, and ultimately in place of,
+ SHA2-256.
+
+3.1.1. Certificate usage DANE-EE(3)
+
+ Authentication via certificate usage DANE-EE(3) TLSA records involves
+ simply checking that the server's leaf certificate matches the TLSA
+ record. In particular the binding of the server public key to its
+ name is based entirely on the TLSA record association. The server
+ MUST be considered authenticated even if none of the names in the
+ certificate match the client's reference identity for the server.
+
+
+
+
+Dukhovni & Hardaker Expires November 26, 2014 [Page 20]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+
+
+ Similarly, the expiration date of the server certificate MUST be
+ ignored, the validity period of the TLSA record key binding is
+ determined by the validity interval of the TLSA record DNSSEC
+ signature.
+
+ With DANE-EE(3) servers need not employ SNI (may ignore the client's
+ SNI message) even when the server is known under independent names
+ that would otherwise require separate certificates. It is instead
+ sufficient for the TLSA RRsets for all the domains in question to
+ match the server's default certificate. Of course with SMTP servers
+ it is simpler still to publish the same MX hostname for all the
+ hosted domains.
+
+ For domains where it is practical to make coordinated changes in DNS
+ TLSA records during SMTP server key rotation, it is often best to
+ publish end-entity DANE-EE(3) certificate associations. DANE-EE(3)
+ certificates don't suddenly stop working when leaf or intermediate
+ certificates expire, and don't fail when the server operator neglects
+ to configure all the required issuer certificates in the server
+ certificate chain.
+
+ TLSA records published for SMTP servers SHOULD, in most cases, be
+ "DANE-EE(3) SPKI(1) SHA2-256(1)" records. Since all DANE
+ implementations are required to support SHA2-256, this record type
+ works for all clients and need not change across certificate renewals
+ with the same key.
+
+3.1.2. Certificate usage DANE-TA(2)
+
+ Some domains may prefer to avoid the operational complexity of
+ publishing unique TLSA RRs for each TLS service. If the domain
+ employs a common issuing Certification Authority to create
+ certificates for multiple TLS services, it may be simpler to publish
+ the issuing authority as a trust anchor (TA) for the certificate
+ chains of all relevant services. The TLSA query domain (TLSA base
+ domain with port and protocol prefix labels) for each service issued
+ by the same TA may then be set to a CNAME alias that points to a
+ common TLSA RRset that matches the TA. For example:
+
+ example.com. IN MX 0 mx1.example.com.
+ example.com. IN MX 0 mx2.example.com.
+ _25._tcp.mx1.example.com. IN CNAME tlsa211._dane.example.com.
+ _25._tcp.mx2.example.com. IN CNAME tlsa211._dane.example.com.
+ tlsa211._dane.example.com. IN TLSA 2 1 1 e3b0c44298fc1c14....
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires November 26, 2014 [Page 21]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+
+
+ With usage DANE-TA(2) the server certificates will need to have names
+ that match one of the client's reference identifiers (see [RFC6125]).
+ The server MAY employ SNI to select the appropriate certificate to
+ present to the client.
+
+ SMTP servers that rely on certificate usage DANE-TA(2) TLSA records
+ for TLS authentication MUST include the TA certificate as part of the
+ certificate chain presented in the TLS handshake server certificate
+ message even when it is a self-signed root certificate. At this
+ time, many SMTP servers are not configured with a comprehensive list
+ of trust anchors, nor are they expected to at any point in the
+ future. Some MTAs will ignore all locally trusted certificates when
+ processing usage DANE-TA(2) TLSA records. Thus even when the TA
+ happens to be a public Certification Authority known to the SMTP
+ client, authentication is likely to fail unless the TA certificate is
+ included in the TLS server certificate message.
+
+ TLSA records with selector Full(0) are discouraged. While these
+ potentially obviate the need to transmit the TA certificate in the
+ TLS server certificate message, client implementations may not be
+ able to augment the server certificate chain with the data obtained
+ from DNS, especially when the TLSA record supplies a bare key
+ (selector SPKI(1)). Since the server will need to transmit the TA
+ certificate in any case, server operators SHOULD publish TLSA records
+ with a selector other than Full(0) and avoid potential
+ interoperability issues with large TLSA records containing full
+ certificates or keys.
+
+ TLSA Publishers employing DANE-TA(2) records SHOULD publish records
+ with a selector of Cert(0). Such TLSA records are associated with
+ the whole trust anchor certificate, not just with the trust anchor
+ public key. In particular, the SMTP client SHOULD then apply any
+ relevant constraints from the trust anchor certificate, such as, for
+ example, path length constraints.
+
+ While a selector of SPKI(1) may also be employed, the resulting TLSA
+ record will not specify the full trust anchor certificate content,
+ and elements of the trust anchor certificate other than the public
+ key become mutable. This may, for example, allow a subsidiary CA to
+ issue a chain that violates the trust anchor's path length or name
+ constraints.
+
+3.1.3. Certificate usages PKIX-TA(0) and PKIX-EE(1)
+
+ As noted in the introduction, SMTP clients cannot, without relying on
+ DNSSEC for secure MX records and DANE for STARTTLS support signaling,
+ perform server identity verification or prevent STARTTLS downgrade
+ attacks. The use of PKIX CAs offers no added security since an
+
+
+
+Dukhovni & Hardaker Expires November 26, 2014 [Page 22]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+
+
+ attacker capable of compromising DNSSEC is free to replace any PKIX-
+ TA(0) or PKIX-EE(1) TLSA records with records bearing any convenient
+ non-PKIX certificate usage.
+
+ SMTP servers SHOULD NOT publish TLSA RRs with certificate usage PKIX-
+ TA(0) or PKIX-EE(1). SMTP clients cannot be expected to be
+ configured with a suitably complete set of trusted public CAs.
+ Lacking a complete set of public CAs, clients would not be able to
+ verify the certificates of SMTP servers whose issuing root CAs are
+ not trusted by the client.
+
+ Opportunistic DANE TLS needs to interoperate without bilateral
+ coordination of security settings between client and server systems.
+ Therefore, parameter choices that are fragile in the absence of
+ bilateral coordination are unsupported. Nothing is lost since the
+ PKIX certificate usages cannot aid SMTP TLS security, they can only
+ impede SMTP TLS interoperability.
+
+ SMTP client treatment of TLSA RRs with certificate usages PKIX-TA(0)
+ or PKIX-EE(1) is undefined. SMTP clients should generally treat such
+ TLSA records as unusable.
+
+3.2. Certificate matching
+
+ When at least one usable "secure" TLSA record is found, the SMTP
+ client MUST use TLSA records to authenticate the SMTP server.
+ Messages MUST NOT be delivered via the SMTP server if authentication
+ fails, otherwise the SMTP client is vulnerable to MITM attacks.
+
+3.2.1. DANE-EE(3) name checks
+
+ The SMTP client MUST NOT perform certificate name checks with
+ certificate usage DANE-EE(3), see Section 3.1.1 above.
+
+3.2.2. DANE-TA(2) name checks
+
+ To match a server via a TLSA record with certificate usage DANE-
+ TA(2), the client MUST perform name checks to ensure that it has
+ reached the correct server. In all DANE-TA(2) cases the SMTP client
+ MUST include the TLSA base domain as one of the valid reference
+ identifiers for matching the server certificate.
+
+ TLSA records for MX hostnames: If the TLSA base domain was obtained
+ indirectly via a "secure" MX lookup (including any CNAME-expanded
+ name of an MX hostname), then the original next-hop domain used in
+ the MX lookup MUST be included as as a second reference
+ identifier. The CNAME-expanded original next-hop domain MUST be
+ included as a third reference identifier if different from the
+
+
+
+Dukhovni & Hardaker Expires November 26, 2014 [Page 23]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+
+
+ original next-hop domain. When the client MTA is employing DANE
+ TLS security despite "insecure" MX redirection the MX hostname is
+ the only reference identifier.
+
+ TLSA records for Non-MX hostnames: If MX records were not used
+ (e.g., if none exist) and the TLSA base domain is the CNAME-
+ expanded original next-hop domain, then the original next-hop
+ domain MUST be included as a second reference identifier.
+
+ Accepting certificates with the original next-hop domain in addition
+ to the MX hostname allows a domain with multiple MX hostnames to
+ field a single certificate bearing a single domain name (i.e., the
+ email domain) across all the SMTP servers. This also aids
+ interoperability with pre-DANE SMTP clients that are configured to
+ look for the email domain name in server certificates. For example,
+ with "secure" DNS records as below:
+
+ exchange.example.org. IN CNAME mail.example.org.
+ mail.example.org. IN CNAME example.com.
+ example.com. IN MX 10 mx10.example.com.
+ example.com. IN MX 15 mx15.example.com.
+ example.com. IN MX 20 mx20.example.com.
+ ;
+ mx10.example.com. IN A 192.0.2.10
+ _25._tcp.mx10.example.com. IN TLSA 2 0 1 ...
+ ;
+ mx15.example.com. IN CNAME mxbackup.example.com.
+ mxbackup.example.com. IN A 192.0.2.15
+ ; _25._tcp.mxbackup.example.com. IN TLSA ? (NXDOMAIN)
+ _25._tcp.mx15.example.com. IN TLSA 2 0 1 ...
+ ;
+ mx20.example.com. IN CNAME mxbackup.example.net.
+ mxbackup.example.net. IN A 198.51.100.20
+ _25._tcp.mxbackup.example.net. IN TLSA 2 0 1 ...
+
+ Certificate name checks for delivery of mail to exchange.example.org
+ via any of the associated SMTP servers MUST accept at least the names
+ "exchange.example.org" and "example.com", which are respectively the
+ original and fully expanded next-hop domain. When the SMTP server is
+ mx10.example.com, name checks MUST accept the TLSA base domain
+ "mx10.example.com". If, despite the fact that MX hostnames are
+ required to not be aliases, the MTA supports delivery via
+ "mx15.example.com" or "mx20.example.com" then name checks MUST accept
+ the respective TLSA base domains "mx15.example.com" and
+ "mxbackup.example.net".
+
+3.2.3. Reference identifier matching
+
+
+
+
+Dukhovni & Hardaker Expires November 26, 2014 [Page 24]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+
+
+ When name checks are applicable (certificate usage DANE-TA(2)), if
+ the server certificate contains a Subject Alternative Name extension
+ ([RFC5280]), with at least one DNS-ID ([RFC6125]) then only the DNS-
+ IDs are matched against the client's reference identifiers. The CN-
+ ID ([RFC6125]) is only considered when no DNS-IDs are present. The
+ server certificate is considered matched when one of its presented
+ identifiers ([RFC5280]) matches any of the client's reference
+ identifiers.
+
+ Wildcards are valid in either DNS-IDs or the CN-ID when applicable.
+ The wildcard character must be entire first label of the DNS-ID or
+ CN-ID. Thus, "*.example.com" is valid, while "smtp*.example.com" and
+ "*smtp.example.com" are not. SMTP clients MUST support wildcards
+ that match the first label of the reference identifier, with the
+ remaining labels matching verbatim. For example, the DNS-ID
+ "*.example.com" matches the reference identifier "mx1.example.com".
+ SMTP clients MAY, subject to local policy allow wildcards to match
+ multiple reference identifier labels, but servers cannot expect broad
+ support for such a policy. Therefore any wildcards in server
+ certificates SHOULD match exactly one label in either the TLSA base
+ domain or the next-hop domain.
+
+4. Server key management
+
+ Two TLSA records MUST be published before employing a new EE or TA
+ public key or certificate, one matching the currently deployed key
+ and the other matching the new key scheduled to replace it. Once
+ sufficient time has elapsed for all DNS caches to expire the previous
+ TLSA RRset and related signature RRsets, servers may be configured to
+ use the new EE private key and associated public key certificate or
+ may employ certificates signed by the new trust anchor.
+
+ Once the new public key or certificate is in use, the TLSA RR that
+ matches the retired key can be removed from DNS, leaving only RRs
+ that match keys or certificates in active use.
+
+ As described in Section 3.1.2, when server certificates are validated
+ via a DANE-TA(2) trust anchor, and CNAME records are employed to
+ store the TA association data at a single location, the
+ responsibility of updating the TLSA RRset shifts to the operator of
+ the trust anchor. Before a new trust anchor is used to sign any new
+ server certificates, its certificate (digest) is added to the
+ relevant TLSA RRset. After enough time elapses for the original TLSA
+ RRset to age out of DNS caches, the new trust anchor can start
+ issuing new server certificates. Once all certificates issued under
+ the previous trust anchor have expired, its associated RRs can be
+ removed from the TLSA RRset.
+
+
+
+
+Dukhovni & Hardaker Expires November 26, 2014 [Page 25]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+
+
+ In the DANE-TA(2) key management model server operators do not
+ generally need to update DNS TLSA records after initially creating a
+ CNAME record that references the centrally operated DANE-TA(2) RRset.
+ If a particular server's key is compromised, its TLSA CNAME SHOULD be
+ replaced with a DANE-EE(3) association until the certificate for the
+ compromised key expires, at which point it can return to using CNAME
+ record. If the central trust anchor is compromised, all servers need
+ to be issued new keys by a new TA, and a shared DANE-TA(2) TLSA RRset
+ needs to be published containing just the new TA. SMTP servers
+ cannot expect broad SMTP client CRL or OCSP support.
+
+5. Digest algorithm agility
+
+ While [RFC6698] specifies multiple digest algorithms, it does not
+ specify a protocol by which the SMTP client and TLSA record publisher
+ can agree on the strongest shared algorithm. Such a protocol would
+ allow the client and server to avoid exposure to any deprecated
+ weaker algorithms that are published for compatibility with less
+ capable clients, but should be ignored when possible. We specify
+ such a protocol below.
+
+ Suppose that a DANE TLS client authenticating a TLS server considers
+ digest algorithm "BetterAlg" stronger than digest algorithm
+ "WorseAlg". Suppose further that a server's TLSA RRset contains some
+ records with "BetterAlg" as the digest algorithm. Finally, suppose
+ that for every raw public key or certificate object that is included
+ in the server's TLSA RRset in digest form, whenever that object
+ appears with algorithm "WorseAlg" with some usage and selector it
+ also appears with algorithm "BetterAlg" with the same usage and
+ selector. In that case our client can safely ignore TLSA records
+ with the weaker algorithm "WorseAlg", because it suffices to check
+ the records with the stronger algorithm "BetterAlg".
+
+ Server operators MUST ensure that for any given usage and selector,
+ each object (certificate or public key), for which a digest
+ association exists in the TLSA RRset, is published with the SAME SET
+ of digest algorithms as all other objects that published with that
+ usage and selector. In other words, for each usage and selector, the
+ records with non-zero matching types will correspond to on a cross-
+ product of a set of underlying objects and a fixed set of digest
+ algorithms that apply uniformly to all the objects.
+
+ To achieve digest algorithm agility, all published TLSA RRsets for
+ use with opportunistic DANE TLS for SMTP MUST conform to the above
+ requirements. Then, for each combination of usage and selector, SMTP
+ clients can simply ignore all digest records except those that employ
+ the strongest digest algorithm. The ordering of digest algorithms by
+ strength is not specified in advance, it is entirely up to the SMTP
+
+
+
+Dukhovni & Hardaker Expires November 26, 2014 [Page 26]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+
+
+ client. SMTP client implementations SHOULD make the digest algorithm
+ preference order configurable. Only the future will tell which
+ algorithms might be weakened by new attacks and when.
+
+ Note, TLSA records with a matching type of Full(0), that publish the
+ full value of a certificate or public key object, play no role in
+ digest algorithm agility. They neither trump the processing of
+ records that employ digests, nor are they ignored in the presence of
+ any records with a digest (i.e. non-zero) matching type.
+
+ SMTP clients SHOULD use digest algorithm agility when processing the
+ DANE TLSA records of an SMTP server. Algorithm agility is to be
+ applied after first discarding any unusable or malformed records
+ (unsupported digest algorithm, or incorrect digest length). Thus,
+ for each usage and selector, the client SHOULD process only any
+ usable records with a matching type of Full(0) and the usable records
+ whose digest algorithm is believed to be the strongest among usable
+ records with the given usage and selector.
+
+ The main impact of this requirement is on key rotation, when the TLSA
+ RRset is pre-populated with digests of new certificates or public
+ keys, before these replace or augment their predecessors. Were the
+ newly introduced RRs to include previously unused digest algorithms,
+ clients that employ this protocol could potentially ignore all the
+ digests corresponding to the current keys or certificates, causing
+ connectivity issues until the new keys or certificates are deployed.
+ Similarly, publishing new records with fewer digests could cause
+ problems for clients using cached TLSA RRsets that list both the old
+ and new objects once the new keys are deployed.
+
+ To avoid problems, server operators SHOULD apply the following
+ strategy:
+
+ o When changing the set of objects published via the TLSA RRset
+ (e.g. during key rotation), DO NOT change the set of digest
+ algorithms used; change just the list of objects.
+
+ o When changing the set of digest algorithms, change only the set of
+ algorithms, and generate a new RRset in which all the current
+ objects are re-published with the new set of digest algorithms.
+
+ After either of these two changes are made, the new TLSA RRset should
+ be left in place long enough that the older TLSA RRset can be flushed
+ from caches before making another change.
+
+6. Mandatory TLS Security
+
+
+
+
+
+Dukhovni & Hardaker Expires November 26, 2014 [Page 27]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+
+
+ An MTA implementing this protocol may require a stronger security
+ assurance when sending email to selected destinations. The sending
+ organization may need to send sensitive email and/or may have
+ regulatory obligations to protect its content. This protocol is not
+ in conflict with such a requirement, and in fact can often simplify
+ authenticated delivery to such destinations.
+
+ Specifically, with domains that publish DANE TLSA records for their
+ MX hostnames, a sending MTA can be configured to use the receiving
+ domains's DANE TLSA records to authenticate the corresponding SMTP
+ server. Authentication via DANE TLSA records is easier to manage, as
+ changes in the receiver's expected certificate properties are made on
+ the receiver end and don't require manually communicated
+ configuration changes. With mandatory DANE TLS, when no usable TLSA
+ records are found, message delivery is delayed. Thus, mail is only
+ sent when an authenticated TLS channel is established to the remote
+ SMTP server.
+
+ Administrators of mail servers that employ mandatory DANE TLS, need
+ to carefully monitor their mail logs and queues. If a partner domain
+ unwittingly misconfigures their TLSA records, disables DNSSEC, or
+ misconfigures SMTP server certificate chains, mail will be delayed
+ and may bounce if the issue is not resolved in a timely manner.
+
+7. Note on DANE for Message User Agents
+
+ We note that the SMTP protocol is also used between Message User
+ Agents (MUAs) and Message Submission Agents (MSAs) [RFC6409]. In
+ [RFC6186] a protocol is specified that enables an MUA to dynamically
+ locate the MSA based on the user's email address. SMTP connection
+ security considerations for MUAs implementing [RFC6186] are largely
+ analogous to connection security requirements for MTAs, and this
+ specification could be applied largely verbatim with DNS MX records
+ replaced by corresponding DNS Service (SRV) records
+ [I-D.ietf-dane-srv].
+
+ However, until MUAs begin to adopt the dynamic configuration
+ mechanisms of [RFC6186] they are adequately served by more
+ traditional static TLS security policies. Specification of DANE TLS
+ for Message User Agent (MUA) to Message Submission Agent (MSA) SMTP
+ is left to future documents that focus specifically on SMTP security
+ between MUAs and MSAs.
+
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires November 26, 2014 [Page 28]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+
+
+8. Interoperability considerations
+
+8.1. SNI support
+
+ To ensure that the server sends the right certificate chain, the SMTP
+ client MUST send the TLS SNI extension containing the TLSA base
+ domain. This precludes the use of the backward compatible SSL 2.0
+ compatible SSL HELLO by the SMTP client. The minimum SSL/TLS client
+ HELLO version for SMTP clients performing DANE authentication is SSL
+ 3.0, but a client that offers SSL 3.0 MUST also offer at least TLS
+ 1.0 and MUST include the SNI extension. Servers that don't make use
+ of SNI MAY negotiate SSL 3.0 if offered by the client.
+
+ Each SMTP server MUST present a certificate chain (see [RFC5246]
+ Section 7.4.2) that matches at least one of the TLSA records. The
+ server MAY rely on SNI to determine which certificate chain to
+ present to the client. Clients that don't send SNI information may
+ not see the expected certificate chain.
+
+ If the server's TLSA records match the server's default certificate
+ chain, the server need not support SNI. In either case, the server
+ need not include the SNI extension in its TLS HELLO as simply
+ returning a matching certificate chain is sufficient. Servers MUST
+ NOT enforce the use of SNI by clients, as the client may be using
+ unauthenticated opportunistic TLS and may not expect any particular
+ certificate from the server. If the client sends no SNI extension,
+ or sends an SNI extension for an unsupported domain, the server MUST
+ simply send some fallback certificate chain of its choice. The
+ reason for not enforcing strict matching of the requested SNI
+ hostname is that DANE TLS clients are typically willing to accept
+ multiple server names, but can only send one name in the SNI
+ extension. The server's fallback certificate may match a different
+ name acceptable to the client, e.g., the original next-hop domain.
+
+8.2. Anonymous TLS cipher suites
+
+ Since many SMTP servers either do not support or do not enable any
+ anonymous TLS cipher suites, SMTP client TLS HELLO messages SHOULD
+ offer to negotiate a typical set of non-anonymous cipher suites
+ required for interoperability with such servers. An SMTP client
+ employing pre-DANE opportunistic TLS MAY in addition include one or
+ more anonymous TLS cipher suites in its TLS HELLO. SMTP servers,
+ that need to interoperate with opportunistic TLS clients SHOULD be
+ prepared to interoperate with such clients by either always selecting
+ a mutually supported non-anonymous cipher suite or by correctly
+ handling client connections that negotiate anonymous cipher suites.
+
+
+
+
+
+Dukhovni & Hardaker Expires November 26, 2014 [Page 29]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+
+
+ Note that while SMTP server operators are under no obligation to
+ enable anonymous cipher suites, no security is gained by sending
+ certificates to clients that will ignore them. Indeed support for
+ anonymous cipher suites in the server makes audit trails more
+ informative. Log entries that record connections that employed an
+ anonymous cipher suite record the fact that the clients did not care
+ to authenticate the server.
+
+9. Operational Considerations
+
+9.1. Client Operational Considerations
+
+ An operational error on the sending or receiving side that cannot be
+ corrected in a timely manner may, at times, lead to consistent
+ failure to deliver time-sensitive email. The sending MTA
+ administrator may have to choose between letting email queue until
+ the error is resolved and disabling opportunistic or mandatory DANE
+ TLS for one or more destinations. The choice to disable DANE TLS
+ security should not be made lightly. Every reasonable effort should
+ be made to determine that problems with mail delivery are the result
+ of an operational error, and not an attack. A fallback strategy may
+ be to configure explicit out-of-band TLS security settings if
+ supported by the sending MTA.
+
+ SMTP clients may deploy opportunistic DANE TLS incrementally by
+ enabling it only for selected sites, or may occasionally need to
+ disable opportunistic DANE TLS for peers that fail to interoperate
+ due to misconfiguration or software defects on either end. Some
+ implementations MAY support DANE TLS in an "audit only" mode in which
+ failure to achieve the requisite security level is logged as a
+ warning and delivery proceeds at a reduced security level. Unless
+ local policy specifies "audit only" or that opportunistic DANE TLS is
+ not to be used for a particular destination, an SMTP client MUST NOT
+ deliver mail via a server whose certificate chain fails to match at
+ least one TLSA record when usable TLSA records are found for that
+ server.
+
+9.2. Publisher Operational Considerations
+
+ SMTP servers that publish certificate usage DANE-TA(2) associations
+ MUST include the TA certificate in their TLS server certificate
+ chain, even when that TA certificate is a self-signed root
+ certificate.
+
+ TLSA Publishers must follow the digest agility guidelines in
+ Section 5 and must make sure that all objects published in digest
+ form for a particular usage and selector are published with the same
+ set of digest algorithms.
+
+
+
+Dukhovni & Hardaker Expires November 26, 2014 [Page 30]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+
+
+ TLSA Publishers should follow the TLSA publication size guidance
+ found in [I-D.ietf-dane-ops] about "DANE DNS Record Size Guidelines".
+
+10. Security Considerations
+
+ This protocol leverages DANE TLSA records to implement MITM resistant
+ opportunistic channel security for SMTP. For destination domains
+ that sign their MX records and publish signed TLSA records for their
+ MX hostnames, this protocol allows sending MTAs to securely discover
+ both the availability of TLS and how to authenticate the destination.
+
+ This protocol does not aim to secure all SMTP traffic, as that is not
+ practical until DNSSEC and DANE adoption are universal. The
+ incremental deployment provided by following this specification is a
+ best possible path for securing SMTP. This protocol coexists and
+ interoperates with the existing insecure Internet email backbone.
+
+ The protocol does not preclude existing non-opportunistic SMTP TLS
+ security arrangements, which can continue to be used as before via
+ manual configuration with negotiated out-of-band key and TLS
+ configuration exchanges.
+
+ Opportunistic SMTP TLS depends critically on DNSSEC for downgrade
+ resistance and secure resolution of the destination name. If DNSSEC
+ is compromised, it is not possible to fall back on the public CA PKI
+ to prevent MITM attacks. A successful breach of DNSSEC enables the
+ attacker to publish TLSA usage 3 certificate associations, and
+ thereby bypass any security benefit the legitimate domain owner might
+ hope to gain by publishing usage 0 or 1 TLSA RRs. Given the lack of
+ public CA PKI support in existing MTA deployments, avoiding
+ certificate usages 0 and 1 simplifies implementation and deployment
+ with no adverse security consequences.
+
+ Implementations must strictly follow the portions of this
+ specification that indicate when it is appropriate to initiate a non-
+ authenticated connection or cleartext connection to a SMTP server.
+ Specifically, in order to prevent downgrade attacks on this protocol,
+ implementation must not initiate a connection when this specification
+ indicates a particular SMTP server must be considered unreachable.
+
+11. IANA considerations
+
+ This specification requires no support from IANA.
+
+12. Acknowledgements
+
+ The authors would like to extend great thanks to Tony Finch, who
+ started the original version of a DANE SMTP document. His work is
+
+
+
+Dukhovni & Hardaker Expires November 26, 2014 [Page 31]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+
+
+ greatly appreciated and has been incorporated into this document.
+ The authors would like to additionally thank Phil Pennock for his
+ comments and advice on this document.
+
+ Acknowledgments from Viktor: Thanks to Paul Hoffman who motivated me
+ to begin work on this memo and provided feedback on early drafts.
+ Thanks to Patrick Koetter, Perry Metzger and Nico Williams for
+ valuable review comments. Thanks also to Wietse Venema who created
+ Postfix, and whose advice and feedback were essential to the
+ development of the Postfix DANE implementation.
+
+13. References
+
+13.1. Normative References
+
+ [I-D.ietf-dane-ops]
+ Dukhovni, V. and W. Hardaker, "DANE TLSA implementation
+ and operational guidance", draft-ietf-dane-ops-00 (work in
+ progress), October 2013.
+
+ [RFC1035] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
+ Transport Layer Security", RFC 3207, February 2002.
+
+ [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "DNS Security Introduction and Requirements", RFC
+ 4033, March 2005.
+
+ [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Resource Records for the DNS Security Extensions",
+ RFC 4034, March 2005.
+
+ [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Protocol Modifications for the DNS Security
+ Extensions", RFC 4035, March 2005.
+
+ [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+ [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, May 2008.
+
+
+
+Dukhovni & Hardaker Expires November 26, 2014 [Page 32]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+
+
+ [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
+ October 2008.
+
+ [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
+ Extension Definitions", RFC 6066, January 2011.
+
+ [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, March 2011.
+
+ [RFC6186] Daboo, C., "Use of SRV Records for Locating Email
+ Submission/Access Services", RFC 6186, March 2011.
+
+ [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
+ DNS", RFC 6672, June 2012.
+
+ [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
+ of Named Entities (DANE) Transport Layer Security (TLS)
+ Protocol: TLSA", RFC 6698, August 2012.
+
+13.2. Informative References
+
+ [I-D.ietf-dane-registry-acronyms]
+ Gudmundsson, O., "Adding acronyms to simplify DANE
+ conversations", draft-ietf-dane-registry-acronyms-01 (work
+ in progress), October 2013.
+
+ [I-D.ietf-dane-srv]
+ Finch, T., "Using DNS-Based Authentication of Named
+ Entities (DANE) TLSA records with SRV and MX records.",
+ draft-ietf-dane-srv-02 (work in progress), February 2013.
+
+ [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July
+ 2009.
+
+ [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",
+ STD 72, RFC 6409, November 2011.
+
+Authors' Addresses
+
+ Viktor Dukhovni
+ Two Sigma
+
+ Email: ietf-dane@dukhovni.org
+
+
+
+
+
+Dukhovni & Hardaker Expires November 26, 2014 [Page 33]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS May 2014
+
+
+ Wes Hardaker
+ Parsons
+ P.O. Box 382
+ Davis, CA 95617
+ US
+
+ Email: ietf@hardakers.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires November 26, 2014 [Page 34]
--- /dev/null
+
+
+
+
+DANE V. Dukhovni
+Internet-Draft Two Sigma
+Intended status: Standards Track W. Hardaker
+Expires: February 3, 2015 Parsons
+ August 2, 2014
+
+
+ SMTP security via opportunistic DANE TLS
+ draft-ietf-dane-smtp-with-dane-11
+
+Abstract
+
+ This memo describes a downgrade-resistant protocol for SMTP transport
+ security between Mail Transfer Agents (MTAs) based on the DNS-Based
+ Authentication of Named Entities (DANE) TLSA DNS record. Adoption of
+ this protocol enables an incremental transition of the Internet email
+ backbone to one using encrypted and authenticated Transport Layer
+ Security (TLS).
+
+Status of This Memo
+
+ This Internet-Draft is submitted in full conformance with the
+ provisions of BCP 78 and BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF). Note that other groups may also distribute
+ working documents as Internet-Drafts. The list of current Internet-
+ Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ This Internet-Draft will expire on February 3, 2015.
+
+Copyright Notice
+
+ Copyright (c) 2014 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
+
+
+
+Dukhovni & Hardaker Expires February 3, 2015 [Page 1]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 5
+ 1.3. SMTP channel security . . . . . . . . . . . . . . . . . . 6
+ 1.3.1. STARTTLS downgrade attack . . . . . . . . . . . . . . 6
+ 1.3.2. Insecure server name without DNSSEC . . . . . . . . . 7
+ 1.3.3. Sender policy does not scale . . . . . . . . . . . . 8
+ 1.3.4. Too many certification authorities . . . . . . . . . 8
+ 2. Identifying applicable TLSA records . . . . . . . . . . . . . 9
+ 2.1. DNS considerations . . . . . . . . . . . . . . . . . . . 9
+ 2.1.1. DNS errors, bogus and indeterminate responses . . . . 9
+ 2.1.2. DNS error handling . . . . . . . . . . . . . . . . . 11
+ 2.1.3. Stub resolver considerations . . . . . . . . . . . . 12
+ 2.2. TLS discovery . . . . . . . . . . . . . . . . . . . . . . 13
+ 2.2.1. MX resolution . . . . . . . . . . . . . . . . . . . . 14
+ 2.2.2. Non-MX destinations . . . . . . . . . . . . . . . . . 15
+ 2.2.3. TLSA record lookup . . . . . . . . . . . . . . . . . 17
+ 3. DANE authentication . . . . . . . . . . . . . . . . . . . . . 19
+ 3.1. TLSA certificate usages . . . . . . . . . . . . . . . . . 19
+ 3.1.1. Certificate usage DANE-EE(3) . . . . . . . . . . . . 21
+ 3.1.2. Certificate usage DANE-TA(2) . . . . . . . . . . . . 22
+ 3.1.3. Certificate usages PKIX-TA(0) and PKIX-EE(1) . . . . 23
+ 3.2. Certificate matching . . . . . . . . . . . . . . . . . . 24
+ 3.2.1. DANE-EE(3) name checks . . . . . . . . . . . . . . . 24
+ 3.2.2. DANE-TA(2) name checks . . . . . . . . . . . . . . . 24
+ 3.2.3. Reference identifier matching . . . . . . . . . . . . 25
+ 4. Server key management . . . . . . . . . . . . . . . . . . . . 26
+ 5. Digest algorithm agility . . . . . . . . . . . . . . . . . . 26
+ 6. Mandatory TLS Security . . . . . . . . . . . . . . . . . . . 28
+ 7. Note on DANE for Message User Agents . . . . . . . . . . . . 29
+ 8. Interoperability considerations . . . . . . . . . . . . . . . 29
+ 8.1. SNI support . . . . . . . . . . . . . . . . . . . . . . . 29
+ 8.2. Anonymous TLS cipher suites . . . . . . . . . . . . . . . 30
+ 9. Operational Considerations . . . . . . . . . . . . . . . . . 30
+ 9.1. Client Operational Considerations . . . . . . . . . . . . 30
+ 9.2. Publisher Operational Considerations . . . . . . . . . . 31
+ 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31
+ 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 32
+ 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
+ 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
+ 13.1. Normative References . . . . . . . . . . . . . . . . . . 33
+ 13.2. Informative References . . . . . . . . . . . . . . . . . 34
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
+
+
+
+Dukhovni & Hardaker Expires February 3, 2015 [Page 2]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+1. Introduction
+
+ This memo specifies a new connection security model for Message
+ Transfer Agents (MTAs). This model is motivated by key features of
+ inter-domain SMTP delivery, in particular the fact that the
+ destination server is selected indirectly via DNS Mail Exchange (MX)
+ records and that neither email addresses nor MX hostnames signal a
+ requirement for either secure or cleartext transport. Therefore,
+ aside from a few manually configured exceptions, SMTP transport
+ security is of necessity opportunistic.
+
+ This specification uses the presence of DANE TLSA records to securely
+ signal TLS support and to publish the means by which SMTP clients can
+ successfully authenticate legitimate SMTP servers. This becomes
+ "opportunistic DANE TLS" and is resistant to downgrade and man-in-
+ the-middle (MITM) attacks. It enables an incremental transition of
+ the email backbone to authenticated TLS delivery, with increased
+ global protection as adoption increases.
+
+ With opportunistic DANE TLS, traffic from SMTP clients to domains
+ that publish "usable" DANE TLSA records in accordance with this memo
+ is authenticated and encrypted. Traffic from legacy clients or to
+ domains that do not publish TLSA records will continue to be sent in
+ the same manner as before, via manually configured security, (pre-
+ DANE) opportunistic TLS or just cleartext SMTP.
+
+ Problems with existing use of TLS in MTA to MTA SMTP that motivate
+ this specification are described in Section 1.3. The specification
+ itself follows in Section 2 and Section 3 which describe respectively
+ how to locate and use DANE TLSA records with SMTP. In Section 6, we
+ discuss application of DANE TLS to destinations for which channel
+ integrity and confidentiality are mandatory. In Section 7 we briefly
+ comment on potential applicability of this specification to Message
+ User Agents.
+
+1.1. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ [RFC2119].
+
+ The following terms or concepts are used through the document:
+
+ Man-in-the-middle or MITM attack: Active modification of network
+ traffic by an adversary able to thereby compromise the
+ confidentiality or integrity of the data.
+
+
+
+
+Dukhovni & Hardaker Expires February 3, 2015 [Page 3]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ secure, bogus, insecure, indeterminate: DNSSEC validation results,
+ as defined in Section 4.3 of [RFC4035].
+
+ Validating Security-Aware Stub Resolver and Non-Validating
+ Security-Aware Stub Resolver:
+ Capabilities of the stub resolver in use as defined in [RFC4033];
+ note that this specification requires the use of a Security-Aware
+ Stub Resolver.
+
+ (pre-DANE) opportunistic TLS: Best-effort use of TLS that is
+ generally vulnerable to DNS forgery and STARTTLS downgrade
+ attacks. When a TLS-encrypted communication channel is not
+ available, message transmission takes place in the clear. MX
+ record indirection generally precludes authentication even when
+ TLS is available.
+
+ opportunistic DANE TLS: Best-effort use of TLS, resistant to
+ downgrade attacks for destinations with DNSSEC-validated TLSA
+ records. When opportunistic DANE TLS is determined to be
+ unavailable, clients should fall back to opportunistic TLS.
+ Opportunistic DANE TLS requires support for DNSSEC, DANE and
+ STARTTLS on the client side and STARTTLS plus a DNSSEC published
+ TLSA record on the server side.
+
+ reference identifier: (Special case of [RFC6125] definition). One
+ of the domain names associated by the SMTP client with the
+ destination SMTP server for performing name checks on the server
+ certificate. When name checks are applicable, at least one of the
+ reference identifiers MUST match an [RFC6125] DNS-ID (or if none
+ are present the [RFC6125] CN-ID) of the server certificate (see
+ Section 3.2.3).
+
+ MX hostname: The RRDATA of an MX record consists of a 16 bit
+ preference followed by a Mail Exchange domain name (see [RFC1035],
+ Section 3.3.9). We will use the term "MX hostname" to refer to
+ the latter, that is, the DNS domain name found after the
+ preference value in an MX record. Thus an "MX hostname" is
+ specifically a reference to a DNS domain name, rather than any
+ host that bears that name.
+
+ delayed delivery: Email delivery is a multi-hop store & forward
+ process. When an MTA is unable forward a message that may become
+ deliverable later the message is queued and delivery is retried
+ periodically. Some MTAs may be configured with a fallback next-
+ hop destination that handles messages that the MTA would otherwise
+ queue and retry. When a fallback next-hop is configured, messages
+ that would otherwise have to be delayed may be sent to the
+ fallback next-hop destination instead. The fallback destination
+
+
+
+Dukhovni & Hardaker Expires February 3, 2015 [Page 4]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ may itself be subject to opportunistic or mandatory DANE TLS as
+ though it were the original message destination.
+
+ original next hop destination: The logical destination for mail
+ delivery. By default this is the domain portion of the recipient
+ address, but MTAs may be configured to forward mail for some or
+ all recipients via designated relays. The original next hop
+ destination is, respectively, either the recipient domain or the
+ associated configured relay.
+
+ MTA: Message Transfer Agent ([RFC5598], Section 4.3.2).
+
+ MSA: Message Submission Agent ([RFC5598], Section 4.3.1).
+
+ MUA: Message User Agent ([RFC5598], Section 4.2.1).
+
+ RR: A DNS Resource Record
+
+ RRset: A set of DNS Resource Records for a particular class, domain
+ and record type.
+
+1.2. Background
+
+ The Domain Name System Security Extensions (DNSSEC) add data origin
+ authentication, data integrity and data non-existence proofs to the
+ Domain Name System (DNS). DNSSEC is defined in [RFC4033], [RFC4034]
+ and [RFC4035].
+
+ As described in the introduction of [RFC6698], TLS authentication via
+ the existing public Certification Authority (CA) PKI suffers from an
+ over-abundance of trusted parties capable of issuing certificates for
+ any domain of their choice. DANE leverages the DNSSEC infrastructure
+ to publish trusted public keys and certificates for use with the
+ Transport Layer Security (TLS) [RFC5246] protocol via a new "TLSA"
+ DNS record type. With DNSSEC each domain can only vouch for the keys
+ of its directly delegated sub-domains.
+
+ The TLS protocol enables secure TCP communication. In the context of
+ this memo, channel security is assumed to be provided by TLS. Used
+ without authentication, TLS provides only privacy protection against
+ eavesdropping attacks. With authentication, TLS also provides data
+ integrity protection to guard against MITM attacks.
+
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 3, 2015 [Page 5]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+1.3. SMTP channel security
+
+ With HTTPS, Transport Layer Security (TLS) employs X.509 certificates
+ [RFC5280] issued by one of the many Certificate Authorities (CAs)
+ bundled with popular web browsers to allow users to authenticate
+ their "secure" websites. Before we specify a new DANE TLS security
+ model for SMTP, we will explain why a new security model is needed.
+ In the process, we will explain why the familiar HTTPS security model
+ is inadequate to protect inter-domain SMTP traffic.
+
+ The subsections below outline four key problems with applying
+ traditional PKI to SMTP that are addressed by this specification.
+ Since SMTP channel security policy is not explicitly specified in
+ either the recipient address or the MX record, a new signaling
+ mechanism is required to indicate when channel security is possible
+ and should be used. The publication of TLSA records allows server
+ operators to securely signal to SMTP clients that TLS is available
+ and should be used. DANE TLSA makes it possible to simultaneously
+ discover which destination domains support secure delivery via TLS
+ and how to verify the authenticity of the associated SMTP services,
+ providing a path forward to ubiquitous SMTP channel security.
+
+1.3.1. STARTTLS downgrade attack
+
+ The Simple Mail Transfer Protocol (SMTP) [RFC5321] is a single-hop
+ protocol in a multi-hop store & forward email delivery process. An
+ SMTP envelope recipient address does not correspond to a specific
+ transport-layer endpoint address, rather at each relay hop the
+ transport-layer endpoint is the next-hop relay, while the envelope
+ recipient address typically remains the same. Unlike the Hypertext
+ Transfer Protocol (HTTP) and its corresponding secured version,
+ HTTPS, where the use of TLS is signaled via the URI scheme, email
+ recipient addresses do not directly signal transport security policy.
+ Indeed, no such signaling could work well with SMTP since TLS
+ encryption of SMTP protects email traffic on a hop-by-hop basis while
+ email addresses could only express end-to-end policy.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 3, 2015 [Page 6]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ With no mechanism available to signal transport security policy, SMTP
+ relays employ a best-effort "opportunistic" security model for TLS.
+ A single SMTP server TCP listening endpoint can serve both TLS and
+ non-TLS clients; the use of TLS is negotiated via the SMTP STARTTLS
+ command ([RFC3207]). The server signals TLS support to the client
+ over a cleartext SMTP connection, and, if the client also supports
+ TLS, it may negotiate a TLS encrypted channel to use for email
+ transmission. The server's indication of TLS support can be easily
+ suppressed by an MITM attacker. Thus pre-DANE SMTP TLS security can
+ be subverted by simply downgrading a connection to cleartext. No TLS
+ security feature, such as the use of PKIX, can prevent this. The
+ attacker can simply disable TLS.
+
+1.3.2. Insecure server name without DNSSEC
+
+ With SMTP, DNS Mail Exchange (MX) records abstract the next-hop
+ transport endpoint and allow administrators to specify a set of
+ target servers to which SMTP traffic should be directed for a given
+ domain.
+
+ A PKIX TLS client is vulnerable to MITM attacks unless it verifies
+ that the server's certificate binds the public key to a name that
+ matches one of the client's reference identifiers. A natural choice
+ of reference identifier is the server's domain name. However, with
+ SMTP, server names are not directly encoded in the recipient address,
+ instead they are obtained indirectly via MX records. Without DNSSEC,
+ the MX lookup is vulnerable to MITM and DNS cache poisoning attacks.
+ Active attackers can forge DNS replies with fake MX records and can
+ redirect email to servers with names of their choice. Therefore,
+ secure verification of SMTP TLS certificates matching the server name
+ is not possible without DNSSEC.
+
+ One might try to harden TLS for SMTP against DNS attacks by using the
+ envelope recipient domain as a reference identifier and requiring
+ each SMTP server to possess a trusted certificate for the envelope
+ recipient domain rather than the MX hostname. Unfortunately, this is
+ impractical as email for many domains is handled by third parties
+ that are not in a position to obtain certificates for all the domains
+ they serve. Deployment of the Server Name Indication (SNI) extension
+ to TLS (see [RFC6066] Section 3) is no panacea, since SNI key
+ management is operationally challenging except when the email service
+ provider is also the domain's registrar and its certificate issuer;
+ this is rarely the case for email.
+
+ Since the recipient domain name cannot be used as the SMTP server
+ reference identifier, and neither can the MX hostname without DNSSEC,
+ large-scale deployment of authenticated TLS for SMTP requires that
+ the DNS be secure.
+
+
+
+Dukhovni & Hardaker Expires February 3, 2015 [Page 7]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ Since SMTP security depends critically on DNSSEC, it is important to
+ point out that consequently SMTP with DANE is the most conservative
+ possible trust model. It trusts only what must be trusted and no
+ more. Adding any other trusted actors to the mix can only reduce
+ SMTP security. A sender may choose to further harden DNSSEC for
+ selected high-value receiving domains by configuring explicit trust
+ anchors for those domains instead of relying on the chain of trust
+ from the root domain. However, detailed discussion of DNSSEC
+ security practices is out of scope for this document.
+
+1.3.3. Sender policy does not scale
+
+ Sending systems are in some cases explicitly configured to use TLS
+ for mail sent to selected peer domains. This requires sending MTAs
+ to be configured with appropriate subject names or certificate
+ content digests to expect in the presented server certificates.
+ Because of the heavy administrative burden, such statically
+ configured SMTP secure channels are used rarely (generally only
+ between domains that make bilateral arrangements with their business
+ partners). Internet email, on the other hand, requires regularly
+ contacting new domains for which security configurations cannot be
+ established in advance.
+
+ The abstraction of the SMTP transport endpoint via DNS MX records,
+ often across organization boundaries, limits the use of public CA PKI
+ with SMTP to a small set of sender-configured peer domains. With
+ little opportunity to use TLS authentication, sending MTAs are rarely
+ configured with a comprehensive list of trusted CAs. SMTP services
+ that support STARTTLS often deploy X.509 certificates that are self-
+ signed or issued by a private CA.
+
+1.3.4. Too many certification authorities
+
+ Even if it were generally possible to determine a secure server name,
+ the SMTP client would still need to verify that the server's
+ certificate chain is issued by a trusted Certification Authority (a
+ trust anchor). MTAs are not interactive applications where a human
+ operator can make a decision (wisely or otherwise) to selectively
+ disable TLS security policy when certificate chain verification
+ fails. With no user to "click OK", the MTA's list of public CA trust
+ anchors would need to be comprehensive in order to avoid bouncing
+ mail addressed to sites that employ unknown Certification
+ Authorities.
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 3, 2015 [Page 8]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ On the other hand, each trusted CA can issue certificates for any
+ domain. If even one of the configured CAs is compromised or operated
+ by an adversary, it can subvert TLS security for all destinations.
+ Any set of CAs is simultaneously both overly inclusive and not
+ inclusive enough.
+
+2. Identifying applicable TLSA records
+
+2.1. DNS considerations
+
+2.1.1. DNS errors, bogus and indeterminate responses
+
+ An SMTP client that implements opportunistic DANE TLS per this
+ specification depends critically on the integrity of DNSSEC lookups,
+ as discussed in Section 1.3.2. This section lists the DNS resolver
+ requirements needed to avoid downgrade attacks when using
+ opportunistic DANE TLS.
+
+ A DNS lookup may signal an error or return a definitive answer. A
+ security-aware resolver must be used for this specification.
+ Security-aware resolvers will indicate the security status of a DNS
+ RRset with one of four possible values defined in Section 4.3 of
+ [RFC4035]: "secure", "insecure", "bogus" and "indeterminate". In
+ [RFC4035] the meaning of the "indeterminate" security status is:
+
+ An RRset for which the resolver is not able to determine whether
+ the RRset should be signed, as the resolver is not able to obtain
+ the necessary DNSSEC RRs. This can occur when the security-aware
+ resolver is not able to contact security-aware name servers for
+ the relevant zones.
+
+ Note, the "indeterminate" security status has a conflicting
+ definition in section 5 of [RFC4033].
+
+ There is no trust anchor that would indicate that a specific
+ portion of the tree is secure.
+
+ To avoid further confusion, the adjective "anchorless" will be used
+ below to refer to domains or RRsets that are "indeterminate" in the
+ [RFC4033] sense, and the term "indeterminate" will be used
+ exclusively in the sense of [RFC4035].
+
+ SMTP clients following this specification SHOULD NOT distinguish
+ between "insecure" and "anchorless" DNS responses. Both "insecure"
+ and "anchorless" RRsets MUST be handled identically: in either case
+ unvalidated data for the query domain is all that is and can be
+ available, and authentication using the data is impossible. In what
+ follows, the term "insecure" will also includes the case of
+
+
+
+Dukhovni & Hardaker Expires February 3, 2015 [Page 9]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ "anchorless" domains that lie in a portion of the DNS tree for which
+ there is no applicable trust anchor. With the DNS root zone signed,
+ we expect that validating resolvers used by Internet-facing MTAs will
+ be configured with trust anchor data for the root zone, and that
+ therefore "anchorless" domains should be rare in practice.
+
+ As noted in section 4.3 of [RFC4035], a security-aware DNS resolver
+ MUST be able to determine whether a given non-error DNS response is
+ "secure", "insecure", "bogus" or "indeterminate". It is expected
+ that most security-aware stub resolvers will not signal an
+ "indeterminate" security status (in the sense of RFC4035) to the
+ application, and will signal a "bogus" or error result instead. If a
+ resolver does signal an RFC4035 "indeterminate" security status, this
+ MUST be treated by the SMTP client as though a "bogus" or error
+ result had been returned.
+
+ An MTA making use of a non-validating security-aware stub resolver
+ MAY use the stub resolver's ability, if available, to signal DNSSEC
+ validation status based on information the stub resolver has learned
+ from an upstream validating recursive resolver. Security-Oblivious
+ stub-resolvers MUST NOT be used. In accordance with section 4.9.3 of
+ [RFC4035]:
+
+ ... a security-aware stub resolver MUST NOT place any reliance on
+ signature validation allegedly performed on its behalf, except
+ when the security-aware stub resolver obtained the data in question
+ from a trusted security-aware recursive name server via a secure
+ channel.
+
+ To avoid much repetition in the text below, we will pause to explain
+ the handling of "bogus" or "indeterminate" DNSSEC query responses.
+ These are not necessarily the result of a malicious actor; they can,
+ for example, occur when network packets are corrupted or lost in
+ transit. Therefore, "bogus" or "indeterminate" replies are equated
+ in this memo with lookup failure.
+
+ There is an important non-failure condition we need to highlight in
+ addition to the obvious case of the DNS client obtaining a non-empty
+ "secure" or "insecure" RRset of the requested type. Namely, it is
+ not an error when either "secure" or "insecure" non-existence is
+ determined for the requested data. When a DNSSEC response with a
+ validation status that is either "secure" or "insecure" reports
+ either no records of the requested type or non-existence of the query
+ domain, the response is not a DNS error condition. The DNS client
+ has not been left without an answer; it has learned that records of
+ the requested type do not exist.
+
+
+
+
+
+Dukhovni & Hardaker Expires February 3, 2015 [Page 10]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ Security-aware stub resolvers will, of course, also signal DNS lookup
+ errors in other cases, for example when processing a "ServFail"
+ RCODE, which will not have an associated DNSSEC status. All lookup
+ errors are treated the same way by this specification, regardless of
+ whether they are from a "bogus" or "indeterminate" DNSSEC status or
+ from a more generic DNS error: the information that was requested
+ cannot be obtained by the security-aware resolver at this time. A
+ lookup error is thus a failure to obtain the relevant RRset if it
+ exists, or to determine that no such RRset exists when it does not.
+
+ In contrast to a "bogus" or an "indeterminate" response, an
+ "insecure" DNSSEC response is not an error, rather it indicates that
+ the target DNS zone is either securely opted out of DNSSEC validation
+ or is not connected with the DNSSEC trust anchors being used.
+ Insecure results will leave the SMTP client with degraded channel
+ security, but do not stand in the way of message delivery. See
+ section Section 2.2 for further details.
+
+2.1.2. DNS error handling
+
+ When a DNS lookup failure (error or "bogus" or "indeterminate" as
+ defined above) prevents an SMTP client from determining which SMTP
+ server or servers it should connect to, message delivery MUST be
+ delayed. This naturally includes, for example, the case when a
+ "bogus" or "indeterminate" response is encountered during MX
+ resolution. When multiple MX hostnames are obtained from a
+ successful MX lookup, but a later DNS lookup failure prevents network
+ address resolution for a given MX hostname, delivery may proceed via
+ any remaining MX hosts.
+
+ When a particular SMTP server is securely identified as the delivery
+ destination, a set of DNS lookups (Section 2.2) MUST be performed to
+ locate any related TLSA records. If any DNS queries used to locate
+ TLSA records fail (be it due to "bogus" or "indeterminate" records,
+ timeouts, malformed replies, ServFails, etc.), then the SMTP client
+ MUST treat that server as unreachable and MUST NOT deliver the
+ message via that server. If no servers are reachable, delivery is
+ delayed.
+
+ In what follows, we will only describe what happens when all relevant
+ DNS queries succeed. If any DNS failure occurs, the SMTP client MUST
+ behave as described in this section, by skipping the problem SMTP
+ server, or the problem destination. Queries for candidate TLSA
+ records are explicitly part of "all relevant DNS queries" and SMTP
+ clients MUST NOT continue to connect to an SMTP server or destination
+ whose TLSA record lookup fails.
+
+
+
+
+
+Dukhovni & Hardaker Expires February 3, 2015 [Page 11]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+2.1.3. Stub resolver considerations
+
+ SMTP clients that employ opportunistic DANE TLS to secure connections
+ to SMTP servers MUST NOT use Security-Oblivious stub-resolvers.
+
+ A note about DNAME aliases: a query for a domain name whose ancestor
+ domain is a DNAME alias returns the DNAME RR for the ancestor domain
+ along with a CNAME that maps the query domain to the corresponding
+ sub-domain of the target domain of the DNAME alias [RFC6672].
+ Therefore, whenever we speak of CNAME aliases, we implicitly allow
+ for the possibility that the alias in question is the result of an
+ ancestor domain DNAME record. Consequently, no explicit support for
+ DNAME records is needed in SMTP software; it is sufficient to process
+ the resulting CNAME aliases. DNAME records only require special
+ processing in the validating stub-resolver library that checks the
+ integrity of the combined DNAME + CNAME reply. When DNSSEC
+ validation is handled by a local caching resolver, rather than the
+ MTA itself, even that part of the DNAME support logic is outside the
+ MTA.
+
+ When a stub resolver returns a response containing a CNAME alias that
+ does not also contain the corresponding query results for the target
+ of the alias, the SMTP client will need to repeat the query at the
+ target of the alias, and should do so recursively up to some
+ configured or implementation-dependent recursion limit. If at any
+ stage of CNAME expansion an error is detected, the lookup of the
+ original requested records MUST be considered to have failed.
+
+ Whether a chain of CNAME records was returned in a single stub
+ resolver response or via explicit recursion by the SMTP client, if at
+ any stage of recursive expansion an "insecure" CNAME record is
+ encountered, then it and all subsequent results (in particular, the
+ final result) MUST be considered "insecure" regardless of whether any
+ earlier CNAME records leading to the "insecure" record were "secure".
+
+ Note that a security-aware non-validating stub resolver may return to
+ the SMTP client an "insecure" reply received from a validating
+ recursive resolver that contains a CNAME record along with additional
+ answers recursively obtained starting at the target of the CNAME. In
+ this case, the only possible conclusion is that some record in the
+ set of records returned is "insecure", and it is in fact possible
+ that the initial CNAME record and a subset of the subsequent records
+ are "secure".
+
+ If the SMTP client needs to determine the security status of the DNS
+ zone containing the initial CNAME record, it may need to issue a
+ separate query of type "CNAME" that returns only the initial CNAME
+ record. In particular in Section 2.2.2 when insecure A or AAAA
+
+
+
+Dukhovni & Hardaker Expires February 3, 2015 [Page 12]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ records are found for an SMTP server via a CNAME alias, it may be
+ necessary to perform an additional CNAME query to determine whether
+ the DNS zone in which the alias is published is signed.
+
+2.2. TLS discovery
+
+ As noted previously (in Section 1.3.1), opportunistic TLS with SMTP
+ servers that advertise TLS support via STARTTLS is subject to an MITM
+ downgrade attack. Also some SMTP servers that are not, in fact, TLS
+ capable erroneously advertise STARTTLS by default and clients need to
+ be prepared to retry cleartext delivery after STARTTLS fails. In
+ contrast, DNSSEC validated TLSA records MUST NOT be published for
+ servers that do not support TLS. Clients can safely interpret their
+ presence as a commitment by the server operator to implement TLS and
+ STARTTLS.
+
+ This memo defines four actions to be taken after the search for a
+ TLSA record returns secure usable results, secure unusable results,
+ insecure or no results or an error signal. The term "usable" in this
+ context is in the sense of Section 4.1 of [RFC6698]. Specifically,
+ if the DNS lookup for a TLSA record returns:
+
+ A secure TLSA RRset with at least one usable record: A connection to
+ the MTA MUST be made using authenticated and encrypted TLS, using
+ the techniques discussed in the rest of this document. Failure to
+ establish an authenticated TLS connection MUST result in falling
+ back to the next SMTP server or delayed delivery.
+
+ A secure non-empty TLSA RRset where all the records are unusable: A
+ connection to the MTA MUST be made via TLS, but authentication is
+ not required. Failure to establish an encrypted TLS connection
+ MUST result in falling back to the next SMTP server or delayed
+ delivery.
+
+ An insecure TLSA RRset or DNSSEC validated proof-of-non-existent TLSA
+ records:
+ A connection to the MTA SHOULD be made using (pre-DANE)
+ opportunistic TLS, this includes using cleartext delivery when the
+ remote SMTP server does not appear to support TLS. The MTA MAY
+ retry in cleartext when delivery via TLS fails either during the
+ handshake or even during data transfer.
+
+ Any lookup error: Lookup errors, including "bogus" and
+ "indeterminate", as explained in Section 2.1.1 MUST result in
+ falling back to the next SMTP server or delayed delivery.
+
+ An SMTP client MAY be configured to require DANE verified delivery
+ for some destinations. We will call such a configuration "mandatory
+
+
+
+Dukhovni & Hardaker Expires February 3, 2015 [Page 13]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ DANE TLS". With mandatory DANE TLS, delivery proceeds only when
+ "secure" TLSA records are used to establish an encrypted and
+ authenticated TLS channel with the SMTP server.
+
+ When the original next-hop destination is an address literal, rather
+ than a DNS domain, DANE TLS does not apply. Delivery proceeds using
+ any relevant security policy configured by the MTA administrator.
+ Similarly, when an MX RRset incorrectly lists a network address in
+ lieu of an MX hostname, if an MTA chooses to connect to the network
+ address in the non-conformat MX record, DANE TLSA does not apply for
+ such a connection.
+
+ In the subsections that follow we explain how to locate the SMTP
+ servers and the associated TLSA records for a given next-hop
+ destination domain. We also explain which name or names are to be
+ used in identity checks of the SMTP server certificate.
+
+2.2.1. MX resolution
+
+ In this section we consider next-hop domains that are subject to MX
+ resolution and have MX records. The TLSA records and the associated
+ base domain are derived separately for each MX hostname that is used
+ to attempt message delivery. DANE TLS can authenticate message
+ delivery to the intended next-hop domain only when the MX records are
+ obtained securely via a DNSSEC validated lookup.
+
+ MX records MUST be sorted by preference; an MX hostname with a worse
+ (numerically higher) MX preference that has TLSA records MUST NOT
+ preempt an MX hostname with a better (numerically lower) preference
+ that has no TLSA records. In other words, prevention of delivery
+ loops by obeying MX preferences MUST take precedence over channel
+ security considerations. Even with two equal-preference MX records,
+ an MTA is not obligated to choose the MX hostname that offers more
+ security. Domains that want secure inbound mail delivery need to
+ ensure that all their SMTP servers and MX records are configured
+ accordingly.
+
+ In the language of [RFC5321] Section 5.1, the original next-hop
+ domain is the "initial name". If the MX lookup of the initial name
+ results in a CNAME alias, the MTA replaces the initial name with the
+ resulting name and performs a new lookup with the new name. MTAs
+ typically support recursion in CNAME expansion, so this replacement
+ is performed repeatedly (up to the MTA's recursion limit) until the
+ ultimate non-CNAME domain is found.
+
+ If the MX RRset (or any CNAME leading to it) is "insecure" (see
+ Section 2.1.1), DANE TLS need not apply, and delivery MAY proceed via
+ pre-DANE opportunistic TLS. That said, the protocol in this memo is
+
+
+
+Dukhovni & Hardaker Expires February 3, 2015 [Page 14]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ an "opportunistic security" protocol, meaning that it strives to
+ communicate with each peer as securely as possible, while maintaining
+ broad interoperability. Therefore, the SMTP client MAY proceed to
+ use DANE TLS (as described in Section 2.2.2 below) even with MX hosts
+ obtained via an "insecure" MX RRset. For example, when a hosting
+ provider has a signed DNS zone and publishes TLSA records for its
+ SMTP servers, hosted domains that are not signed may still benefit
+ from the provider's TLSA records. Deliveries via the provider's SMTP
+ servers will not be subject to active attacks when sending SMTP
+ clients elect to make use of the provider's TLSA records.
+
+ When the MX records are not (DNSSEC) signed, an active attacker can
+ redirect SMTP clients to MX hosts of his choice. Such redirection is
+ tamper-evident when SMTP servers found via "insecure" MX records are
+ recorded as the next-hop relay in the MTA delivery logs in their
+ original (rather than CNAME expanded) form. Sending MTAs SHOULD log
+ unexpanded MX hostnames when these result from insecure MX lookups.
+ Any successful authentication via an insecurely determined MX host
+ MUST NOT be misrepresented in the mail logs as secure delivery to the
+ intended next-hop domain. When DANE TLS is mandatory (Section 6) for
+ a given destination, delivery MUST be delayed when the MX RRset is
+ not "secure".
+
+ Otherwise, assuming no DNS errors (Section 2.1.1), the MX RRset is
+ "secure", and the SMTP client MUST treat each MX hostname as a
+ separate non-MX destination for opportunistic DANE TLS as described
+ in Section 2.2.2. When, for a given MX hostname, no TLSA records are
+ found, or only "insecure" TLSA records are found, DANE TLSA is not
+ applicable with the SMTP server in question and delivery proceeds to
+ that host as with pre-DANE opportunistic TLS. To avoid downgrade
+ attacks, any errors during TLSA lookups MUST, as explained in
+ Section 2.1.1, cause the SMTP server in question to be treated as
+ unreachable.
+
+2.2.2. Non-MX destinations
+
+ This section describes the algorithm used to locate the TLSA records
+ and associated TLSA base domain for an input domain not subject to MX
+ resolution. Such domains include:
+
+ o Each MX hostname used in a message delivery attempt for an
+ original next-hop destination domain subject to MX resolution.
+ Note, MTAs are not obligated to support CNAME expansion of MX
+ hostnames.
+
+ o Any administrator configured relay hostname, not subject to MX
+ resolution. This frequently involves configuration set by the MTA
+ administrator to handle some or all mail.
+
+
+
+Dukhovni & Hardaker Expires February 3, 2015 [Page 15]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ o A next-hop destination domain subject to MX resolution that has no
+ MX records. In this case the domain's name is implicitly also its
+ sole SMTP server name.
+
+ Note that DNS queries with type TLSA are mishandled by load balancing
+ nameservers that serve the MX hostnames of some large email
+ providers. The DNS zones served by these nameservers are not signed
+ and contain no TLSA records, but queries for TLSA records fail,
+ rather than returning the non-existence of the requested TLSA
+ records.
+
+ To avoid problems delivering mail to domains whose SMTP servers are
+ served by the problem nameservers the SMTP client MUST perform any A
+ and/or AAAA queries for the destination before attempting to locate
+ the associated TLSA records. This lookup is needed in any case to
+ determine whether the destination domain is reachable and the DNSSEC
+ validation status of the chain of CNAME queries required to reach the
+ ultimate address records.
+
+ If no address records are found, the destination is unreachable. If
+ address records are found, but the DNSSEC validation status of the
+ first query response is "insecure" (see Section 2.1.3), the SMTP
+ client SHOULD NOT proceed to search for any associated TLSA records.
+ With the problem domains, TLSA queries will lead to DNS lookup errors
+ and cause messages to be consistently delayed and ultimately returned
+ to the sender. We don't expect to find any "secure" TLSA records
+ associated with a TLSA base domain that lies in an unsigned DNS zone.
+ Therefore, skipping TLSA lookups in this case will also reduce
+ latency with no detrimental impact on security.
+
+ If the A and/or AAAA lookup of the "initial name" yields a CNAME, we
+ replace it with the resulting name as if it were the initial name and
+ perform a lookup again using the new name. This replacement is
+ performed recursively (up to the MTA's recursion limit).
+
+ We consider the following cases for handling a DNS response for an A
+ or AAAA DNS lookup:
+
+ Not found: When the DNS queries for A and/or AAAA records yield
+ neither a list of addresses nor a CNAME (or CNAME expansion is not
+ supported) the destination is unreachable.
+
+
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 3, 2015 [Page 16]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ Non-CNAME: The answer is not a CNAME alias. If the address RRset
+ is "secure", TLSA lookups are performed as described in
+ Section 2.2.3 with the initial name as the candidate TLSA base
+ domain. If no "secure" TLSA records are found, DANE TLS is not
+ applicable and mail delivery proceeds with pre-DANE opportunistic
+ TLS (which, being best-effort, degrades to cleartext delivery when
+ STARTTLS is not available or the TLS handshake fails).
+
+ Insecure CNAME: The input domain is a CNAME alias, but the ultimate
+ network address RRset is "insecure" (see Section 2.1.1). If the
+ initial CNAME response is also "insecure", DANE TLS does not
+ apply. Otherwise, this case is treated just like the non-CNAME
+ case above, where a search is performed for a TLSA record with the
+ original input domain as the candidate TLSA base domain.
+
+ Secure CNAME: The input domain is a CNAME alias, and the ultimate
+ network address RRset is "secure" (see Section 2.1.1). Two
+ candidate TLSA base domains are tried: the fully CNAME-expanded
+ initial name and, failing that, then the initial name itself.
+
+ In summary, if it is possible to securely obtain the full, CNAME-
+ expanded, DNSSEC-validated address records for the input domain, then
+ that name is the preferred TLSA base domain. Otherwise, the
+ unexpanded input-MX domain is the candidate TLSA base domain. When
+ no "secure" TLSA records are found at either the CNAME-expanded or
+ unexpanded domain, then DANE TLS does not apply for mail delivery via
+ the input domain in question. And, as always, errors, bogus or
+ indeterminate results for any query in the process MUST result in
+ delaying or abandoning delivery.
+
+2.2.3. TLSA record lookup
+
+ Each candidate TLSA base domain (the original or fully CNAME-expanded
+ name of a non-MX destination or a particular MX hostname of an MX
+ destination) is in turn prefixed with service labels of the form
+ "_<port>._tcp". The resulting domain name is used to issue a DNSSEC
+ query with the query type set to TLSA ([RFC6698] Section 7.1).
+
+ For SMTP, the destination TCP port is typically 25, but this may be
+ different with custom routes specified by the MTA administrator in
+ which case the SMTP client MUST use the appropriate number in the
+ "_<port>" prefix in place of "_25". If, for example, the candidate
+ base domain is "mx.example.com", and the SMTP connection is to port
+ 25, the TLSA RRset is obtained via a DNSSEC query of the form:
+
+ _25._tcp.mx.example.com. IN TLSA ?
+
+
+
+
+
+Dukhovni & Hardaker Expires February 3, 2015 [Page 17]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ The query response may be a CNAME, or the actual TLSA RRset. If the
+ response is a CNAME, the SMTP client (through the use of its
+ security-aware stub resolver) restarts the TLSA query at the target
+ domain, following CNAMEs as appropriate and keeping track of whether
+ the entire chain is "secure". If any "insecure" records are
+ encountered, or the TLSA records don't exist, the next candidate TLSA
+ base domain is tried instead.
+
+ If the ultimate response is a "secure" TLSA RRset, then the candidate
+ TLSA base domain will be the actual TLSA base domain and the TLSA
+ RRset will constitute the TLSA records for the destination. If none
+ of the candidate TLSA base domains yield "secure" TLSA records then
+ delivery MAY proceed via pre-DANE opportunistic TLS. SMTP clients
+ MAY elect to use "insecure" TLSA records to avoid STARTTLS downgrades
+ or even to skip SMTP servers that fail authentication, but MUST NOT
+ misrepresent authentication success as either a secure connection to
+ the SMTP server or as a secure delivery to the intended next-hop
+ domain.
+
+ TLSA record publishers may leverage CNAMEs to reference a single
+ authoritative TLSA RRset specifying a common Certification Authority
+ or a common end entity certificate to be used with multiple TLS
+ services. Such CNAME expansion does not change the SMTP client's
+ notion of the TLSA base domain; thus, when _25._tcp.mx.example.com is
+ a CNAME, the base domain remains mx.example.com and this is still the
+ reference identifier used together with the next-hop domain in peer
+ certificate name checks.
+
+ Note that shared end entity certificate associations expose the
+ publishing domain to substitution attacks, where an MITM attacker can
+ reroute traffic to a different server that shares the same end entity
+ certificate. Such shared end entity TLSA records SHOULD be avoided
+ unless the servers in question are functionally equivalent or employ
+ mutually incompatible protocols (an active attacker gains nothing by
+ diverting client traffic from one such server to another).
+
+ A better example, employing a shared trust anchor rather than shared
+ end-entity certificates, is illustrated by the DNSSEC validated
+ records below:
+
+ example.com. IN MX 0 mx1.example.com.
+ example.com. IN MX 0 mx2.example.com.
+ _25._tcp.mx1.example.com. IN CNAME tlsa201._dane.example.com.
+ _25._tcp.mx2.example.com. IN CNAME tlsa201._dane.example.com.
+ tlsa201._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c149a...
+
+ The SMTP servers mx1.example.com and mx2.example.com will be expected
+ to have certificates issued under a common trust anchor, but each MX
+
+
+
+Dukhovni & Hardaker Expires February 3, 2015 [Page 18]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ hostname's TLSA base domain remains unchanged despite the above CNAME
+ records. Correspondingly, each SMTP server will be associated with a
+ pair of reference identifiers consisting of its hostname plus the
+ next-hop domain "example.com".
+
+ If, during TLSA resolution (including possible CNAME indirection), at
+ least one "secure" TLSA record is found (even if not usable because
+ it is unsupported by the implementation or support is
+ administratively disabled), then the corresponding host has signaled
+ its commitment to implement TLS. The SMTP client MUST NOT deliver
+ mail via the corresponding host unless a TLS session is negotiated
+ via STARTTLS. This is required to avoid MITM STARTTLS downgrade
+ attacks.
+
+ As noted previously (in Section Section 2.2.2), when no "secure" TLSA
+ records are found at the fully CNAME-expanded name, the original
+ unexpanded name MUST be tried instead. This supports customers of
+ hosting providers where the provider's zone cannot be validated with
+ DNSSEC, but the customer has shared appropriate key material with the
+ hosting provider to enable TLS via SNI. Intermediate names that
+ arise during CNAME expansion that are neither the original, nor the
+ final name, are never candidate TLSA base domains, even if "secure".
+
+3. DANE authentication
+
+ This section describes which TLSA records are applicable to SMTP
+ opportunistic DANE TLS and how to apply such records to authenticate
+ the SMTP server. With opportunistic DANE TLS, both the TLS support
+ implied by the presence of DANE TLSA records and the verification
+ parameters necessary to authenticate the TLS peer are obtained
+ together. In contrast to protocols where channel security policy is
+ set exclusively by the client, authentication via this protocol is
+ expected to be less prone to connection failure caused by
+ incompatible configuration of the client and server.
+
+3.1. TLSA certificate usages
+
+ The DANE TLSA specification [RFC6698] defines multiple TLSA RR types
+ via combinations of 3 numeric parameters. The numeric values of
+ these parameters were later given symbolic names in [RFC7218]. The
+ rest of the TLSA record is the "certificate association data field",
+ which specifies the full or digest value of a certificate or public
+ key. The parameters are:
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 3, 2015 [Page 19]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ The TLSA Certificate Usage field: Section 2.1.1 of [RFC6698]
+ specifies four values: PKIX-TA(0), PKIX-EE(1), DANE-TA(2), and
+ DANE-EE(3). There is an additional private-use value:
+ PrivCert(255). All other values are reserved for use by future
+ specifications.
+
+ The selector field: Section 2.1.2 of [RFC6698] specifies two values:
+ Cert(0) and SPKI(1). There is an additional private-use value:
+ PrivSel(255). All other values are reserved for use by future
+ specifications.
+
+ The matching type field: Section 2.1.3 of [RFC6698] specifies three
+ values: Full(0), SHA2-256(1) and SHA2-512(2). There is an
+ additional private-use value: PrivMatch(255). All other values
+ are reserved for use by future specifications.
+
+ We may think of TLSA Certificate Usage values 0 through 3 as a
+ combination of two one-bit flags. The low bit chooses between trust
+ anchor (TA) and end entity (EE) certificates. The high bit chooses
+ between public PKI issued and domain-issued certificates.
+
+ The selector field specifies whether the TLSA RR matches the whole
+ certificate: Cert(0), or just its subjectPublicKeyInfo: SPKI(1). The
+ subjectPublicKeyInfo is an ASN.1 DER ([X.690]) encoding of the
+ certificate's algorithm id, any parameters and the public key data.
+
+ The matching type field specifies how the TLSA RR Certificate
+ Association Data field is to be compared with the certificate or
+ public key. A value of Full(0) means an exact match: the full DER
+ encoding of the certificate or public key is given in the TLSA RR. A
+ value of SHA2-256(1) means that the association data matches the
+ SHA2-256 digest of the certificate or public key, and likewise
+ SHA2-512(2) means a SHA2-512 digest is used.
+
+ Since opportunistic DANE TLS will be used by non-interactive MTAs,
+ with no user to "press OK" when authentication fails, reliability of
+ peer authentication is paramount. Server operators are advised to
+ publish TLSA records that are least likely to fail authentication due
+ to interoperability or operational problems. Because DANE TLS relies
+ on coordinated changes to DNS and SMTP server settings, the best
+ choice of records to publish will depend on site-specific practices.
+
+
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 3, 2015 [Page 20]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ The certificate usage element of a TLSA record plays a critical role
+ in determining how the corresponding certificate association data
+ field is used to authenticate server's certificate chain. The next
+ two subsections explain the process for certificate usages DANE-EE(3)
+ and DANE-TA(2). The third subsection briefly explains why
+ certificate usages PKIX-TA(0) and PKIX-EE(1) are not applicable with
+ opportunistic DANE TLS.
+
+ In summary, we recommend the use of either "DANE-EE(3) SPKI(1)
+ SHA2-256(1)" or "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA records
+ depending on site needs. Other combinations of TLSA parameters are
+ either explicitly unsupported, or offer little to recommend them over
+ these two.
+
+ The mandatory to support digest algorithm in [RFC6698] is
+ SHA2-256(1). When the server's TLSA RRset includes records with a
+ matching type indicating a digest record (i.e., a value other than
+ Full(0)), a TLSA record with a SHA2-256(1) matching type SHOULD be
+ provided along with any other digest published, since some SMTP
+ clients may support only SHA2-256(1). If at some point the SHA2-256
+ digest algorithm is tarnished by new cryptanalytic attacks,
+ publishers will need to include an appropriate stronger digest in
+ their TLSA records, initially along with, and ultimately in place of,
+ SHA2-256.
+
+3.1.1. Certificate usage DANE-EE(3)
+
+ Authentication via certificate usage DANE-EE(3) TLSA records involves
+ simply checking that the server's leaf certificate matches the TLSA
+ record. In particular the binding of the server public key to its
+ name is based entirely on the TLSA record association. The server
+ MUST be considered authenticated even if none of the names in the
+ certificate match the client's reference identity for the server.
+
+ Similarly, the expiration date of the server certificate MUST be
+ ignored, the validity period of the TLSA record key binding is
+ determined by the validity interval of the TLSA record DNSSEC
+ signature.
+
+ With DANE-EE(3) servers need not employ SNI (may ignore the client's
+ SNI message) even when the server is known under independent names
+ that would otherwise require separate certificates. It is instead
+ sufficient for the TLSA RRsets for all the domains in question to
+ match the server's default certificate. Of course with SMTP servers
+ it is simpler still to publish the same MX hostname for all the
+ hosted domains.
+
+
+
+
+
+Dukhovni & Hardaker Expires February 3, 2015 [Page 21]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ For domains where it is practical to make coordinated changes in DNS
+ TLSA records during SMTP server key rotation, it is often best to
+ publish end-entity DANE-EE(3) certificate associations. DANE-EE(3)
+ certificates don't suddenly stop working when leaf or intermediate
+ certificates expire, and don't fail when the server operator neglects
+ to configure all the required issuer certificates in the server
+ certificate chain.
+
+ TLSA records published for SMTP servers SHOULD, in most cases, be
+ "DANE-EE(3) SPKI(1) SHA2-256(1)" records. Since all DANE
+ implementations are required to support SHA2-256, this record type
+ works for all clients and need not change across certificate renewals
+ with the same key.
+
+3.1.2. Certificate usage DANE-TA(2)
+
+ Some domains may prefer to avoid the operational complexity of
+ publishing unique TLSA RRs for each TLS service. If the domain
+ employs a common issuing Certification Authority to create
+ certificates for multiple TLS services, it may be simpler to publish
+ the issuing authority as a trust anchor (TA) for the certificate
+ chains of all relevant services. The TLSA query domain (TLSA base
+ domain with port and protocol prefix labels) for each service issued
+ by the same TA may then be set to a CNAME alias that points to a
+ common TLSA RRset that matches the TA. For example:
+
+ example.com. IN MX 0 mx1.example.com.
+ example.com. IN MX 0 mx2.example.com.
+ _25._tcp.mx1.example.com. IN CNAME tlsa201._dane.example.com.
+ _25._tcp.mx2.example.com. IN CNAME tlsa201._dane.example.com.
+ tlsa201._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c14....
+
+ With usage DANE-TA(2) the server certificates will need to have names
+ that match one of the client's reference identifiers (see [RFC6125]).
+ The server MAY employ SNI to select the appropriate certificate to
+ present to the client.
+
+ SMTP servers that rely on certificate usage DANE-TA(2) TLSA records
+ for TLS authentication MUST include the TA certificate as part of the
+ certificate chain presented in the TLS handshake server certificate
+ message even when it is a self-signed root certificate. At this
+ time, many SMTP servers are not configured with a comprehensive list
+ of trust anchors, nor are they expected to at any point in the
+ future. Some MTAs will ignore all locally trusted certificates when
+ processing usage DANE-TA(2) TLSA records. Thus even when the TA
+ happens to be a public Certification Authority known to the SMTP
+ client, authentication is likely to fail unless the TA certificate is
+ included in the TLS server certificate message.
+
+
+
+Dukhovni & Hardaker Expires February 3, 2015 [Page 22]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ TLSA records with selector Full(0) are discouraged. While these
+ potentially obviate the need to transmit the TA certificate in the
+ TLS server certificate message, client implementations may not be
+ able to augment the server certificate chain with the data obtained
+ from DNS, especially when the TLSA record supplies a bare key
+ (selector SPKI(1)). Since the server will need to transmit the TA
+ certificate in any case, server operators SHOULD publish TLSA records
+ with a selector other than Full(0) and avoid potential
+ interoperability issues with large TLSA records containing full
+ certificates or keys.
+
+ TLSA Publishers employing DANE-TA(2) records SHOULD publish records
+ with a selector of Cert(0). Such TLSA records are associated with
+ the whole trust anchor certificate, not just with the trust anchor
+ public key. In particular, the SMTP client SHOULD then apply any
+ relevant constraints from the trust anchor certificate, such as, for
+ example, path length constraints.
+
+ While a selector of SPKI(1) may also be employed, the resulting TLSA
+ record will not specify the full trust anchor certificate content,
+ and elements of the trust anchor certificate other than the public
+ key become mutable. This may, for example, allow a subsidiary CA to
+ issue a chain that violates the trust anchor's path length or name
+ constraints.
+
+3.1.3. Certificate usages PKIX-TA(0) and PKIX-EE(1)
+
+ As noted in the introduction, SMTP clients cannot, without relying on
+ DNSSEC for secure MX records and DANE for STARTTLS support signaling,
+ perform server identity verification or prevent STARTTLS downgrade
+ attacks. The use of PKIX CAs offers no added security since an
+ attacker capable of compromising DNSSEC is free to replace any PKIX-
+ TA(0) or PKIX-EE(1) TLSA records with records bearing any convenient
+ non-PKIX certificate usage.
+
+ SMTP servers SHOULD NOT publish TLSA RRs with certificate usage PKIX-
+ TA(0) or PKIX-EE(1). SMTP clients cannot be expected to be
+ configured with a suitably complete set of trusted public CAs.
+ Lacking a complete set of public CAs, clients would not be able to
+ verify the certificates of SMTP servers whose issuing root CAs are
+ not trusted by the client.
+
+ Opportunistic DANE TLS needs to interoperate without bilateral
+ coordination of security settings between client and server systems.
+ Therefore, parameter choices that are fragile in the absence of
+ bilateral coordination are unsupported. Nothing is lost since the
+ PKIX certificate usages cannot aid SMTP TLS security, they can only
+ impede SMTP TLS interoperability.
+
+
+
+Dukhovni & Hardaker Expires February 3, 2015 [Page 23]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ SMTP client treatment of TLSA RRs with certificate usages PKIX-TA(0)
+ or PKIX-EE(1) is undefined. SMTP clients should generally treat such
+ TLSA records as unusable.
+
+3.2. Certificate matching
+
+ When at least one usable "secure" TLSA record is found, the SMTP
+ client MUST use TLSA records to authenticate the SMTP server.
+ Messages MUST NOT be delivered via the SMTP server if authentication
+ fails, otherwise the SMTP client is vulnerable to MITM attacks.
+
+3.2.1. DANE-EE(3) name checks
+
+ The SMTP client MUST NOT perform certificate name checks with
+ certificate usage DANE-EE(3); see Section 3.1.1 above.
+
+3.2.2. DANE-TA(2) name checks
+
+ To match a server via a TLSA record with certificate usage DANE-
+ TA(2), the client MUST perform name checks to ensure that it has
+ reached the correct server. In all DANE-TA(2) cases the SMTP client
+ MUST include the TLSA base domain as one of the valid reference
+ identifiers for matching the server certificate.
+
+ TLSA records for MX hostnames: If the TLSA base domain was obtained
+ indirectly via a "secure" MX lookup (including any CNAME-expanded
+ name of an MX hostname), then the original next-hop domain used in
+ the MX lookup MUST be included as as a second reference
+ identifier. The CNAME-expanded original next-hop domain MUST be
+ included as a third reference identifier if different from the
+ original next-hop domain. When the client MTA is employing DANE
+ TLS security despite "insecure" MX redirection the MX hostname is
+ the only reference identifier.
+
+ TLSA records for Non-MX hostnames: If MX records were not used
+ (e.g., if none exist) and the TLSA base domain is the CNAME-
+ expanded original next-hop domain, then the original next-hop
+ domain MUST be included as a second reference identifier.
+
+ Accepting certificates with the original next-hop domain in addition
+ to the MX hostname allows a domain with multiple MX hostnames to
+ field a single certificate bearing a single domain name (i.e., the
+ email domain) across all the SMTP servers. This also aids
+ interoperability with pre-DANE SMTP clients that are configured to
+ look for the email domain name in server certificates. For example,
+ with "secure" DNS records as below:
+
+
+
+
+
+Dukhovni & Hardaker Expires February 3, 2015 [Page 24]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ exchange.example.org. IN CNAME mail.example.org.
+ mail.example.org. IN CNAME example.com.
+ example.com. IN MX 10 mx10.example.com.
+ example.com. IN MX 15 mx15.example.com.
+ example.com. IN MX 20 mx20.example.com.
+ ;
+ mx10.example.com. IN A 192.0.2.10
+ _25._tcp.mx10.example.com. IN TLSA 2 0 1 ...
+ ;
+ mx15.example.com. IN CNAME mxbackup.example.com.
+ mxbackup.example.com. IN A 192.0.2.15
+ ; _25._tcp.mxbackup.example.com. IN TLSA ? (NXDOMAIN)
+ _25._tcp.mx15.example.com. IN TLSA 2 0 1 ...
+ ;
+ mx20.example.com. IN CNAME mxbackup.example.net.
+ mxbackup.example.net. IN A 198.51.100.20
+ _25._tcp.mxbackup.example.net. IN TLSA 2 0 1 ...
+
+ Certificate name checks for delivery of mail to exchange.example.org
+ via any of the associated SMTP servers MUST accept at least the names
+ "exchange.example.org" and "example.com", which are respectively the
+ original and fully expanded next-hop domain. When the SMTP server is
+ mx10.example.com, name checks MUST accept the TLSA base domain
+ "mx10.example.com". If, despite the fact that MX hostnames are
+ required to not be aliases, the MTA supports delivery via
+ "mx15.example.com" or "mx20.example.com" then name checks MUST accept
+ the respective TLSA base domains "mx15.example.com" and
+ "mxbackup.example.net".
+
+3.2.3. Reference identifier matching
+
+ When name checks are applicable (certificate usage DANE-TA(2)), if
+ the server certificate contains a Subject Alternative Name extension
+ ([RFC5280]), with at least one DNS-ID ([RFC6125]) then only the DNS-
+ IDs are matched against the client's reference identifiers. The CN-
+ ID ([RFC6125]) is only considered when no DNS-IDs are present. The
+ server certificate is considered matched when one of its presented
+ identifiers ([RFC5280]) matches any of the client's reference
+ identifiers.
+
+ Wildcards are valid in either DNS-IDs or the CN-ID when applicable.
+ The wildcard character must be entire first label of the DNS-ID or
+ CN-ID. Thus, "*.example.com" is valid, while "smtp*.example.com" and
+ "*smtp.example.com" are not. SMTP clients MUST support wildcards
+ that match the first label of the reference identifier, with the
+ remaining labels matching verbatim. For example, the DNS-ID
+ "*.example.com" matches the reference identifier "mx1.example.com".
+ SMTP clients MAY, subject to local policy allow wildcards to match
+
+
+
+Dukhovni & Hardaker Expires February 3, 2015 [Page 25]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ multiple reference identifier labels, but servers cannot expect broad
+ support for such a policy. Therefore any wildcards in server
+ certificates SHOULD match exactly one label in either the TLSA base
+ domain or the next-hop domain.
+
+4. Server key management
+
+ Two TLSA records MUST be published before employing a new EE or TA
+ public key or certificate, one matching the currently deployed key
+ and the other matching the new key scheduled to replace it. Once
+ sufficient time has elapsed for all DNS caches to expire the previous
+ TLSA RRset and related signature RRsets, servers may be configured to
+ use the new EE private key and associated public key certificate or
+ may employ certificates signed by the new trust anchor.
+
+ Once the new public key or certificate is in use, the TLSA RR that
+ matches the retired key can be removed from DNS, leaving only RRs
+ that match keys or certificates in active use.
+
+ As described in Section 3.1.2, when server certificates are validated
+ via a DANE-TA(2) trust anchor, and CNAME records are employed to
+ store the TA association data at a single location, the
+ responsibility of updating the TLSA RRset shifts to the operator of
+ the trust anchor. Before a new trust anchor is used to sign any new
+ server certificates, its certificate (digest) is added to the
+ relevant TLSA RRset. After enough time elapses for the original TLSA
+ RRset to age out of DNS caches, the new trust anchor can start
+ issuing new server certificates. Once all certificates issued under
+ the previous trust anchor have expired, its associated RRs can be
+ removed from the TLSA RRset.
+
+ In the DANE-TA(2) key management model server operators do not
+ generally need to update DNS TLSA records after initially creating a
+ CNAME record that references the centrally operated DANE-TA(2) RRset.
+ If a particular server's key is compromised, its TLSA CNAME SHOULD be
+ replaced with a DANE-EE(3) association until the certificate for the
+ compromised key expires, at which point it can return to using CNAME
+ record. If the central trust anchor is compromised, all servers need
+ to be issued new keys by a new TA, and a shared DANE-TA(2) TLSA RRset
+ needs to be published containing just the new TA. SMTP servers
+ cannot expect broad SMTP client CRL or OCSP support.
+
+5. Digest algorithm agility
+
+ While [RFC6698] specifies multiple digest algorithms, it does not
+ specify a protocol by which the SMTP client and TLSA record publisher
+ can agree on the strongest shared algorithm. Such a protocol would
+ allow the client and server to avoid exposure to any deprecated
+
+
+
+Dukhovni & Hardaker Expires February 3, 2015 [Page 26]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ weaker algorithms that are published for compatibility with less
+ capable clients, but should be ignored when possible. We specify
+ such a protocol below.
+
+ Suppose that a DANE TLS client authenticating a TLS server considers
+ digest algorithm "BetterAlg" stronger than digest algorithm
+ "WorseAlg". Suppose further that a server's TLSA RRset contains some
+ records with "BetterAlg" as the digest algorithm. Finally, suppose
+ that for every raw public key or certificate object that is included
+ in the server's TLSA RRset in digest form, whenever that object
+ appears with algorithm "WorseAlg" with some usage and selector it
+ also appears with algorithm "BetterAlg" with the same usage and
+ selector. In that case our client can safely ignore TLSA records
+ with the weaker algorithm "WorseAlg", because it suffices to check
+ the records with the stronger algorithm "BetterAlg".
+
+ Server operators MUST ensure that for any given usage and selector,
+ each object (certificate or public key), for which a digest
+ association exists in the TLSA RRset, is published with the SAME SET
+ of digest algorithms as all other objects that published with that
+ usage and selector. In other words, for each usage and selector, the
+ records with non-zero matching types will correspond to on a cross-
+ product of a set of underlying objects and a fixed set of digest
+ algorithms that apply uniformly to all the objects.
+
+ To achieve digest algorithm agility, all published TLSA RRsets for
+ use with opportunistic DANE TLS for SMTP MUST conform to the above
+ requirements. Then, for each combination of usage and selector, SMTP
+ clients can simply ignore all digest records except those that employ
+ the strongest digest algorithm. The ordering of digest algorithms by
+ strength is not specified in advance, it is entirely up to the SMTP
+ client. SMTP client implementations SHOULD make the digest algorithm
+ preference order configurable. Only the future will tell which
+ algorithms might be weakened by new attacks and when.
+
+ Note, TLSA records with a matching type of Full(0), that publish the
+ full value of a certificate or public key object, play no role in
+ digest algorithm agility. They neither trump the processing of
+ records that employ digests, nor are they ignored in the presence of
+ any records with a digest (i.e. non-zero) matching type.
+
+
+
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 3, 2015 [Page 27]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ SMTP clients SHOULD use digest algorithm agility when processing the
+ DANE TLSA records of an SMTP server. Algorithm agility is to be
+ applied after first discarding any unusable or malformed records
+ (unsupported digest algorithm, or incorrect digest length). Thus,
+ for each usage and selector, the client SHOULD process only any
+ usable records with a matching type of Full(0) and the usable records
+ whose digest algorithm is believed to be the strongest among usable
+ records with the given usage and selector.
+
+ The main impact of this requirement is on key rotation, when the TLSA
+ RRset is pre-populated with digests of new certificates or public
+ keys, before these replace or augment their predecessors. Were the
+ newly introduced RRs to include previously unused digest algorithms,
+ clients that employ this protocol could potentially ignore all the
+ digests corresponding to the current keys or certificates, causing
+ connectivity issues until the new keys or certificates are deployed.
+ Similarly, publishing new records with fewer digests could cause
+ problems for clients using cached TLSA RRsets that list both the old
+ and new objects once the new keys are deployed.
+
+ To avoid problems, server operators SHOULD apply the following
+ strategy:
+
+ o When changing the set of objects published via the TLSA RRset
+ (e.g. during key rotation), DO NOT change the set of digest
+ algorithms used; change just the list of objects.
+
+ o When changing the set of digest algorithms, change only the set of
+ algorithms, and generate a new RRset in which all the current
+ objects are re-published with the new set of digest algorithms.
+
+ After either of these two changes are made, the new TLSA RRset should
+ be left in place long enough that the older TLSA RRset can be flushed
+ from caches before making another change.
+
+6. Mandatory TLS Security
+
+ An MTA implementing this protocol may require a stronger security
+ assurance when sending email to selected destinations. The sending
+ organization may need to send sensitive email and/or may have
+ regulatory obligations to protect its content. This protocol is not
+ in conflict with such a requirement, and in fact can often simplify
+ authenticated delivery to such destinations.
+
+ Specifically, with domains that publish DANE TLSA records for their
+ MX hostnames, a sending MTA can be configured to use the receiving
+ domains's DANE TLSA records to authenticate the corresponding SMTP
+ server. Authentication via DANE TLSA records is easier to manage, as
+
+
+
+Dukhovni & Hardaker Expires February 3, 2015 [Page 28]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ changes in the receiver's expected certificate properties are made on
+ the receiver end and don't require manually communicated
+ configuration changes. With mandatory DANE TLS, when no usable TLSA
+ records are found, message delivery is delayed. Thus, mail is only
+ sent when an authenticated TLS channel is established to the remote
+ SMTP server.
+
+ Administrators of mail servers that employ mandatory DANE TLS, need
+ to carefully monitor their mail logs and queues. If a partner domain
+ unwittingly misconfigures their TLSA records, disables DNSSEC, or
+ misconfigures SMTP server certificate chains, mail will be delayed
+ and may bounce if the issue is not resolved in a timely manner.
+
+7. Note on DANE for Message User Agents
+
+ We note that the SMTP protocol is also used between Message User
+ Agents (MUAs) and Message Submission Agents (MSAs) [RFC6409]. In
+ [RFC6186] a protocol is specified that enables an MUA to dynamically
+ locate the MSA based on the user's email address. SMTP connection
+ security considerations for MUAs implementing [RFC6186] are largely
+ analogous to connection security requirements for MTAs, and this
+ specification could be applied largely verbatim with DNS MX records
+ replaced by corresponding DNS Service (SRV) records
+ [I-D.ietf-dane-srv].
+
+ However, until MUAs begin to adopt the dynamic configuration
+ mechanisms of [RFC6186] they are adequately served by more
+ traditional static TLS security policies. Specification of DANE TLS
+ for Message User Agent (MUA) to Message Submission Agent (MSA) SMTP
+ is left to future documents that focus specifically on SMTP security
+ between MUAs and MSAs.
+
+8. Interoperability considerations
+
+8.1. SNI support
+
+ To ensure that the server sends the right certificate chain, the SMTP
+ client MUST send the TLS SNI extension containing the TLSA base
+ domain. This precludes the use of the backward compatible SSL 2.0
+ compatible SSL HELLO by the SMTP client. The minimum SSL/TLS client
+ HELLO version for SMTP clients performing DANE authentication is SSL
+ 3.0, but a client that offers SSL 3.0 MUST also offer at least TLS
+ 1.0 and MUST include the SNI extension. Servers that don't make use
+ of SNI MAY negotiate SSL 3.0 if offered by the client.
+
+ Each SMTP server MUST present a certificate chain (see [RFC5246]
+ Section 7.4.2) that matches at least one of the TLSA records. The
+ server MAY rely on SNI to determine which certificate chain to
+
+
+
+Dukhovni & Hardaker Expires February 3, 2015 [Page 29]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ present to the client. Clients that don't send SNI information may
+ not see the expected certificate chain.
+
+ If the server's TLSA records match the server's default certificate
+ chain, the server need not support SNI. In either case, the server
+ need not include the SNI extension in its TLS HELLO as simply
+ returning a matching certificate chain is sufficient. Servers MUST
+ NOT enforce the use of SNI by clients, as the client may be using
+ unauthenticated opportunistic TLS and may not expect any particular
+ certificate from the server. If the client sends no SNI extension,
+ or sends an SNI extension for an unsupported domain, the server MUST
+ simply send some fallback certificate chain of its choice. The
+ reason for not enforcing strict matching of the requested SNI
+ hostname is that DANE TLS clients are typically willing to accept
+ multiple server names, but can only send one name in the SNI
+ extension. The server's fallback certificate may match a different
+ name acceptable to the client, e.g., the original next-hop domain.
+
+8.2. Anonymous TLS cipher suites
+
+ Since many SMTP servers either do not support or do not enable any
+ anonymous TLS cipher suites, SMTP client TLS HELLO messages SHOULD
+ offer to negotiate a typical set of non-anonymous cipher suites
+ required for interoperability with such servers. An SMTP client
+ employing pre-DANE opportunistic TLS MAY in addition include one or
+ more anonymous TLS cipher suites in its TLS HELLO. SMTP servers,
+ that need to interoperate with opportunistic TLS clients SHOULD be
+ prepared to interoperate with such clients by either always selecting
+ a mutually supported non-anonymous cipher suite or by correctly
+ handling client connections that negotiate anonymous cipher suites.
+
+ Note that while SMTP server operators are under no obligation to
+ enable anonymous cipher suites, no security is gained by sending
+ certificates to clients that will ignore them. Indeed support for
+ anonymous cipher suites in the server makes audit trails more
+ informative. Log entries that record connections that employed an
+ anonymous cipher suite record the fact that the clients did not care
+ to authenticate the server.
+
+9. Operational Considerations
+
+9.1. Client Operational Considerations
+
+ An operational error on the sending or receiving side that cannot be
+ corrected in a timely manner may, at times, lead to consistent
+ failure to deliver time-sensitive email. The sending MTA
+ administrator may have to choose between letting email queue until
+ the error is resolved and disabling opportunistic or mandatory DANE
+
+
+
+Dukhovni & Hardaker Expires February 3, 2015 [Page 30]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ TLS for one or more destinations. The choice to disable DANE TLS
+ security should not be made lightly. Every reasonable effort should
+ be made to determine that problems with mail delivery are the result
+ of an operational error, and not an attack. A fallback strategy may
+ be to configure explicit out-of-band TLS security settings if
+ supported by the sending MTA.
+
+ SMTP clients may deploy opportunistic DANE TLS incrementally by
+ enabling it only for selected sites, or may occasionally need to
+ disable opportunistic DANE TLS for peers that fail to interoperate
+ due to misconfiguration or software defects on either end. Some
+ implementations MAY support DANE TLS in an "audit only" mode in which
+ failure to achieve the requisite security level is logged as a
+ warning and delivery proceeds at a reduced security level. Unless
+ local policy specifies "audit only" or that opportunistic DANE TLS is
+ not to be used for a particular destination, an SMTP client MUST NOT
+ deliver mail via a server whose certificate chain fails to match at
+ least one TLSA record when usable TLSA records are found for that
+ server.
+
+9.2. Publisher Operational Considerations
+
+ SMTP servers that publish certificate usage DANE-TA(2) associations
+ MUST include the TA certificate in their TLS server certificate
+ chain, even when that TA certificate is a self-signed root
+ certificate.
+
+ TLSA Publishers MUST follow the digest agility guidelines in
+ Section 5 and MUST make sure that all objects published in digest
+ form for a particular usage and selector are published with the same
+ set of digest algorithms.
+
+ TLSA Publishers should follow the TLSA publication size guidance
+ found in [I-D.ietf-dane-ops] about "DANE DNS Record Size Guidelines".
+
+10. Security Considerations
+
+ This protocol leverages DANE TLSA records to implement MITM resistant
+ opportunistic security ([I-D.dukhovni-opportunistic-security]) for
+ SMTP. For destination domains that sign their MX records and publish
+ signed TLSA records for their MX hostnames, this protocol allows
+ sending MTAs to securely discover both the availability of TLS and
+ how to authenticate the destination.
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 3, 2015 [Page 31]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ This protocol does not aim to secure all SMTP traffic, as that is not
+ practical until DNSSEC and DANE adoption are universal. The
+ incremental deployment provided by following this specification is a
+ best possible path for securing SMTP. This protocol coexists and
+ interoperates with the existing insecure Internet email backbone.
+
+ The protocol does not preclude existing non-opportunistic SMTP TLS
+ security arrangements, which can continue to be used as before via
+ manual configuration with negotiated out-of-band key and TLS
+ configuration exchanges.
+
+ Opportunistic SMTP TLS depends critically on DNSSEC for downgrade
+ resistance and secure resolution of the destination name. If DNSSEC
+ is compromised, it is not possible to fall back on the public CA PKI
+ to prevent MITM attacks. A successful breach of DNSSEC enables the
+ attacker to publish TLSA usage 3 certificate associations, and
+ thereby bypass any security benefit the legitimate domain owner might
+ hope to gain by publishing usage 0 or 1 TLSA RRs. Given the lack of
+ public CA PKI support in existing MTA deployments, avoiding
+ certificate usages 0 and 1 simplifies implementation and deployment
+ with no adverse security consequences.
+
+ Implementations must strictly follow the portions of this
+ specification that indicate when it is appropriate to initiate a non-
+ authenticated connection or cleartext connection to a SMTP server.
+ Specifically, in order to prevent downgrade attacks on this protocol,
+ implementation must not initiate a connection when this specification
+ indicates a particular SMTP server must be considered unreachable.
+
+11. IANA considerations
+
+ This specification requires no support from IANA.
+
+12. Acknowledgements
+
+ The authors would like to extend great thanks to Tony Finch, who
+ started the original version of a DANE SMTP document. His work is
+ greatly appreciated and has been incorporated into this document.
+ The authors would like to additionally thank Phil Pennock for his
+ comments and advice on this document.
+
+ Acknowledgments from Viktor: Thanks to Paul Hoffman who motivated me
+ to begin work on this memo and provided feedback on early drafts.
+ Thanks to Patrick Koetter, Perry Metzger and Nico Williams for
+ valuable review comments. Thanks also to Wietse Venema who created
+ Postfix, and whose advice and feedback were essential to the
+ development of the Postfix DANE implementation.
+
+
+
+
+Dukhovni & Hardaker Expires February 3, 2015 [Page 32]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+13. References
+
+13.1. Normative References
+
+ [I-D.ietf-dane-ops]
+ Dukhovni, V. and W. Hardaker, "DANE TLSA implementation
+ and operational guidance", draft-ietf-dane-ops-00 (work in
+ progress), October 2013.
+
+ [RFC1035] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
+ Transport Layer Security", RFC 3207, February 2002.
+
+ [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "DNS Security Introduction and Requirements", RFC
+ 4033, March 2005.
+
+ [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Resource Records for the DNS Security Extensions",
+ RFC 4034, March 2005.
+
+ [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Protocol Modifications for the DNS Security
+ Extensions", RFC 4035, March 2005.
+
+ [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+ [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, May 2008.
+
+ [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
+ October 2008.
+
+ [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
+ Extension Definitions", RFC 6066, January 2011.
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 3, 2015 [Page 33]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ [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, March 2011.
+
+ [RFC6186] Daboo, C., "Use of SRV Records for Locating Email
+ Submission/Access Services", RFC 6186, March 2011.
+
+ [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
+ DNS", RFC 6672, June 2012.
+
+ [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
+ of Named Entities (DANE) Transport Layer Security (TLS)
+ Protocol: TLSA", RFC 6698, August 2012.
+
+ [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify
+ Conversations about DNS-Based Authentication of Named
+ Entities (DANE)", RFC 7218, April 2014.
+
+ [X.690] International Telecommunications Union, "Recommendation
+ ITU-T X.690 (2002) | ISO/IEC 8825-1:2002, Information
+ technology - ASN.1 encoding rules: Specification of Basic
+ Encoding Rules (BER), Canonical Encoding Rules (CER) and
+ Distinguished Encoding Rules (DER)", July 2002.
+
+13.2. Informative References
+
+ [I-D.dukhovni-opportunistic-security]
+ Dukhovni, V., "Opportunistic Security: some protection
+ most of the time", draft-dukhovni-opportunistic-
+ security-01 (work in progress), July 2014.
+
+ [I-D.ietf-dane-srv]
+ Finch, T., "Using DNS-Based Authentication of Named
+ Entities (DANE) TLSA records with SRV and MX records.",
+ draft-ietf-dane-srv-02 (work in progress), February 2013.
+
+ [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July
+ 2009.
+
+ [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",
+ STD 72, RFC 6409, November 2011.
+
+Authors' Addresses
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 3, 2015 [Page 34]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ Viktor Dukhovni
+ Two Sigma
+
+ Email: ietf-dane@dukhovni.org
+
+
+ Wes Hardaker
+ Parsons
+ P.O. Box 382
+ Davis, CA 95617
+ US
+
+ Email: ietf@hardakers.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 3, 2015 [Page 35]
--- /dev/null
+
+
+
+
+DANE V. Dukhovni
+Internet-Draft Two Sigma
+Intended status: Standards Track W. Hardaker
+Expires: February 18, 2015 Parsons
+ August 17, 2014
+
+
+ SMTP security via opportunistic DANE TLS
+ draft-ietf-dane-smtp-with-dane-12
+
+Abstract
+
+ This memo describes a downgrade-resistant protocol for SMTP transport
+ security between Mail Transfer Agents (MTAs) based on the DNS-Based
+ Authentication of Named Entities (DANE) TLSA DNS record. Adoption of
+ this protocol enables an incremental transition of the Internet email
+ backbone to one using encrypted and authenticated Transport Layer
+ Security (TLS).
+
+Status of This Memo
+
+ This Internet-Draft is submitted in full conformance with the
+ provisions of BCP 78 and BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF). Note that other groups may also distribute
+ working documents as Internet-Drafts. The list of current Internet-
+ Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ This Internet-Draft will expire on February 18, 2015.
+
+Copyright Notice
+
+ Copyright (c) 2014 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
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 1]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 5
+ 1.3. SMTP channel security . . . . . . . . . . . . . . . . . . 6
+ 1.3.1. STARTTLS downgrade attack . . . . . . . . . . . . . . 6
+ 1.3.2. Insecure server name without DNSSEC . . . . . . . . . 7
+ 1.3.3. Sender policy does not scale . . . . . . . . . . . . 8
+ 1.3.4. Too many certification authorities . . . . . . . . . 8
+ 2. Identifying applicable TLSA records . . . . . . . . . . . . . 9
+ 2.1. DNS considerations . . . . . . . . . . . . . . . . . . . 9
+ 2.1.1. DNS errors, bogus and indeterminate responses . . . . 9
+ 2.1.2. DNS error handling . . . . . . . . . . . . . . . . . 11
+ 2.1.3. Stub resolver considerations . . . . . . . . . . . . 12
+ 2.2. TLS discovery . . . . . . . . . . . . . . . . . . . . . . 13
+ 2.2.1. MX resolution . . . . . . . . . . . . . . . . . . . . 14
+ 2.2.2. Non-MX destinations . . . . . . . . . . . . . . . . . 15
+ 2.2.3. TLSA record lookup . . . . . . . . . . . . . . . . . 17
+ 3. DANE authentication . . . . . . . . . . . . . . . . . . . . . 19
+ 3.1. TLSA certificate usages . . . . . . . . . . . . . . . . . 19
+ 3.1.1. Certificate usage DANE-EE(3) . . . . . . . . . . . . 21
+ 3.1.2. Certificate usage DANE-TA(2) . . . . . . . . . . . . 22
+ 3.1.3. Certificate usages PKIX-TA(0) and PKIX-EE(1) . . . . 23
+ 3.2. Certificate matching . . . . . . . . . . . . . . . . . . 24
+ 3.2.1. DANE-EE(3) name checks . . . . . . . . . . . . . . . 24
+ 3.2.2. DANE-TA(2) name checks . . . . . . . . . . . . . . . 24
+ 3.2.3. Reference identifier matching . . . . . . . . . . . . 25
+ 4. Server key management . . . . . . . . . . . . . . . . . . . . 26
+ 5. Digest algorithm agility . . . . . . . . . . . . . . . . . . 26
+ 6. Mandatory TLS Security . . . . . . . . . . . . . . . . . . . 27
+ 7. Note on DANE for Message User Agents . . . . . . . . . . . . 27
+ 8. Interoperability considerations . . . . . . . . . . . . . . . 28
+ 8.1. SNI support . . . . . . . . . . . . . . . . . . . . . . . 28
+ 8.2. Anonymous TLS cipher suites . . . . . . . . . . . . . . . 28
+ 9. Operational Considerations . . . . . . . . . . . . . . . . . 29
+ 9.1. Client Operational Considerations . . . . . . . . . . . . 29
+ 9.2. Publisher Operational Considerations . . . . . . . . . . 30
+ 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30
+ 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 31
+ 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
+ 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
+ 13.1. Normative References . . . . . . . . . . . . . . . . . . 31
+ 13.2. Informative References . . . . . . . . . . . . . . . . . 32
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 2]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+1. Introduction
+
+ This memo specifies a new connection security model for Message
+ Transfer Agents (MTAs). This model is motivated by key features of
+ inter-domain SMTP delivery, in particular the fact that the
+ destination server is selected indirectly via DNS Mail Exchange (MX)
+ records and that neither email addresses nor MX hostnames signal a
+ requirement for either secure or cleartext transport. Therefore,
+ aside from a few manually configured exceptions, SMTP transport
+ security is of necessity opportunistic.
+
+ This specification uses the presence of DANE TLSA records to securely
+ signal TLS support and to publish the means by which SMTP clients can
+ successfully authenticate legitimate SMTP servers. This becomes
+ "opportunistic DANE TLS" and is resistant to downgrade and man-in-
+ the-middle (MITM) attacks. It enables an incremental transition of
+ the email backbone to authenticated TLS delivery, with increased
+ global protection as adoption increases.
+
+ With opportunistic DANE TLS, traffic from SMTP clients to domains
+ that publish "usable" DANE TLSA records in accordance with this memo
+ is authenticated and encrypted. Traffic from legacy clients or to
+ domains that do not publish TLSA records will continue to be sent in
+ the same manner as before, via manually configured security, (pre-
+ DANE) opportunistic TLS or just cleartext SMTP.
+
+ Problems with existing use of TLS in MTA to MTA SMTP that motivate
+ this specification are described in Section 1.3. The specification
+ itself follows in Section 2 and Section 3 which describe respectively
+ how to locate and use DANE TLSA records with SMTP. In Section 6, we
+ discuss application of DANE TLS to destinations for which channel
+ integrity and confidentiality are mandatory. In Section 7 we briefly
+ comment on potential applicability of this specification to Message
+ User Agents.
+
+1.1. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ [RFC2119].
+
+ The following terms or concepts are used through the document:
+
+ Man-in-the-middle or MITM attack: Active modification of network
+ traffic by an adversary able to thereby compromise the
+ confidentiality or integrity of the data.
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 3]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ secure, bogus, insecure, indeterminate: DNSSEC validation results,
+ as defined in Section 4.3 of [RFC4035].
+
+ Validating Security-Aware Stub Resolver and Non-Validating
+ Security-Aware Stub Resolver:
+ Capabilities of the stub resolver in use as defined in [RFC4033];
+ note that this specification requires the use of a Security-Aware
+ Stub Resolver.
+
+ (pre-DANE) opportunistic TLS: Best-effort use of TLS that is
+ generally vulnerable to DNS forgery and STARTTLS downgrade
+ attacks. When a TLS-encrypted communication channel is not
+ available, message transmission takes place in the clear. MX
+ record indirection generally precludes authentication even when
+ TLS is available.
+
+ opportunistic DANE TLS: Best-effort use of TLS, resistant to
+ downgrade attacks for destinations with DNSSEC-validated TLSA
+ records. When opportunistic DANE TLS is determined to be
+ unavailable, clients should fall back to opportunistic TLS.
+ Opportunistic DANE TLS requires support for DNSSEC, DANE and
+ STARTTLS on the client side and STARTTLS plus a DNSSEC published
+ TLSA record on the server side.
+
+ reference identifier: (Special case of [RFC6125] definition). One
+ of the domain names associated by the SMTP client with the
+ destination SMTP server for performing name checks on the server
+ certificate. When name checks are applicable, at least one of the
+ reference identifiers MUST match an [RFC6125] DNS-ID (or if none
+ are present the [RFC6125] CN-ID) of the server certificate (see
+ Section 3.2.3).
+
+ MX hostname: The RRDATA of an MX record consists of a 16 bit
+ preference followed by a Mail Exchange domain name (see [RFC1035],
+ Section 3.3.9). We will use the term "MX hostname" to refer to
+ the latter, that is, the DNS domain name found after the
+ preference value in an MX record. Thus an "MX hostname" is
+ specifically a reference to a DNS domain name, rather than any
+ host that bears that name.
+
+ delayed delivery: Email delivery is a multi-hop store & forward
+ process. When an MTA is unable forward a message that may become
+ deliverable later the message is queued and delivery is retried
+ periodically. Some MTAs may be configured with a fallback next-
+ hop destination that handles messages that the MTA would otherwise
+ queue and retry. When a fallback next-hop is configured, messages
+ that would otherwise have to be delayed may be sent to the
+ fallback next-hop destination instead. The fallback destination
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 4]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ may itself be subject to opportunistic or mandatory DANE TLS as
+ though it were the original message destination.
+
+ original next hop destination: The logical destination for mail
+ delivery. By default this is the domain portion of the recipient
+ address, but MTAs may be configured to forward mail for some or
+ all recipients via designated relays. The original next hop
+ destination is, respectively, either the recipient domain or the
+ associated configured relay.
+
+ MTA: Message Transfer Agent ([RFC5598], Section 4.3.2).
+
+ MSA: Message Submission Agent ([RFC5598], Section 4.3.1).
+
+ MUA: Message User Agent ([RFC5598], Section 4.2.1).
+
+ RR: A DNS Resource Record
+
+ RRset: A set of DNS Resource Records for a particular class, domain
+ and record type.
+
+1.2. Background
+
+ The Domain Name System Security Extensions (DNSSEC) add data origin
+ authentication, data integrity and data non-existence proofs to the
+ Domain Name System (DNS). DNSSEC is defined in [RFC4033], [RFC4034]
+ and [RFC4035].
+
+ As described in the introduction of [RFC6698], TLS authentication via
+ the existing public Certification Authority (CA) PKI suffers from an
+ over-abundance of trusted parties capable of issuing certificates for
+ any domain of their choice. DANE leverages the DNSSEC infrastructure
+ to publish trusted public keys and certificates for use with the
+ Transport Layer Security (TLS) [RFC5246] protocol via a new "TLSA"
+ DNS record type. With DNSSEC each domain can only vouch for the keys
+ of its directly delegated sub-domains.
+
+ The TLS protocol enables secure TCP communication. In the context of
+ this memo, channel security is assumed to be provided by TLS. Used
+ without authentication, TLS provides only privacy protection against
+ eavesdropping attacks. With authentication, TLS also provides data
+ integrity protection to guard against MITM attacks.
+
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 5]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+1.3. SMTP channel security
+
+ With HTTPS, Transport Layer Security (TLS) employs X.509 certificates
+ [RFC5280] issued by one of the many Certificate Authorities (CAs)
+ bundled with popular web browsers to allow users to authenticate
+ their "secure" websites. Before we specify a new DANE TLS security
+ model for SMTP, we will explain why a new security model is needed.
+ In the process, we will explain why the familiar HTTPS security model
+ is inadequate to protect inter-domain SMTP traffic.
+
+ The subsections below outline four key problems with applying
+ traditional PKI to SMTP that are addressed by this specification.
+ Since SMTP channel security policy is not explicitly specified in
+ either the recipient address or the MX record, a new signaling
+ mechanism is required to indicate when channel security is possible
+ and should be used. The publication of TLSA records allows server
+ operators to securely signal to SMTP clients that TLS is available
+ and should be used. DANE TLSA makes it possible to simultaneously
+ discover which destination domains support secure delivery via TLS
+ and how to verify the authenticity of the associated SMTP services,
+ providing a path forward to ubiquitous SMTP channel security.
+
+1.3.1. STARTTLS downgrade attack
+
+ The Simple Mail Transfer Protocol (SMTP) [RFC5321] is a single-hop
+ protocol in a multi-hop store & forward email delivery process. An
+ SMTP envelope recipient address does not correspond to a specific
+ transport-layer endpoint address, rather at each relay hop the
+ transport-layer endpoint is the next-hop relay, while the envelope
+ recipient address typically remains the same. Unlike the Hypertext
+ Transfer Protocol (HTTP) and its corresponding secured version,
+ HTTPS, where the use of TLS is signaled via the URI scheme, email
+ recipient addresses do not directly signal transport security policy.
+ Indeed, no such signaling could work well with SMTP since TLS
+ encryption of SMTP protects email traffic on a hop-by-hop basis while
+ email addresses could only express end-to-end policy.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 6]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ With no mechanism available to signal transport security policy, SMTP
+ relays employ a best-effort "opportunistic" security model for TLS.
+ A single SMTP server TCP listening endpoint can serve both TLS and
+ non-TLS clients; the use of TLS is negotiated via the SMTP STARTTLS
+ command ([RFC3207]). The server signals TLS support to the client
+ over a cleartext SMTP connection, and, if the client also supports
+ TLS, it may negotiate a TLS encrypted channel to use for email
+ transmission. The server's indication of TLS support can be easily
+ suppressed by an MITM attacker. Thus pre-DANE SMTP TLS security can
+ be subverted by simply downgrading a connection to cleartext. No TLS
+ security feature, such as the use of PKIX, can prevent this. The
+ attacker can simply disable TLS.
+
+1.3.2. Insecure server name without DNSSEC
+
+ With SMTP, DNS Mail Exchange (MX) records abstract the next-hop
+ transport endpoint and allow administrators to specify a set of
+ target servers to which SMTP traffic should be directed for a given
+ domain.
+
+ A PKIX TLS client is vulnerable to MITM attacks unless it verifies
+ that the server's certificate binds the public key to a name that
+ matches one of the client's reference identifiers. A natural choice
+ of reference identifier is the server's domain name. However, with
+ SMTP, server names are not directly encoded in the recipient address,
+ instead they are obtained indirectly via MX records. Without DNSSEC,
+ the MX lookup is vulnerable to MITM and DNS cache poisoning attacks.
+ Active attackers can forge DNS replies with fake MX records and can
+ redirect email to servers with names of their choice. Therefore,
+ secure verification of SMTP TLS certificates matching the server name
+ is not possible without DNSSEC.
+
+ One might try to harden TLS for SMTP against DNS attacks by using the
+ envelope recipient domain as a reference identifier and requiring
+ each SMTP server to possess a trusted certificate for the envelope
+ recipient domain rather than the MX hostname. Unfortunately, this is
+ impractical as email for many domains is handled by third parties
+ that are not in a position to obtain certificates for all the domains
+ they serve. Deployment of the Server Name Indication (SNI) extension
+ to TLS (see [RFC6066] Section 3) is no panacea, since SNI key
+ management is operationally challenging except when the email service
+ provider is also the domain's registrar and its certificate issuer;
+ this is rarely the case for email.
+
+ Since the recipient domain name cannot be used as the SMTP server
+ reference identifier, and neither can the MX hostname without DNSSEC,
+ large-scale deployment of authenticated TLS for SMTP requires that
+ the DNS be secure.
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 7]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ Since SMTP security depends critically on DNSSEC, it is important to
+ point out that consequently SMTP with DANE is the most conservative
+ possible trust model. It trusts only what must be trusted and no
+ more. Adding any other trusted actors to the mix can only reduce
+ SMTP security. A sender may choose to further harden DNSSEC for
+ selected high-value receiving domains by configuring explicit trust
+ anchors for those domains instead of relying on the chain of trust
+ from the root domain. However, detailed discussion of DNSSEC
+ security practices is out of scope for this document.
+
+1.3.3. Sender policy does not scale
+
+ Sending systems are in some cases explicitly configured to use TLS
+ for mail sent to selected peer domains. This requires sending MTAs
+ to be configured with appropriate subject names or certificate
+ content digests to expect in the presented server certificates.
+ Because of the heavy administrative burden, such statically
+ configured SMTP secure channels are used rarely (generally only
+ between domains that make bilateral arrangements with their business
+ partners). Internet email, on the other hand, requires regularly
+ contacting new domains for which security configurations cannot be
+ established in advance.
+
+ The abstraction of the SMTP transport endpoint via DNS MX records,
+ often across organization boundaries, limits the use of public CA PKI
+ with SMTP to a small set of sender-configured peer domains. With
+ little opportunity to use TLS authentication, sending MTAs are rarely
+ configured with a comprehensive list of trusted CAs. SMTP services
+ that support STARTTLS often deploy X.509 certificates that are self-
+ signed or issued by a private CA.
+
+1.3.4. Too many certification authorities
+
+ Even if it were generally possible to determine a secure server name,
+ the SMTP client would still need to verify that the server's
+ certificate chain is issued by a trusted Certification Authority (a
+ trust anchor). MTAs are not interactive applications where a human
+ operator can make a decision (wisely or otherwise) to selectively
+ disable TLS security policy when certificate chain verification
+ fails. With no user to "click OK", the MTA's list of public CA trust
+ anchors would need to be comprehensive in order to avoid bouncing
+ mail addressed to sites that employ unknown Certification
+ Authorities.
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 8]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ On the other hand, each trusted CA can issue certificates for any
+ domain. If even one of the configured CAs is compromised or operated
+ by an adversary, it can subvert TLS security for all destinations.
+ Any set of CAs is simultaneously both overly inclusive and not
+ inclusive enough.
+
+2. Identifying applicable TLSA records
+
+2.1. DNS considerations
+
+2.1.1. DNS errors, bogus and indeterminate responses
+
+ An SMTP client that implements opportunistic DANE TLS per this
+ specification depends critically on the integrity of DNSSEC lookups,
+ as discussed in Section 1.3.2. This section lists the DNS resolver
+ requirements needed to avoid downgrade attacks when using
+ opportunistic DANE TLS.
+
+ A DNS lookup may signal an error or return a definitive answer. A
+ security-aware resolver must be used for this specification.
+ Security-aware resolvers will indicate the security status of a DNS
+ RRset with one of four possible values defined in Section 4.3 of
+ [RFC4035]: "secure", "insecure", "bogus" and "indeterminate". In
+ [RFC4035] the meaning of the "indeterminate" security status is:
+
+ An RRset for which the resolver is not able to determine whether
+ the RRset should be signed, as the resolver is not able to obtain
+ the necessary DNSSEC RRs. This can occur when the security-aware
+ resolver is not able to contact security-aware name servers for
+ the relevant zones.
+
+ Note, the "indeterminate" security status has a conflicting
+ definition in section 5 of [RFC4033].
+
+ There is no trust anchor that would indicate that a specific
+ portion of the tree is secure.
+
+ To avoid further confusion, the adjective "anchorless" will be used
+ below to refer to domains or RRsets that are "indeterminate" in the
+ [RFC4033] sense, and the term "indeterminate" will be used
+ exclusively in the sense of [RFC4035].
+
+ SMTP clients following this specification SHOULD NOT distinguish
+ between "insecure" and "anchorless" DNS responses. Both "insecure"
+ and "anchorless" RRsets MUST be handled identically: in either case
+ unvalidated data for the query domain is all that is and can be
+ available, and authentication using the data is impossible. In what
+ follows, the term "insecure" will also include the case of
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 9]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ "anchorless" domains that lie in a portion of the DNS tree for which
+ there is no applicable trust anchor. With the DNS root zone signed,
+ we expect that validating resolvers used by Internet-facing MTAs will
+ be configured with trust anchor data for the root zone, and that
+ therefore "anchorless" domains should be rare in practice.
+
+ As noted in section 4.3 of [RFC4035], a security-aware DNS resolver
+ MUST be able to determine whether a given non-error DNS response is
+ "secure", "insecure", "bogus" or "indeterminate". It is expected
+ that most security-aware stub resolvers will not signal an
+ "indeterminate" security status (in the sense of RFC4035) to the
+ application, and will signal a "bogus" or error result instead. If a
+ resolver does signal an RFC4035 "indeterminate" security status, this
+ MUST be treated by the SMTP client as though a "bogus" or error
+ result had been returned.
+
+ An MTA making use of a non-validating security-aware stub resolver
+ MAY use the stub resolver's ability, if available, to signal DNSSEC
+ validation status based on information the stub resolver has learned
+ from an upstream validating recursive resolver. Security-Oblivious
+ stub-resolvers MUST NOT be used. In accordance with section 4.9.3 of
+ [RFC4035]:
+
+ ... a security-aware stub resolver MUST NOT place any reliance on
+ signature validation allegedly performed on its behalf, except
+ when the security-aware stub resolver obtained the data in question
+ from a trusted security-aware recursive name server via a secure
+ channel.
+
+ To avoid much repetition in the text below, we will pause to explain
+ the handling of "bogus" or "indeterminate" DNSSEC query responses.
+ These are not necessarily the result of a malicious actor; they can,
+ for example, occur when network packets are corrupted or lost in
+ transit. Therefore, "bogus" or "indeterminate" replies are equated
+ in this memo with lookup failure.
+
+ There is an important non-failure condition we need to highlight in
+ addition to the obvious case of the DNS client obtaining a non-empty
+ "secure" or "insecure" RRset of the requested type. Namely, it is
+ not an error when either "secure" or "insecure" non-existence is
+ determined for the requested data. When a DNSSEC response with a
+ validation status that is either "secure" or "insecure" reports
+ either no records of the requested type or non-existence of the query
+ domain, the response is not a DNS error condition. The DNS client
+ has not been left without an answer; it has learned that records of
+ the requested type do not exist.
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 10]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ Security-aware stub resolvers will, of course, also signal DNS lookup
+ errors in other cases, for example when processing a "ServFail"
+ RCODE, which will not have an associated DNSSEC status. All lookup
+ errors are treated the same way by this specification, regardless of
+ whether they are from a "bogus" or "indeterminate" DNSSEC status or
+ from a more generic DNS error: the information that was requested
+ cannot be obtained by the security-aware resolver at this time. A
+ lookup error is thus a failure to obtain the relevant RRset if it
+ exists, or to determine that no such RRset exists when it does not.
+
+ In contrast to a "bogus" or an "indeterminate" response, an
+ "insecure" DNSSEC response is not an error, rather it indicates that
+ the target DNS zone is either securely opted out of DNSSEC validation
+ or is not connected with the DNSSEC trust anchors being used.
+ Insecure results will leave the SMTP client with degraded channel
+ security, but do not stand in the way of message delivery. See
+ section Section 2.2 for further details.
+
+2.1.2. DNS error handling
+
+ When a DNS lookup failure (error or "bogus" or "indeterminate" as
+ defined above) prevents an SMTP client from determining which SMTP
+ server or servers it should connect to, message delivery MUST be
+ delayed. This naturally includes, for example, the case when a
+ "bogus" or "indeterminate" response is encountered during MX
+ resolution. When multiple MX hostnames are obtained from a
+ successful MX lookup, but a later DNS lookup failure prevents network
+ address resolution for a given MX hostname, delivery may proceed via
+ any remaining MX hosts.
+
+ When a particular SMTP server is securely identified as the delivery
+ destination, a set of DNS lookups (Section 2.2) MUST be performed to
+ locate any related TLSA records. If any DNS queries used to locate
+ TLSA records fail (be it due to "bogus" or "indeterminate" records,
+ timeouts, malformed replies, ServFails, etc.), then the SMTP client
+ MUST treat that server as unreachable and MUST NOT deliver the
+ message via that server. If no servers are reachable, delivery is
+ delayed.
+
+ In what follows, we will only describe what happens when all relevant
+ DNS queries succeed. If any DNS failure occurs, the SMTP client MUST
+ behave as described in this section, by skipping the problem SMTP
+ server, or the problem destination. Queries for candidate TLSA
+ records are explicitly part of "all relevant DNS queries" and SMTP
+ clients MUST NOT continue to connect to an SMTP server or destination
+ whose TLSA record lookup fails.
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 11]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+2.1.3. Stub resolver considerations
+
+ SMTP clients that employ opportunistic DANE TLS to secure connections
+ to SMTP servers MUST NOT use Security-Oblivious stub-resolvers.
+
+ A note about DNAME aliases: a query for a domain name whose ancestor
+ domain is a DNAME alias returns the DNAME RR for the ancestor domain
+ along with a CNAME that maps the query domain to the corresponding
+ sub-domain of the target domain of the DNAME alias [RFC6672].
+ Therefore, whenever we speak of CNAME aliases, we implicitly allow
+ for the possibility that the alias in question is the result of an
+ ancestor domain DNAME record. Consequently, no explicit support for
+ DNAME records is needed in SMTP software; it is sufficient to process
+ the resulting CNAME aliases. DNAME records only require special
+ processing in the validating stub-resolver library that checks the
+ integrity of the combined DNAME + CNAME reply. When DNSSEC
+ validation is handled by a local caching resolver, rather than the
+ MTA itself, even that part of the DNAME support logic is outside the
+ MTA.
+
+ When a stub resolver returns a response containing a CNAME alias that
+ does not also contain the corresponding query results for the target
+ of the alias, the SMTP client will need to repeat the query at the
+ target of the alias, and should do so recursively up to some
+ configured or implementation-dependent recursion limit. If at any
+ stage of CNAME expansion an error is detected, the lookup of the
+ original requested records MUST be considered to have failed.
+
+ Whether a chain of CNAME records was returned in a single stub
+ resolver response or via explicit recursion by the SMTP client, if at
+ any stage of recursive expansion an "insecure" CNAME record is
+ encountered, then it and all subsequent results (in particular, the
+ final result) MUST be considered "insecure" regardless of whether any
+ earlier CNAME records leading to the "insecure" record were "secure".
+
+ Note that a security-aware non-validating stub resolver may return to
+ the SMTP client an "insecure" reply received from a validating
+ recursive resolver that contains a CNAME record along with additional
+ answers recursively obtained starting at the target of the CNAME. In
+ this case, the only possible conclusion is that some record in the
+ set of records returned is "insecure", and it is in fact possible
+ that the initial CNAME record and a subset of the subsequent records
+ are "secure".
+
+ If the SMTP client needs to determine the security status of the DNS
+ zone containing the initial CNAME record, it may need to issue a
+ separate query of type "CNAME" that returns only the initial CNAME
+ record. In particular in Section 2.2.2 when insecure A or AAAA
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 12]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ records are found for an SMTP server via a CNAME alias, it may be
+ necessary to perform an additional CNAME query to determine whether
+ the DNS zone in which the alias is published is signed.
+
+2.2. TLS discovery
+
+ As noted previously (in Section 1.3.1), opportunistic TLS with SMTP
+ servers that advertise TLS support via STARTTLS is subject to an MITM
+ downgrade attack. Also some SMTP servers that are not, in fact, TLS
+ capable erroneously advertise STARTTLS by default and clients need to
+ be prepared to retry cleartext delivery after STARTTLS fails. In
+ contrast, DNSSEC validated TLSA records MUST NOT be published for
+ servers that do not support TLS. Clients can safely interpret their
+ presence as a commitment by the server operator to implement TLS and
+ STARTTLS.
+
+ This memo defines four actions to be taken after the search for a
+ TLSA record returns secure usable results, secure unusable results,
+ insecure or no results or an error signal. The term "usable" in this
+ context is in the sense of Section 4.1 of [RFC6698]. Specifically,
+ if the DNS lookup for a TLSA record returns:
+
+ A secure TLSA RRset with at least one usable record: A connection to
+ the MTA MUST be made using authenticated and encrypted TLS, using
+ the techniques discussed in the rest of this document. Failure to
+ establish an authenticated TLS connection MUST result in falling
+ back to the next SMTP server or delayed delivery.
+
+ A secure non-empty TLSA RRset where all the records are unusable: A
+ connection to the MTA MUST be made via TLS, but authentication is
+ not required. Failure to establish an encrypted TLS connection
+ MUST result in falling back to the next SMTP server or delayed
+ delivery.
+
+ An insecure TLSA RRset or DNSSEC validated proof-of-non-existent TLSA
+ records:
+ A connection to the MTA SHOULD be made using (pre-DANE)
+ opportunistic TLS, this includes using cleartext delivery when the
+ remote SMTP server does not appear to support TLS. The MTA MAY
+ retry in cleartext when delivery via TLS fails either during the
+ handshake or even during data transfer.
+
+ Any lookup error: Lookup errors, including "bogus" and
+ "indeterminate", as explained in Section 2.1.1 MUST result in
+ falling back to the next SMTP server or delayed delivery.
+
+ An SMTP client MAY be configured to require DANE verified delivery
+ for some destinations. We will call such a configuration "mandatory
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 13]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ DANE TLS". With mandatory DANE TLS, delivery proceeds only when
+ "secure" TLSA records are used to establish an encrypted and
+ authenticated TLS channel with the SMTP server.
+
+ When the original next-hop destination is an address literal, rather
+ than a DNS domain, DANE TLS does not apply. Delivery proceeds using
+ any relevant security policy configured by the MTA administrator.
+ Similarly, when an MX RRset incorrectly lists a network address in
+ lieu of an MX hostname, if an MTA chooses to connect to the network
+ address in the non-conformant MX record, DANE TLSA does not apply for
+ such a connection.
+
+ In the subsections that follow we explain how to locate the SMTP
+ servers and the associated TLSA records for a given next-hop
+ destination domain. We also explain which name or names are to be
+ used in identity checks of the SMTP server certificate.
+
+2.2.1. MX resolution
+
+ In this section we consider next-hop domains that are subject to MX
+ resolution and have MX records. The TLSA records and the associated
+ base domain are derived separately for each MX hostname that is used
+ to attempt message delivery. DANE TLS can authenticate message
+ delivery to the intended next-hop domain only when the MX records are
+ obtained securely via a DNSSEC validated lookup.
+
+ MX records MUST be sorted by preference; an MX hostname with a worse
+ (numerically higher) MX preference that has TLSA records MUST NOT
+ preempt an MX hostname with a better (numerically lower) preference
+ that has no TLSA records. In other words, prevention of delivery
+ loops by obeying MX preferences MUST take precedence over channel
+ security considerations. Even with two equal-preference MX records,
+ an MTA is not obligated to choose the MX hostname that offers more
+ security. Domains that want secure inbound mail delivery need to
+ ensure that all their SMTP servers and MX records are configured
+ accordingly.
+
+ In the language of [RFC5321] Section 5.1, the original next-hop
+ domain is the "initial name". If the MX lookup of the initial name
+ results in a CNAME alias, the MTA replaces the initial name with the
+ resulting name and performs a new lookup with the new name. MTAs
+ typically support recursion in CNAME expansion, so this replacement
+ is performed repeatedly (up to the MTA's recursion limit) until the
+ ultimate non-CNAME domain is found.
+
+ If the MX RRset (or any CNAME leading to it) is "insecure" (see
+ Section 2.1.1), DANE TLS need not apply, and delivery MAY proceed via
+ pre-DANE opportunistic TLS. That said, the protocol in this memo is
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 14]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ an "opportunistic security" protocol, meaning that it strives to
+ communicate with each peer as securely as possible, while maintaining
+ broad interoperability. Therefore, the SMTP client MAY proceed to
+ use DANE TLS (as described in Section 2.2.2 below) even with MX hosts
+ obtained via an "insecure" MX RRset. For example, when a hosting
+ provider has a signed DNS zone and publishes TLSA records for its
+ SMTP servers, hosted domains that are not signed may still benefit
+ from the provider's TLSA records. Deliveries via the provider's SMTP
+ servers will not be subject to active attacks when sending SMTP
+ clients elect to make use of the provider's TLSA records.
+
+ When the MX records are not (DNSSEC) signed, an active attacker can
+ redirect SMTP clients to MX hosts of his choice. Such redirection is
+ tamper-evident when SMTP servers found via "insecure" MX records are
+ recorded as the next-hop relay in the MTA delivery logs in their
+ original (rather than CNAME expanded) form. Sending MTAs SHOULD log
+ unexpanded MX hostnames when these result from insecure MX lookups.
+ Any successful authentication via an insecurely determined MX host
+ MUST NOT be misrepresented in the mail logs as secure delivery to the
+ intended next-hop domain. When DANE TLS is mandatory (Section 6) for
+ a given destination, delivery MUST be delayed when the MX RRset is
+ not "secure".
+
+ Otherwise, assuming no DNS errors (Section 2.1.1), the MX RRset is
+ "secure", and the SMTP client MUST treat each MX hostname as a
+ separate non-MX destination for opportunistic DANE TLS as described
+ in Section 2.2.2. When, for a given MX hostname, no TLSA records are
+ found, or only "insecure" TLSA records are found, DANE TLSA is not
+ applicable with the SMTP server in question and delivery proceeds to
+ that host as with pre-DANE opportunistic TLS. To avoid downgrade
+ attacks, any errors during TLSA lookups MUST, as explained in
+ Section 2.1.1, cause the SMTP server in question to be treated as
+ unreachable.
+
+2.2.2. Non-MX destinations
+
+ This section describes the algorithm used to locate the TLSA records
+ and associated TLSA base domain for an input domain not subject to MX
+ resolution. Such domains include:
+
+ o Each MX hostname used in a message delivery attempt for an
+ original next-hop destination domain subject to MX resolution.
+ Note, MTAs are not obligated to support CNAME expansion of MX
+ hostnames.
+
+ o Any administrator configured relay hostname, not subject to MX
+ resolution. This frequently involves configuration set by the MTA
+ administrator to handle some or all mail.
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 15]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ o A next-hop destination domain subject to MX resolution that has no
+ MX records. In this case the domain's name is implicitly also its
+ sole SMTP server name.
+
+ Note that DNS queries with type TLSA are mishandled by load balancing
+ nameservers that serve the MX hostnames of some large email
+ providers. The DNS zones served by these nameservers are not signed
+ and contain no TLSA records, but queries for TLSA records fail,
+ rather than returning the non-existence of the requested TLSA
+ records.
+
+ To avoid problems delivering mail to domains whose SMTP servers are
+ served by the problem nameservers the SMTP client MUST perform any A
+ and/or AAAA queries for the destination before attempting to locate
+ the associated TLSA records. This lookup is needed in any case to
+ determine whether the destination domain is reachable and the DNSSEC
+ validation status of the chain of CNAME queries required to reach the
+ ultimate address records.
+
+ If no address records are found, the destination is unreachable. If
+ address records are found, but the DNSSEC validation status of the
+ first query response is "insecure" (see Section 2.1.3), the SMTP
+ client SHOULD NOT proceed to search for any associated TLSA records.
+ With the problem domains, TLSA queries will lead to DNS lookup errors
+ and cause messages to be consistently delayed and ultimately returned
+ to the sender. We don't expect to find any "secure" TLSA records
+ associated with a TLSA base domain that lies in an unsigned DNS zone.
+ Therefore, skipping TLSA lookups in this case will also reduce
+ latency with no detrimental impact on security.
+
+ If the A and/or AAAA lookup of the "initial name" yields a CNAME, we
+ replace it with the resulting name as if it were the initial name and
+ perform a lookup again using the new name. This replacement is
+ performed recursively (up to the MTA's recursion limit).
+
+ We consider the following cases for handling a DNS response for an A
+ or AAAA DNS lookup:
+
+ Not found: When the DNS queries for A and/or AAAA records yield
+ neither a list of addresses nor a CNAME (or CNAME expansion is not
+ supported) the destination is unreachable.
+
+
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 16]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ Non-CNAME: The answer is not a CNAME alias. If the address RRset
+ is "secure", TLSA lookups are performed as described in
+ Section 2.2.3 with the initial name as the candidate TLSA base
+ domain. If no "secure" TLSA records are found, DANE TLS is not
+ applicable and mail delivery proceeds with pre-DANE opportunistic
+ TLS (which, being best-effort, degrades to cleartext delivery when
+ STARTTLS is not available or the TLS handshake fails).
+
+ Insecure CNAME: The input domain is a CNAME alias, but the ultimate
+ network address RRset is "insecure" (see Section 2.1.1). If the
+ initial CNAME response is also "insecure", DANE TLS does not
+ apply. Otherwise, this case is treated just like the non-CNAME
+ case above, where a search is performed for a TLSA record with the
+ original input domain as the candidate TLSA base domain.
+
+ Secure CNAME: The input domain is a CNAME alias, and the ultimate
+ network address RRset is "secure" (see Section 2.1.1). Two
+ candidate TLSA base domains are tried: the fully CNAME-expanded
+ initial name and, failing that, then the initial name itself.
+
+ In summary, if it is possible to securely obtain the full, CNAME-
+ expanded, DNSSEC-validated address records for the input domain, then
+ that name is the preferred TLSA base domain. Otherwise, the
+ unexpanded input-MX domain is the candidate TLSA base domain. When
+ no "secure" TLSA records are found at either the CNAME-expanded or
+ unexpanded domain, then DANE TLS does not apply for mail delivery via
+ the input domain in question. And, as always, errors, bogus or
+ indeterminate results for any query in the process MUST result in
+ delaying or abandoning delivery.
+
+2.2.3. TLSA record lookup
+
+ Each candidate TLSA base domain (the original or fully CNAME-expanded
+ name of a non-MX destination or a particular MX hostname of an MX
+ destination) is in turn prefixed with service labels of the form
+ "_<port>._tcp". The resulting domain name is used to issue a DNSSEC
+ query with the query type set to TLSA ([RFC6698] Section 7.1).
+
+ For SMTP, the destination TCP port is typically 25, but this may be
+ different with custom routes specified by the MTA administrator in
+ which case the SMTP client MUST use the appropriate number in the
+ "_<port>" prefix in place of "_25". If, for example, the candidate
+ base domain is "mx.example.com", and the SMTP connection is to port
+ 25, the TLSA RRset is obtained via a DNSSEC query of the form:
+
+ _25._tcp.mx.example.com. IN TLSA ?
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 17]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ The query response may be a CNAME, or the actual TLSA RRset. If the
+ response is a CNAME, the SMTP client (through the use of its
+ security-aware stub resolver) restarts the TLSA query at the target
+ domain, following CNAMEs as appropriate and keeping track of whether
+ the entire chain is "secure". If any "insecure" records are
+ encountered, or the TLSA records don't exist, the next candidate TLSA
+ base domain is tried instead.
+
+ If the ultimate response is a "secure" TLSA RRset, then the candidate
+ TLSA base domain will be the actual TLSA base domain and the TLSA
+ RRset will constitute the TLSA records for the destination. If none
+ of the candidate TLSA base domains yield "secure" TLSA records then
+ delivery MAY proceed via pre-DANE opportunistic TLS. SMTP clients
+ MAY elect to use "insecure" TLSA records to avoid STARTTLS downgrades
+ or even to skip SMTP servers that fail authentication, but MUST NOT
+ misrepresent authentication success as either a secure connection to
+ the SMTP server or as a secure delivery to the intended next-hop
+ domain.
+
+ TLSA record publishers may leverage CNAMEs to reference a single
+ authoritative TLSA RRset specifying a common Certification Authority
+ or a common end entity certificate to be used with multiple TLS
+ services. Such CNAME expansion does not change the SMTP client's
+ notion of the TLSA base domain; thus, when _25._tcp.mx.example.com is
+ a CNAME, the base domain remains mx.example.com and this is still the
+ reference identifier used together with the next-hop domain in peer
+ certificate name checks.
+
+ Note that shared end entity certificate associations expose the
+ publishing domain to substitution attacks, where an MITM attacker can
+ reroute traffic to a different server that shares the same end entity
+ certificate. Such shared end entity TLSA records SHOULD be avoided
+ unless the servers in question are functionally equivalent or employ
+ mutually incompatible protocols (an active attacker gains nothing by
+ diverting client traffic from one such server to another).
+
+ A better example, employing a shared trust anchor rather than shared
+ end-entity certificates, is illustrated by the DNSSEC validated
+ records below:
+
+ example.com. IN MX 0 mx1.example.com.
+ example.com. IN MX 0 mx2.example.com.
+ _25._tcp.mx1.example.com. IN CNAME tlsa201._dane.example.com.
+ _25._tcp.mx2.example.com. IN CNAME tlsa201._dane.example.com.
+ tlsa201._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c149a...
+
+ The SMTP servers mx1.example.com and mx2.example.com will be expected
+ to have certificates issued under a common trust anchor, but each MX
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 18]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ hostname's TLSA base domain remains unchanged despite the above CNAME
+ records. Correspondingly, each SMTP server will be associated with a
+ pair of reference identifiers consisting of its hostname plus the
+ next-hop domain "example.com".
+
+ If, during TLSA resolution (including possible CNAME indirection), at
+ least one "secure" TLSA record is found (even if not usable because
+ it is unsupported by the implementation or support is
+ administratively disabled), then the corresponding host has signaled
+ its commitment to implement TLS. The SMTP client MUST NOT deliver
+ mail via the corresponding host unless a TLS session is negotiated
+ via STARTTLS. This is required to avoid MITM STARTTLS downgrade
+ attacks.
+
+ As noted previously (in Section Section 2.2.2), when no "secure" TLSA
+ records are found at the fully CNAME-expanded name, the original
+ unexpanded name MUST be tried instead. This supports customers of
+ hosting providers where the provider's zone cannot be validated with
+ DNSSEC, but the customer has shared appropriate key material with the
+ hosting provider to enable TLS via SNI. Intermediate names that
+ arise during CNAME expansion that are neither the original, nor the
+ final name, are never candidate TLSA base domains, even if "secure".
+
+3. DANE authentication
+
+ This section describes which TLSA records are applicable to SMTP
+ opportunistic DANE TLS and how to apply such records to authenticate
+ the SMTP server. With opportunistic DANE TLS, both the TLS support
+ implied by the presence of DANE TLSA records and the verification
+ parameters necessary to authenticate the TLS peer are obtained
+ together. In contrast to protocols where channel security policy is
+ set exclusively by the client, authentication via this protocol is
+ expected to be less prone to connection failure caused by
+ incompatible configuration of the client and server.
+
+3.1. TLSA certificate usages
+
+ The DANE TLSA specification [RFC6698] defines multiple TLSA RR types
+ via combinations of 3 numeric parameters. The numeric values of
+ these parameters were later given symbolic names in [RFC7218]. The
+ rest of the TLSA record is the "certificate association data field",
+ which specifies the full or digest value of a certificate or public
+ key. The parameters are:
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 19]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ The TLSA Certificate Usage field: Section 2.1.1 of [RFC6698]
+ specifies four values: PKIX-TA(0), PKIX-EE(1), DANE-TA(2), and
+ DANE-EE(3). There is an additional private-use value:
+ PrivCert(255). All other values are reserved for use by future
+ specifications.
+
+ The selector field: Section 2.1.2 of [RFC6698] specifies two values:
+ Cert(0) and SPKI(1). There is an additional private-use value:
+ PrivSel(255). All other values are reserved for use by future
+ specifications.
+
+ The matching type field: Section 2.1.3 of [RFC6698] specifies three
+ values: Full(0), SHA2-256(1) and SHA2-512(2). There is an
+ additional private-use value: PrivMatch(255). All other values
+ are reserved for use by future specifications.
+
+ We may think of TLSA Certificate Usage values 0 through 3 as a
+ combination of two one-bit flags. The low bit chooses between trust
+ anchor (TA) and end entity (EE) certificates. The high bit chooses
+ between public PKI issued and domain-issued certificates.
+
+ The selector field specifies whether the TLSA RR matches the whole
+ certificate: Cert(0), or just its subjectPublicKeyInfo: SPKI(1). The
+ subjectPublicKeyInfo is an ASN.1 DER ([X.690]) encoding of the
+ certificate's algorithm id, any parameters and the public key data.
+
+ The matching type field specifies how the TLSA RR Certificate
+ Association Data field is to be compared with the certificate or
+ public key. A value of Full(0) means an exact match: the full DER
+ encoding of the certificate or public key is given in the TLSA RR. A
+ value of SHA2-256(1) means that the association data matches the
+ SHA2-256 digest of the certificate or public key, and likewise
+ SHA2-512(2) means a SHA2-512 digest is used.
+
+ Since opportunistic DANE TLS will be used by non-interactive MTAs,
+ with no user to "press OK" when authentication fails, reliability of
+ peer authentication is paramount. Server operators are advised to
+ publish TLSA records that are least likely to fail authentication due
+ to interoperability or operational problems. Because DANE TLS relies
+ on coordinated changes to DNS and SMTP server settings, the best
+ choice of records to publish will depend on site-specific practices.
+
+
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 20]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ The certificate usage element of a TLSA record plays a critical role
+ in determining how the corresponding certificate association data
+ field is used to authenticate server's certificate chain. The next
+ two subsections explain the process for certificate usages DANE-EE(3)
+ and DANE-TA(2). The third subsection briefly explains why
+ certificate usages PKIX-TA(0) and PKIX-EE(1) are not applicable with
+ opportunistic DANE TLS.
+
+ In summary, we recommend the use of either "DANE-EE(3) SPKI(1)
+ SHA2-256(1)" or "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA records
+ depending on site needs. Other combinations of TLSA parameters are
+ either explicitly unsupported, or offer little to recommend them over
+ these two.
+
+ The mandatory to support digest algorithm in [RFC6698] is
+ SHA2-256(1). When the server's TLSA RRset includes records with a
+ matching type indicating a digest record (i.e., a value other than
+ Full(0)), a TLSA record with a SHA2-256(1) matching type SHOULD be
+ provided along with any other digest published, since some SMTP
+ clients may support only SHA2-256(1). If at some point the SHA2-256
+ digest algorithm is tarnished by new cryptanalytic attacks,
+ publishers will need to include an appropriate stronger digest in
+ their TLSA records, initially along with, and ultimately in place of,
+ SHA2-256.
+
+3.1.1. Certificate usage DANE-EE(3)
+
+ Authentication via certificate usage DANE-EE(3) TLSA records involves
+ simply checking that the server's leaf certificate matches the TLSA
+ record. In particular the binding of the server public key to its
+ name is based entirely on the TLSA record association. The server
+ MUST be considered authenticated even if none of the names in the
+ certificate match the client's reference identity for the server.
+
+ Similarly, the expiration date of the server certificate MUST be
+ ignored, the validity period of the TLSA record key binding is
+ determined by the validity interval of the TLSA record DNSSEC
+ signature.
+
+ With DANE-EE(3) servers need not employ SNI (may ignore the client's
+ SNI message) even when the server is known under independent names
+ that would otherwise require separate certificates. It is instead
+ sufficient for the TLSA RRsets for all the domains in question to
+ match the server's default certificate. Of course with SMTP servers
+ it is simpler still to publish the same MX hostname for all the
+ hosted domains.
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 21]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ For domains where it is practical to make coordinated changes in DNS
+ TLSA records during SMTP server key rotation, it is often best to
+ publish end-entity DANE-EE(3) certificate associations. DANE-EE(3)
+ certificates don't suddenly stop working when leaf or intermediate
+ certificates expire, and don't fail when the server operator neglects
+ to configure all the required issuer certificates in the server
+ certificate chain.
+
+ TLSA records published for SMTP servers SHOULD, in most cases, be
+ "DANE-EE(3) SPKI(1) SHA2-256(1)" records. Since all DANE
+ implementations are required to support SHA2-256, this record type
+ works for all clients and need not change across certificate renewals
+ with the same key.
+
+3.1.2. Certificate usage DANE-TA(2)
+
+ Some domains may prefer to avoid the operational complexity of
+ publishing unique TLSA RRs for each TLS service. If the domain
+ employs a common issuing Certification Authority to create
+ certificates for multiple TLS services, it may be simpler to publish
+ the issuing authority as a trust anchor (TA) for the certificate
+ chains of all relevant services. The TLSA query domain (TLSA base
+ domain with port and protocol prefix labels) for each service issued
+ by the same TA may then be set to a CNAME alias that points to a
+ common TLSA RRset that matches the TA. For example:
+
+ example.com. IN MX 0 mx1.example.com.
+ example.com. IN MX 0 mx2.example.com.
+ _25._tcp.mx1.example.com. IN CNAME tlsa201._dane.example.com.
+ _25._tcp.mx2.example.com. IN CNAME tlsa201._dane.example.com.
+ tlsa201._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c14....
+
+ With usage DANE-TA(2) the server certificates will need to have names
+ that match one of the client's reference identifiers (see [RFC6125]).
+ The server MAY employ SNI to select the appropriate certificate to
+ present to the client.
+
+ SMTP servers that rely on certificate usage DANE-TA(2) TLSA records
+ for TLS authentication MUST include the TA certificate as part of the
+ certificate chain presented in the TLS handshake server certificate
+ message even when it is a self-signed root certificate. At this
+ time, many SMTP servers are not configured with a comprehensive list
+ of trust anchors, nor are they expected to at any point in the
+ future. Some MTAs will ignore all locally trusted certificates when
+ processing usage DANE-TA(2) TLSA records. Thus even when the TA
+ happens to be a public Certification Authority known to the SMTP
+ client, authentication is likely to fail unless the TA certificate is
+ included in the TLS server certificate message.
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 22]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ TLSA records with selector Full(0) are discouraged. While these
+ potentially obviate the need to transmit the TA certificate in the
+ TLS server certificate message, client implementations may not be
+ able to augment the server certificate chain with the data obtained
+ from DNS, especially when the TLSA record supplies a bare key
+ (selector SPKI(1)). Since the server will need to transmit the TA
+ certificate in any case, server operators SHOULD publish TLSA records
+ with a selector other than Full(0) and avoid potential
+ interoperability issues with large TLSA records containing full
+ certificates or keys.
+
+ TLSA Publishers employing DANE-TA(2) records SHOULD publish records
+ with a selector of Cert(0). Such TLSA records are associated with
+ the whole trust anchor certificate, not just with the trust anchor
+ public key. In particular, the SMTP client SHOULD then apply any
+ relevant constraints from the trust anchor certificate, such as, for
+ example, path length constraints.
+
+ While a selector of SPKI(1) may also be employed, the resulting TLSA
+ record will not specify the full trust anchor certificate content,
+ and elements of the trust anchor certificate other than the public
+ key become mutable. This may, for example, allow a subsidiary CA to
+ issue a chain that violates the trust anchor's path length or name
+ constraints.
+
+3.1.3. Certificate usages PKIX-TA(0) and PKIX-EE(1)
+
+ As noted in the introduction, SMTP clients cannot, without relying on
+ DNSSEC for secure MX records and DANE for STARTTLS support signaling,
+ perform server identity verification or prevent STARTTLS downgrade
+ attacks. The use of PKIX CAs offers no added security since an
+ attacker capable of compromising DNSSEC is free to replace any PKIX-
+ TA(0) or PKIX-EE(1) TLSA records with records bearing any convenient
+ non-PKIX certificate usage.
+
+ SMTP servers SHOULD NOT publish TLSA RRs with certificate usage PKIX-
+ TA(0) or PKIX-EE(1). SMTP clients cannot be expected to be
+ configured with a suitably complete set of trusted public CAs.
+ Lacking a complete set of public CAs, clients would not be able to
+ verify the certificates of SMTP servers whose issuing root CAs are
+ not trusted by the client.
+
+ Opportunistic DANE TLS needs to interoperate without bilateral
+ coordination of security settings between client and server systems.
+ Therefore, parameter choices that are fragile in the absence of
+ bilateral coordination are unsupported. Nothing is lost since the
+ PKIX certificate usages cannot aid SMTP TLS security, they can only
+ impede SMTP TLS interoperability.
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 23]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ SMTP client treatment of TLSA RRs with certificate usages PKIX-TA(0)
+ or PKIX-EE(1) is undefined. SMTP clients should generally treat such
+ TLSA records as unusable.
+
+3.2. Certificate matching
+
+ When at least one usable "secure" TLSA record is found, the SMTP
+ client MUST use TLSA records to authenticate the SMTP server.
+ Messages MUST NOT be delivered via the SMTP server if authentication
+ fails, otherwise the SMTP client is vulnerable to MITM attacks.
+
+3.2.1. DANE-EE(3) name checks
+
+ The SMTP client MUST NOT perform certificate name checks with
+ certificate usage DANE-EE(3); see Section 3.1.1 above.
+
+3.2.2. DANE-TA(2) name checks
+
+ To match a server via a TLSA record with certificate usage DANE-
+ TA(2), the client MUST perform name checks to ensure that it has
+ reached the correct server. In all DANE-TA(2) cases the SMTP client
+ MUST include the TLSA base domain as one of the valid reference
+ identifiers for matching the server certificate.
+
+ TLSA records for MX hostnames: If the TLSA base domain was obtained
+ indirectly via a "secure" MX lookup (including any CNAME-expanded
+ name of an MX hostname), then the original next-hop domain used in
+ the MX lookup MUST be included as as a second reference
+ identifier. The CNAME-expanded original next-hop domain MUST be
+ included as a third reference identifier if different from the
+ original next-hop domain. When the client MTA is employing DANE
+ TLS security despite "insecure" MX redirection the MX hostname is
+ the only reference identifier.
+
+ TLSA records for Non-MX hostnames: If MX records were not used
+ (e.g., if none exist) and the TLSA base domain is the CNAME-
+ expanded original next-hop domain, then the original next-hop
+ domain MUST be included as a second reference identifier.
+
+ Accepting certificates with the original next-hop domain in addition
+ to the MX hostname allows a domain with multiple MX hostnames to
+ field a single certificate bearing a single domain name (i.e., the
+ email domain) across all the SMTP servers. This also aids
+ interoperability with pre-DANE SMTP clients that are configured to
+ look for the email domain name in server certificates. For example,
+ with "secure" DNS records as below:
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 24]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ exchange.example.org. IN CNAME mail.example.org.
+ mail.example.org. IN CNAME example.com.
+ example.com. IN MX 10 mx10.example.com.
+ example.com. IN MX 15 mx15.example.com.
+ example.com. IN MX 20 mx20.example.com.
+ ;
+ mx10.example.com. IN A 192.0.2.10
+ _25._tcp.mx10.example.com. IN TLSA 2 0 1 ...
+ ;
+ mx15.example.com. IN CNAME mxbackup.example.com.
+ mxbackup.example.com. IN A 192.0.2.15
+ ; _25._tcp.mxbackup.example.com. IN TLSA ? (NXDOMAIN)
+ _25._tcp.mx15.example.com. IN TLSA 2 0 1 ...
+ ;
+ mx20.example.com. IN CNAME mxbackup.example.net.
+ mxbackup.example.net. IN A 198.51.100.20
+ _25._tcp.mxbackup.example.net. IN TLSA 2 0 1 ...
+
+ Certificate name checks for delivery of mail to exchange.example.org
+ via any of the associated SMTP servers MUST accept at least the names
+ "exchange.example.org" and "example.com", which are respectively the
+ original and fully expanded next-hop domain. When the SMTP server is
+ mx10.example.com, name checks MUST accept the TLSA base domain
+ "mx10.example.com". If, despite the fact that MX hostnames are
+ required to not be aliases, the MTA supports delivery via
+ "mx15.example.com" or "mx20.example.com" then name checks MUST accept
+ the respective TLSA base domains "mx15.example.com" and
+ "mxbackup.example.net".
+
+3.2.3. Reference identifier matching
+
+ When name checks are applicable (certificate usage DANE-TA(2)), if
+ the server certificate contains a Subject Alternative Name extension
+ ([RFC5280]), with at least one DNS-ID ([RFC6125]) then only the DNS-
+ IDs are matched against the client's reference identifiers. The CN-
+ ID ([RFC6125]) is only considered when no DNS-IDs are present. The
+ server certificate is considered matched when one of its presented
+ identifiers ([RFC5280]) matches any of the client's reference
+ identifiers.
+
+ Wildcards are valid in either DNS-IDs or the CN-ID when applicable.
+ The wildcard character must be entire first label of the DNS-ID or
+ CN-ID. Thus, "*.example.com" is valid, while "smtp*.example.com" and
+ "*smtp.example.com" are not. SMTP clients MUST support wildcards
+ that match the first label of the reference identifier, with the
+ remaining labels matching verbatim. For example, the DNS-ID
+ "*.example.com" matches the reference identifier "mx1.example.com".
+ SMTP clients MAY, subject to local policy allow wildcards to match
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 25]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ multiple reference identifier labels, but servers cannot expect broad
+ support for such a policy. Therefore any wildcards in server
+ certificates SHOULD match exactly one label in either the TLSA base
+ domain or the next-hop domain.
+
+4. Server key management
+
+ Two TLSA records MUST be published before employing a new EE or TA
+ public key or certificate, one matching the currently deployed key
+ and the other matching the new key scheduled to replace it. Once
+ sufficient time has elapsed for all DNS caches to expire the previous
+ TLSA RRset and related signature RRsets, servers may be configured to
+ use the new EE private key and associated public key certificate or
+ may employ certificates signed by the new trust anchor.
+
+ Once the new public key or certificate is in use, the TLSA RR that
+ matches the retired key can be removed from DNS, leaving only RRs
+ that match keys or certificates in active use.
+
+ As described in Section 3.1.2, when server certificates are validated
+ via a DANE-TA(2) trust anchor, and CNAME records are employed to
+ store the TA association data at a single location, the
+ responsibility of updating the TLSA RRset shifts to the operator of
+ the trust anchor. Before a new trust anchor is used to sign any new
+ server certificates, its certificate (digest) is added to the
+ relevant TLSA RRset. After enough time elapses for the original TLSA
+ RRset to age out of DNS caches, the new trust anchor can start
+ issuing new server certificates. Once all certificates issued under
+ the previous trust anchor have expired, its associated RRs can be
+ removed from the TLSA RRset.
+
+ In the DANE-TA(2) key management model server operators do not
+ generally need to update DNS TLSA records after initially creating a
+ CNAME record that references the centrally operated DANE-TA(2) RRset.
+ If a particular server's key is compromised, its TLSA CNAME SHOULD be
+ replaced with a DANE-EE(3) association until the certificate for the
+ compromised key expires, at which point it can return to using a
+ CNAME record. If the central trust anchor is compromised, all
+ servers need to be issued new keys by a new TA, and an updated DANE-
+ TA(2) TLSA RRset needs to be published containing just the new TA.
+
+ SMTP servers cannot expect broad CRL or OCSP support from SMTP
+ clients. As outlined above, with DANE, compromised server or trust
+ anchor keys can be "revoked" by removing them from the DNS without
+ the need for client-side support for OCSP or CRLs.
+
+5. Digest algorithm agility
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 26]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ While [RFC6698] specifies multiple digest algorithms, it does not
+ specify a protocol by which the SMTP client and TLSA record publisher
+ can agree on the strongest shared algorithm. Such a protocol would
+ allow the client and server to avoid exposure to any deprecated
+ weaker algorithms that are published for compatibility with less
+ capable clients, but should be ignored when possible. Such a
+ protocol is specified in [I-D.ietf-dane-ops]. SMTP clients and
+ servers that implement this specification MUST comply with the
+ requirements outlined under "Digest Algorithm Agility" in
+ [I-D.ietf-dane-ops].
+
+6. Mandatory TLS Security
+
+ An MTA implementing this protocol may require a stronger security
+ assurance when sending email to selected destinations. The sending
+ organization may need to send sensitive email and/or may have
+ regulatory obligations to protect its content. This protocol is not
+ in conflict with such a requirement, and in fact can often simplify
+ authenticated delivery to such destinations.
+
+ Specifically, with domains that publish DANE TLSA records for their
+ MX hostnames, a sending MTA can be configured to use the receiving
+ domains's DANE TLSA records to authenticate the corresponding SMTP
+ server. Authentication via DANE TLSA records is easier to manage, as
+ changes in the receiver's expected certificate properties are made on
+ the receiver end and don't require manually communicated
+ configuration changes. With mandatory DANE TLS, when no usable TLSA
+ records are found, message delivery is delayed. Thus, mail is only
+ sent when an authenticated TLS channel is established to the remote
+ SMTP server.
+
+ Administrators of mail servers that employ mandatory DANE TLS, need
+ to carefully monitor their mail logs and queues. If a partner domain
+ unwittingly misconfigures their TLSA records, disables DNSSEC, or
+ misconfigures SMTP server certificate chains, mail will be delayed
+ and may bounce if the issue is not resolved in a timely manner.
+
+7. Note on DANE for Message User Agents
+
+ We note that the SMTP protocol is also used between Message User
+ Agents (MUAs) and Message Submission Agents (MSAs) [RFC6409]. In
+ [RFC6186] a protocol is specified that enables an MUA to dynamically
+ locate the MSA based on the user's email address. SMTP connection
+ security considerations for MUAs implementing [RFC6186] are largely
+ analogous to connection security requirements for MTAs, and this
+ specification could be applied largely verbatim with DNS MX records
+ replaced by corresponding DNS Service (SRV) records
+ [I-D.ietf-dane-srv].
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 27]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ However, until MUAs begin to adopt the dynamic configuration
+ mechanisms of [RFC6186] they are adequately served by more
+ traditional static TLS security policies. Specification of DANE TLS
+ for Message User Agent (MUA) to Message Submission Agent (MSA) SMTP
+ is left to future documents that focus specifically on SMTP security
+ between MUAs and MSAs.
+
+8. Interoperability considerations
+
+8.1. SNI support
+
+ To ensure that the server sends the right certificate chain, the SMTP
+ client MUST send the TLS SNI extension containing the TLSA base
+ domain. This precludes the use of the backward compatible SSL 2.0
+ compatible SSL HELLO by the SMTP client. The minimum SSL/TLS client
+ HELLO version for SMTP clients performing DANE authentication is SSL
+ 3.0, but a client that offers SSL 3.0 MUST also offer at least TLS
+ 1.0 and MUST include the SNI extension. Servers that don't make use
+ of SNI MAY negotiate SSL 3.0 if offered by the client.
+
+ Each SMTP server MUST present a certificate chain (see [RFC5246]
+ Section 7.4.2) that matches at least one of the TLSA records. The
+ server MAY rely on SNI to determine which certificate chain to
+ present to the client. Clients that don't send SNI information may
+ not see the expected certificate chain.
+
+ If the server's TLSA records match the server's default certificate
+ chain, the server need not support SNI. In either case, the server
+ need not include the SNI extension in its TLS HELLO as simply
+ returning a matching certificate chain is sufficient. Servers MUST
+ NOT enforce the use of SNI by clients, as the client may be using
+ unauthenticated opportunistic TLS and may not expect any particular
+ certificate from the server. If the client sends no SNI extension,
+ or sends an SNI extension for an unsupported domain, the server MUST
+ simply send some fallback certificate chain of its choice. The
+ reason for not enforcing strict matching of the requested SNI
+ hostname is that DANE TLS clients are typically willing to accept
+ multiple server names, but can only send one name in the SNI
+ extension. The server's fallback certificate may match a different
+ name acceptable to the client, e.g., the original next-hop domain.
+
+8.2. Anonymous TLS cipher suites
+
+ Since many SMTP servers either do not support or do not enable any
+ anonymous TLS cipher suites, SMTP client TLS HELLO messages SHOULD
+ offer to negotiate a typical set of non-anonymous cipher suites
+ required for interoperability with such servers. An SMTP client
+ employing pre-DANE opportunistic TLS MAY in addition include one or
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 28]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ more anonymous TLS cipher suites in its TLS HELLO. SMTP servers,
+ that need to interoperate with opportunistic TLS clients SHOULD be
+ prepared to interoperate with such clients by either always selecting
+ a mutually supported non-anonymous cipher suite or by correctly
+ handling client connections that negotiate anonymous cipher suites.
+
+ Note that while SMTP server operators are under no obligation to
+ enable anonymous cipher suites, no security is gained by sending
+ certificates to clients that will ignore them. Indeed support for
+ anonymous cipher suites in the server makes audit trails more
+ informative. Log entries that record connections that employed an
+ anonymous cipher suite record the fact that the clients did not care
+ to authenticate the server.
+
+9. Operational Considerations
+
+9.1. Client Operational Considerations
+
+ An operational error on the sending or receiving side that cannot be
+ corrected in a timely manner may, at times, lead to consistent
+ failure to deliver time-sensitive email. The sending MTA
+ administrator may have to choose between letting email queue until
+ the error is resolved and disabling opportunistic or mandatory DANE
+ TLS for one or more destinations. The choice to disable DANE TLS
+ security should not be made lightly. Every reasonable effort should
+ be made to determine that problems with mail delivery are the result
+ of an operational error, and not an attack. A fallback strategy may
+ be to configure explicit out-of-band TLS security settings if
+ supported by the sending MTA.
+
+ SMTP clients may deploy opportunistic DANE TLS incrementally by
+ enabling it only for selected sites, or may occasionally need to
+ disable opportunistic DANE TLS for peers that fail to interoperate
+ due to misconfiguration or software defects on either end. Some
+ implementations MAY support DANE TLS in an "audit only" mode in which
+ failure to achieve the requisite security level is logged as a
+ warning and delivery proceeds at a reduced security level. Unless
+ local policy specifies "audit only" or that opportunistic DANE TLS is
+ not to be used for a particular destination, an SMTP client MUST NOT
+ deliver mail via a server whose certificate chain fails to match at
+ least one TLSA record when usable TLSA records are found for that
+ server.
+
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 29]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+9.2. Publisher Operational Considerations
+
+ SMTP servers that publish certificate usage DANE-TA(2) associations
+ MUST include the TA certificate in their TLS server certificate
+ chain, even when that TA certificate is a self-signed root
+ certificate.
+
+ TLSA Publishers MUST follow the guidelines in the "TLSA Publisher
+ Requirements" section of [I-D.ietf-dane-ops].
+
+ TLSA Publishers SHOULD follow the TLSA publication size guidance
+ found in [I-D.ietf-dane-ops] under "DANE DNS Record Size Guidelines".
+
+10. Security Considerations
+
+ This protocol leverages DANE TLSA records to implement MITM resistant
+ opportunistic security ([I-D.dukhovni-opportunistic-security]) for
+ SMTP. For destination domains that sign their MX records and publish
+ signed TLSA records for their MX hostnames, this protocol allows
+ sending MTAs to securely discover both the availability of TLS and
+ how to authenticate the destination.
+
+ This protocol does not aim to secure all SMTP traffic, as that is not
+ practical until DNSSEC and DANE adoption are universal. The
+ incremental deployment provided by following this specification is a
+ best possible path for securing SMTP. This protocol coexists and
+ interoperates with the existing insecure Internet email backbone.
+
+ The protocol does not preclude existing non-opportunistic SMTP TLS
+ security arrangements, which can continue to be used as before via
+ manual configuration with negotiated out-of-band key and TLS
+ configuration exchanges.
+
+ Opportunistic SMTP TLS depends critically on DNSSEC for downgrade
+ resistance and secure resolution of the destination name. If DNSSEC
+ is compromised, it is not possible to fall back on the public CA PKI
+ to prevent MITM attacks. A successful breach of DNSSEC enables the
+ attacker to publish TLSA usage 3 certificate associations, and
+ thereby bypass any security benefit the legitimate domain owner might
+ hope to gain by publishing usage 0 or 1 TLSA RRs. Given the lack of
+ public CA PKI support in existing MTA deployments, avoiding
+ certificate usages 0 and 1 simplifies implementation and deployment
+ with no adverse security consequences.
+
+ Implementations must strictly follow the portions of this
+ specification that indicate when it is appropriate to initiate a non-
+ authenticated connection or cleartext connection to a SMTP server.
+ Specifically, in order to prevent downgrade attacks on this protocol,
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 30]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ implementation must not initiate a connection when this specification
+ indicates a particular SMTP server must be considered unreachable.
+
+11. IANA considerations
+
+ This specification requires no support from IANA.
+
+12. Acknowledgements
+
+ The authors would like to extend great thanks to Tony Finch, who
+ started the original version of a DANE SMTP document. His work is
+ greatly appreciated and has been incorporated into this document.
+ The authors would like to additionally thank Phil Pennock for his
+ comments and advice on this document.
+
+ Acknowledgments from Viktor: Thanks to Paul Hoffman who motivated me
+ to begin work on this memo and provided feedback on early drafts.
+ Thanks to Patrick Koetter, Perry Metzger and Nico Williams for
+ valuable review comments. Thanks also to Wietse Venema who created
+ Postfix, and whose advice and feedback were essential to the
+ development of the Postfix DANE implementation.
+
+13. References
+
+13.1. Normative References
+
+ [I-D.ietf-dane-ops]
+ Dukhovni, V. and W. Hardaker, "Updates to and Operational
+ Guidance for the DANE Protocol", draft-ietf-dane-ops-06
+ (work in progress), August 2014.
+
+ [RFC1035] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
+ Transport Layer Security", RFC 3207, February 2002.
+
+ [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "DNS Security Introduction and Requirements", RFC
+ 4033, March 2005.
+
+ [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Resource Records for the DNS Security Extensions",
+ RFC 4034, March 2005.
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 31]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Protocol Modifications for the DNS Security
+ Extensions", RFC 4035, March 2005.
+
+ [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+ [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, May 2008.
+
+ [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
+ October 2008.
+
+ [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
+ Extension Definitions", RFC 6066, January 2011.
+
+ [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, March 2011.
+
+ [RFC6186] Daboo, C., "Use of SRV Records for Locating Email
+ Submission/Access Services", RFC 6186, March 2011.
+
+ [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
+ DNS", RFC 6672, June 2012.
+
+ [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
+ of Named Entities (DANE) Transport Layer Security (TLS)
+ Protocol: TLSA", RFC 6698, August 2012.
+
+ [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify
+ Conversations about DNS-Based Authentication of Named
+ Entities (DANE)", RFC 7218, April 2014.
+
+ [X.690] International Telecommunications Union, "Recommendation
+ ITU-T X.690 (2002) | ISO/IEC 8825-1:2002, Information
+ technology - ASN.1 encoding rules: Specification of Basic
+ Encoding Rules (BER), Canonical Encoding Rules (CER) and
+ Distinguished Encoding Rules (DER)", July 2002.
+
+13.2. Informative References
+
+ [I-D.dukhovni-opportunistic-security]
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 32]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ Dukhovni, V., "Opportunistic Security: Some Protection
+ Most of the Time", draft-dukhovni-opportunistic-
+ security-03 (work in progress), August 2014.
+
+ [I-D.ietf-dane-srv]
+ Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-
+ Based Authentication of Named Entities (DANE) TLSA Records
+ with SRV Records", draft-ietf-dane-srv-07 (work in
+ progress), July 2014.
+
+ [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July
+ 2009.
+
+ [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",
+ STD 72, RFC 6409, November 2011.
+
+Authors' Addresses
+
+ Viktor Dukhovni
+ Two Sigma
+
+ Email: ietf-dane@dukhovni.org
+
+
+ Wes Hardaker
+ Parsons
+ P.O. Box 382
+ Davis, CA 95617
+ US
+
+ Email: ietf@hardakers.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 33]
--- /dev/null
+
+
+
+
+DANE V. Dukhovni
+Internet-Draft Two Sigma
+Intended status: Standards Track W. Hardaker
+Expires: February 18, 2015 Parsons
+ August 17, 2014
+
+
+ SMTP security via opportunistic DANE TLS
+ draft-ietf-dane-smtp-with-dane-12
+
+Abstract
+
+ This memo describes a downgrade-resistant protocol for SMTP transport
+ security between Mail Transfer Agents (MTAs) based on the DNS-Based
+ Authentication of Named Entities (DANE) TLSA DNS record. Adoption of
+ this protocol enables an incremental transition of the Internet email
+ backbone to one using encrypted and authenticated Transport Layer
+ Security (TLS).
+
+Status of This Memo
+
+ This Internet-Draft is submitted in full conformance with the
+ provisions of BCP 78 and BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF). Note that other groups may also distribute
+ working documents as Internet-Drafts. The list of current Internet-
+ Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ This Internet-Draft will expire on February 18, 2015.
+
+Copyright Notice
+
+ Copyright (c) 2014 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
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 1]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 5
+ 1.3. SMTP channel security . . . . . . . . . . . . . . . . . . 6
+ 1.3.1. STARTTLS downgrade attack . . . . . . . . . . . . . . 6
+ 1.3.2. Insecure server name without DNSSEC . . . . . . . . . 7
+ 1.3.3. Sender policy does not scale . . . . . . . . . . . . 8
+ 1.3.4. Too many certification authorities . . . . . . . . . 8
+ 2. Identifying applicable TLSA records . . . . . . . . . . . . . 9
+ 2.1. DNS considerations . . . . . . . . . . . . . . . . . . . 9
+ 2.1.1. DNS errors, bogus and indeterminate responses . . . . 9
+ 2.1.2. DNS error handling . . . . . . . . . . . . . . . . . 11
+ 2.1.3. Stub resolver considerations . . . . . . . . . . . . 12
+ 2.2. TLS discovery . . . . . . . . . . . . . . . . . . . . . . 13
+ 2.2.1. MX resolution . . . . . . . . . . . . . . . . . . . . 14
+ 2.2.2. Non-MX destinations . . . . . . . . . . . . . . . . . 15
+ 2.2.3. TLSA record lookup . . . . . . . . . . . . . . . . . 17
+ 3. DANE authentication . . . . . . . . . . . . . . . . . . . . . 19
+ 3.1. TLSA certificate usages . . . . . . . . . . . . . . . . . 19
+ 3.1.1. Certificate usage DANE-EE(3) . . . . . . . . . . . . 21
+ 3.1.2. Certificate usage DANE-TA(2) . . . . . . . . . . . . 22
+ 3.1.3. Certificate usages PKIX-TA(0) and PKIX-EE(1) . . . . 23
+ 3.2. Certificate matching . . . . . . . . . . . . . . . . . . 24
+ 3.2.1. DANE-EE(3) name checks . . . . . . . . . . . . . . . 24
+ 3.2.2. DANE-TA(2) name checks . . . . . . . . . . . . . . . 24
+ 3.2.3. Reference identifier matching . . . . . . . . . . . . 25
+ 4. Server key management . . . . . . . . . . . . . . . . . . . . 26
+ 5. Digest algorithm agility . . . . . . . . . . . . . . . . . . 26
+ 6. Mandatory TLS Security . . . . . . . . . . . . . . . . . . . 27
+ 7. Note on DANE for Message User Agents . . . . . . . . . . . . 27
+ 8. Interoperability considerations . . . . . . . . . . . . . . . 28
+ 8.1. SNI support . . . . . . . . . . . . . . . . . . . . . . . 28
+ 8.2. Anonymous TLS cipher suites . . . . . . . . . . . . . . . 28
+ 9. Operational Considerations . . . . . . . . . . . . . . . . . 29
+ 9.1. Client Operational Considerations . . . . . . . . . . . . 29
+ 9.2. Publisher Operational Considerations . . . . . . . . . . 30
+ 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30
+ 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 31
+ 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
+ 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
+ 13.1. Normative References . . . . . . . . . . . . . . . . . . 31
+ 13.2. Informative References . . . . . . . . . . . . . . . . . 32
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 2]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+1. Introduction
+
+ This memo specifies a new connection security model for Message
+ Transfer Agents (MTAs). This model is motivated by key features of
+ inter-domain SMTP delivery, in particular the fact that the
+ destination server is selected indirectly via DNS Mail Exchange (MX)
+ records and that neither email addresses nor MX hostnames signal a
+ requirement for either secure or cleartext transport. Therefore,
+ aside from a few manually configured exceptions, SMTP transport
+ security is of necessity opportunistic.
+
+ This specification uses the presence of DANE TLSA records to securely
+ signal TLS support and to publish the means by which SMTP clients can
+ successfully authenticate legitimate SMTP servers. This becomes
+ "opportunistic DANE TLS" and is resistant to downgrade and man-in-
+ the-middle (MITM) attacks. It enables an incremental transition of
+ the email backbone to authenticated TLS delivery, with increased
+ global protection as adoption increases.
+
+ With opportunistic DANE TLS, traffic from SMTP clients to domains
+ that publish "usable" DANE TLSA records in accordance with this memo
+ is authenticated and encrypted. Traffic from legacy clients or to
+ domains that do not publish TLSA records will continue to be sent in
+ the same manner as before, via manually configured security, (pre-
+ DANE) opportunistic TLS or just cleartext SMTP.
+
+ Problems with existing use of TLS in MTA to MTA SMTP that motivate
+ this specification are described in Section 1.3. The specification
+ itself follows in Section 2 and Section 3 which describe respectively
+ how to locate and use DANE TLSA records with SMTP. In Section 6, we
+ discuss application of DANE TLS to destinations for which channel
+ integrity and confidentiality are mandatory. In Section 7 we briefly
+ comment on potential applicability of this specification to Message
+ User Agents.
+
+1.1. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ [RFC2119].
+
+ The following terms or concepts are used through the document:
+
+ Man-in-the-middle or MITM attack: Active modification of network
+ traffic by an adversary able to thereby compromise the
+ confidentiality or integrity of the data.
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 3]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ secure, bogus, insecure, indeterminate: DNSSEC validation results,
+ as defined in Section 4.3 of [RFC4035].
+
+ Validating Security-Aware Stub Resolver and Non-Validating
+ Security-Aware Stub Resolver:
+ Capabilities of the stub resolver in use as defined in [RFC4033];
+ note that this specification requires the use of a Security-Aware
+ Stub Resolver.
+
+ (pre-DANE) opportunistic TLS: Best-effort use of TLS that is
+ generally vulnerable to DNS forgery and STARTTLS downgrade
+ attacks. When a TLS-encrypted communication channel is not
+ available, message transmission takes place in the clear. MX
+ record indirection generally precludes authentication even when
+ TLS is available.
+
+ opportunistic DANE TLS: Best-effort use of TLS, resistant to
+ downgrade attacks for destinations with DNSSEC-validated TLSA
+ records. When opportunistic DANE TLS is determined to be
+ unavailable, clients should fall back to opportunistic TLS.
+ Opportunistic DANE TLS requires support for DNSSEC, DANE and
+ STARTTLS on the client side and STARTTLS plus a DNSSEC published
+ TLSA record on the server side.
+
+ reference identifier: (Special case of [RFC6125] definition). One
+ of the domain names associated by the SMTP client with the
+ destination SMTP server for performing name checks on the server
+ certificate. When name checks are applicable, at least one of the
+ reference identifiers MUST match an [RFC6125] DNS-ID (or if none
+ are present the [RFC6125] CN-ID) of the server certificate (see
+ Section 3.2.3).
+
+ MX hostname: The RRDATA of an MX record consists of a 16 bit
+ preference followed by a Mail Exchange domain name (see [RFC1035],
+ Section 3.3.9). We will use the term "MX hostname" to refer to
+ the latter, that is, the DNS domain name found after the
+ preference value in an MX record. Thus an "MX hostname" is
+ specifically a reference to a DNS domain name, rather than any
+ host that bears that name.
+
+ delayed delivery: Email delivery is a multi-hop store & forward
+ process. When an MTA is unable forward a message that may become
+ deliverable later the message is queued and delivery is retried
+ periodically. Some MTAs may be configured with a fallback next-
+ hop destination that handles messages that the MTA would otherwise
+ queue and retry. When a fallback next-hop is configured, messages
+ that would otherwise have to be delayed may be sent to the
+ fallback next-hop destination instead. The fallback destination
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 4]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ may itself be subject to opportunistic or mandatory DANE TLS as
+ though it were the original message destination.
+
+ original next hop destination: The logical destination for mail
+ delivery. By default this is the domain portion of the recipient
+ address, but MTAs may be configured to forward mail for some or
+ all recipients via designated relays. The original next hop
+ destination is, respectively, either the recipient domain or the
+ associated configured relay.
+
+ MTA: Message Transfer Agent ([RFC5598], Section 4.3.2).
+
+ MSA: Message Submission Agent ([RFC5598], Section 4.3.1).
+
+ MUA: Message User Agent ([RFC5598], Section 4.2.1).
+
+ RR: A DNS Resource Record
+
+ RRset: A set of DNS Resource Records for a particular class, domain
+ and record type.
+
+1.2. Background
+
+ The Domain Name System Security Extensions (DNSSEC) add data origin
+ authentication, data integrity and data non-existence proofs to the
+ Domain Name System (DNS). DNSSEC is defined in [RFC4033], [RFC4034]
+ and [RFC4035].
+
+ As described in the introduction of [RFC6698], TLS authentication via
+ the existing public Certification Authority (CA) PKI suffers from an
+ over-abundance of trusted parties capable of issuing certificates for
+ any domain of their choice. DANE leverages the DNSSEC infrastructure
+ to publish trusted public keys and certificates for use with the
+ Transport Layer Security (TLS) [RFC5246] protocol via a new "TLSA"
+ DNS record type. With DNSSEC each domain can only vouch for the keys
+ of its directly delegated sub-domains.
+
+ The TLS protocol enables secure TCP communication. In the context of
+ this memo, channel security is assumed to be provided by TLS. Used
+ without authentication, TLS provides only privacy protection against
+ eavesdropping attacks. With authentication, TLS also provides data
+ integrity protection to guard against MITM attacks.
+
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 5]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+1.3. SMTP channel security
+
+ With HTTPS, Transport Layer Security (TLS) employs X.509 certificates
+ [RFC5280] issued by one of the many Certificate Authorities (CAs)
+ bundled with popular web browsers to allow users to authenticate
+ their "secure" websites. Before we specify a new DANE TLS security
+ model for SMTP, we will explain why a new security model is needed.
+ In the process, we will explain why the familiar HTTPS security model
+ is inadequate to protect inter-domain SMTP traffic.
+
+ The subsections below outline four key problems with applying
+ traditional PKI to SMTP that are addressed by this specification.
+ Since SMTP channel security policy is not explicitly specified in
+ either the recipient address or the MX record, a new signaling
+ mechanism is required to indicate when channel security is possible
+ and should be used. The publication of TLSA records allows server
+ operators to securely signal to SMTP clients that TLS is available
+ and should be used. DANE TLSA makes it possible to simultaneously
+ discover which destination domains support secure delivery via TLS
+ and how to verify the authenticity of the associated SMTP services,
+ providing a path forward to ubiquitous SMTP channel security.
+
+1.3.1. STARTTLS downgrade attack
+
+ The Simple Mail Transfer Protocol (SMTP) [RFC5321] is a single-hop
+ protocol in a multi-hop store & forward email delivery process. An
+ SMTP envelope recipient address does not correspond to a specific
+ transport-layer endpoint address, rather at each relay hop the
+ transport-layer endpoint is the next-hop relay, while the envelope
+ recipient address typically remains the same. Unlike the Hypertext
+ Transfer Protocol (HTTP) and its corresponding secured version,
+ HTTPS, where the use of TLS is signaled via the URI scheme, email
+ recipient addresses do not directly signal transport security policy.
+ Indeed, no such signaling could work well with SMTP since TLS
+ encryption of SMTP protects email traffic on a hop-by-hop basis while
+ email addresses could only express end-to-end policy.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 6]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ With no mechanism available to signal transport security policy, SMTP
+ relays employ a best-effort "opportunistic" security model for TLS.
+ A single SMTP server TCP listening endpoint can serve both TLS and
+ non-TLS clients; the use of TLS is negotiated via the SMTP STARTTLS
+ command ([RFC3207]). The server signals TLS support to the client
+ over a cleartext SMTP connection, and, if the client also supports
+ TLS, it may negotiate a TLS encrypted channel to use for email
+ transmission. The server's indication of TLS support can be easily
+ suppressed by an MITM attacker. Thus pre-DANE SMTP TLS security can
+ be subverted by simply downgrading a connection to cleartext. No TLS
+ security feature, such as the use of PKIX, can prevent this. The
+ attacker can simply disable TLS.
+
+1.3.2. Insecure server name without DNSSEC
+
+ With SMTP, DNS Mail Exchange (MX) records abstract the next-hop
+ transport endpoint and allow administrators to specify a set of
+ target servers to which SMTP traffic should be directed for a given
+ domain.
+
+ A PKIX TLS client is vulnerable to MITM attacks unless it verifies
+ that the server's certificate binds the public key to a name that
+ matches one of the client's reference identifiers. A natural choice
+ of reference identifier is the server's domain name. However, with
+ SMTP, server names are not directly encoded in the recipient address,
+ instead they are obtained indirectly via MX records. Without DNSSEC,
+ the MX lookup is vulnerable to MITM and DNS cache poisoning attacks.
+ Active attackers can forge DNS replies with fake MX records and can
+ redirect email to servers with names of their choice. Therefore,
+ secure verification of SMTP TLS certificates matching the server name
+ is not possible without DNSSEC.
+
+ One might try to harden TLS for SMTP against DNS attacks by using the
+ envelope recipient domain as a reference identifier and requiring
+ each SMTP server to possess a trusted certificate for the envelope
+ recipient domain rather than the MX hostname. Unfortunately, this is
+ impractical as email for many domains is handled by third parties
+ that are not in a position to obtain certificates for all the domains
+ they serve. Deployment of the Server Name Indication (SNI) extension
+ to TLS (see [RFC6066] Section 3) is no panacea, since SNI key
+ management is operationally challenging except when the email service
+ provider is also the domain's registrar and its certificate issuer;
+ this is rarely the case for email.
+
+ Since the recipient domain name cannot be used as the SMTP server
+ reference identifier, and neither can the MX hostname without DNSSEC,
+ large-scale deployment of authenticated TLS for SMTP requires that
+ the DNS be secure.
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 7]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ Since SMTP security depends critically on DNSSEC, it is important to
+ point out that consequently SMTP with DANE is the most conservative
+ possible trust model. It trusts only what must be trusted and no
+ more. Adding any other trusted actors to the mix can only reduce
+ SMTP security. A sender may choose to further harden DNSSEC for
+ selected high-value receiving domains by configuring explicit trust
+ anchors for those domains instead of relying on the chain of trust
+ from the root domain. However, detailed discussion of DNSSEC
+ security practices is out of scope for this document.
+
+1.3.3. Sender policy does not scale
+
+ Sending systems are in some cases explicitly configured to use TLS
+ for mail sent to selected peer domains. This requires sending MTAs
+ to be configured with appropriate subject names or certificate
+ content digests to expect in the presented server certificates.
+ Because of the heavy administrative burden, such statically
+ configured SMTP secure channels are used rarely (generally only
+ between domains that make bilateral arrangements with their business
+ partners). Internet email, on the other hand, requires regularly
+ contacting new domains for which security configurations cannot be
+ established in advance.
+
+ The abstraction of the SMTP transport endpoint via DNS MX records,
+ often across organization boundaries, limits the use of public CA PKI
+ with SMTP to a small set of sender-configured peer domains. With
+ little opportunity to use TLS authentication, sending MTAs are rarely
+ configured with a comprehensive list of trusted CAs. SMTP services
+ that support STARTTLS often deploy X.509 certificates that are self-
+ signed or issued by a private CA.
+
+1.3.4. Too many certification authorities
+
+ Even if it were generally possible to determine a secure server name,
+ the SMTP client would still need to verify that the server's
+ certificate chain is issued by a trusted Certification Authority (a
+ trust anchor). MTAs are not interactive applications where a human
+ operator can make a decision (wisely or otherwise) to selectively
+ disable TLS security policy when certificate chain verification
+ fails. With no user to "click OK", the MTA's list of public CA trust
+ anchors would need to be comprehensive in order to avoid bouncing
+ mail addressed to sites that employ unknown Certification
+ Authorities.
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 8]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ On the other hand, each trusted CA can issue certificates for any
+ domain. If even one of the configured CAs is compromised or operated
+ by an adversary, it can subvert TLS security for all destinations.
+ Any set of CAs is simultaneously both overly inclusive and not
+ inclusive enough.
+
+2. Identifying applicable TLSA records
+
+2.1. DNS considerations
+
+2.1.1. DNS errors, bogus and indeterminate responses
+
+ An SMTP client that implements opportunistic DANE TLS per this
+ specification depends critically on the integrity of DNSSEC lookups,
+ as discussed in Section 1.3.2. This section lists the DNS resolver
+ requirements needed to avoid downgrade attacks when using
+ opportunistic DANE TLS.
+
+ A DNS lookup may signal an error or return a definitive answer. A
+ security-aware resolver must be used for this specification.
+ Security-aware resolvers will indicate the security status of a DNS
+ RRset with one of four possible values defined in Section 4.3 of
+ [RFC4035]: "secure", "insecure", "bogus" and "indeterminate". In
+ [RFC4035] the meaning of the "indeterminate" security status is:
+
+ An RRset for which the resolver is not able to determine whether
+ the RRset should be signed, as the resolver is not able to obtain
+ the necessary DNSSEC RRs. This can occur when the security-aware
+ resolver is not able to contact security-aware name servers for
+ the relevant zones.
+
+ Note, the "indeterminate" security status has a conflicting
+ definition in section 5 of [RFC4033].
+
+ There is no trust anchor that would indicate that a specific
+ portion of the tree is secure.
+
+ To avoid further confusion, the adjective "anchorless" will be used
+ below to refer to domains or RRsets that are "indeterminate" in the
+ [RFC4033] sense, and the term "indeterminate" will be used
+ exclusively in the sense of [RFC4035].
+
+ SMTP clients following this specification SHOULD NOT distinguish
+ between "insecure" and "anchorless" DNS responses. Both "insecure"
+ and "anchorless" RRsets MUST be handled identically: in either case
+ unvalidated data for the query domain is all that is and can be
+ available, and authentication using the data is impossible. In what
+ follows, the term "insecure" will also include the case of
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 9]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ "anchorless" domains that lie in a portion of the DNS tree for which
+ there is no applicable trust anchor. With the DNS root zone signed,
+ we expect that validating resolvers used by Internet-facing MTAs will
+ be configured with trust anchor data for the root zone, and that
+ therefore "anchorless" domains should be rare in practice.
+
+ As noted in section 4.3 of [RFC4035], a security-aware DNS resolver
+ MUST be able to determine whether a given non-error DNS response is
+ "secure", "insecure", "bogus" or "indeterminate". It is expected
+ that most security-aware stub resolvers will not signal an
+ "indeterminate" security status (in the sense of RFC4035) to the
+ application, and will signal a "bogus" or error result instead. If a
+ resolver does signal an RFC4035 "indeterminate" security status, this
+ MUST be treated by the SMTP client as though a "bogus" or error
+ result had been returned.
+
+ An MTA making use of a non-validating security-aware stub resolver
+ MAY use the stub resolver's ability, if available, to signal DNSSEC
+ validation status based on information the stub resolver has learned
+ from an upstream validating recursive resolver. Security-Oblivious
+ stub-resolvers MUST NOT be used. In accordance with section 4.9.3 of
+ [RFC4035]:
+
+ ... a security-aware stub resolver MUST NOT place any reliance on
+ signature validation allegedly performed on its behalf, except
+ when the security-aware stub resolver obtained the data in question
+ from a trusted security-aware recursive name server via a secure
+ channel.
+
+ To avoid much repetition in the text below, we will pause to explain
+ the handling of "bogus" or "indeterminate" DNSSEC query responses.
+ These are not necessarily the result of a malicious actor; they can,
+ for example, occur when network packets are corrupted or lost in
+ transit. Therefore, "bogus" or "indeterminate" replies are equated
+ in this memo with lookup failure.
+
+ There is an important non-failure condition we need to highlight in
+ addition to the obvious case of the DNS client obtaining a non-empty
+ "secure" or "insecure" RRset of the requested type. Namely, it is
+ not an error when either "secure" or "insecure" non-existence is
+ determined for the requested data. When a DNSSEC response with a
+ validation status that is either "secure" or "insecure" reports
+ either no records of the requested type or non-existence of the query
+ domain, the response is not a DNS error condition. The DNS client
+ has not been left without an answer; it has learned that records of
+ the requested type do not exist.
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 10]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ Security-aware stub resolvers will, of course, also signal DNS lookup
+ errors in other cases, for example when processing a "ServFail"
+ RCODE, which will not have an associated DNSSEC status. All lookup
+ errors are treated the same way by this specification, regardless of
+ whether they are from a "bogus" or "indeterminate" DNSSEC status or
+ from a more generic DNS error: the information that was requested
+ cannot be obtained by the security-aware resolver at this time. A
+ lookup error is thus a failure to obtain the relevant RRset if it
+ exists, or to determine that no such RRset exists when it does not.
+
+ In contrast to a "bogus" or an "indeterminate" response, an
+ "insecure" DNSSEC response is not an error, rather it indicates that
+ the target DNS zone is either securely opted out of DNSSEC validation
+ or is not connected with the DNSSEC trust anchors being used.
+ Insecure results will leave the SMTP client with degraded channel
+ security, but do not stand in the way of message delivery. See
+ section Section 2.2 for further details.
+
+2.1.2. DNS error handling
+
+ When a DNS lookup failure (error or "bogus" or "indeterminate" as
+ defined above) prevents an SMTP client from determining which SMTP
+ server or servers it should connect to, message delivery MUST be
+ delayed. This naturally includes, for example, the case when a
+ "bogus" or "indeterminate" response is encountered during MX
+ resolution. When multiple MX hostnames are obtained from a
+ successful MX lookup, but a later DNS lookup failure prevents network
+ address resolution for a given MX hostname, delivery may proceed via
+ any remaining MX hosts.
+
+ When a particular SMTP server is securely identified as the delivery
+ destination, a set of DNS lookups (Section 2.2) MUST be performed to
+ locate any related TLSA records. If any DNS queries used to locate
+ TLSA records fail (be it due to "bogus" or "indeterminate" records,
+ timeouts, malformed replies, ServFails, etc.), then the SMTP client
+ MUST treat that server as unreachable and MUST NOT deliver the
+ message via that server. If no servers are reachable, delivery is
+ delayed.
+
+ In what follows, we will only describe what happens when all relevant
+ DNS queries succeed. If any DNS failure occurs, the SMTP client MUST
+ behave as described in this section, by skipping the problem SMTP
+ server, or the problem destination. Queries for candidate TLSA
+ records are explicitly part of "all relevant DNS queries" and SMTP
+ clients MUST NOT continue to connect to an SMTP server or destination
+ whose TLSA record lookup fails.
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 11]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+2.1.3. Stub resolver considerations
+
+ SMTP clients that employ opportunistic DANE TLS to secure connections
+ to SMTP servers MUST NOT use Security-Oblivious stub-resolvers.
+
+ A note about DNAME aliases: a query for a domain name whose ancestor
+ domain is a DNAME alias returns the DNAME RR for the ancestor domain
+ along with a CNAME that maps the query domain to the corresponding
+ sub-domain of the target domain of the DNAME alias [RFC6672].
+ Therefore, whenever we speak of CNAME aliases, we implicitly allow
+ for the possibility that the alias in question is the result of an
+ ancestor domain DNAME record. Consequently, no explicit support for
+ DNAME records is needed in SMTP software; it is sufficient to process
+ the resulting CNAME aliases. DNAME records only require special
+ processing in the validating stub-resolver library that checks the
+ integrity of the combined DNAME + CNAME reply. When DNSSEC
+ validation is handled by a local caching resolver, rather than the
+ MTA itself, even that part of the DNAME support logic is outside the
+ MTA.
+
+ When a stub resolver returns a response containing a CNAME alias that
+ does not also contain the corresponding query results for the target
+ of the alias, the SMTP client will need to repeat the query at the
+ target of the alias, and should do so recursively up to some
+ configured or implementation-dependent recursion limit. If at any
+ stage of CNAME expansion an error is detected, the lookup of the
+ original requested records MUST be considered to have failed.
+
+ Whether a chain of CNAME records was returned in a single stub
+ resolver response or via explicit recursion by the SMTP client, if at
+ any stage of recursive expansion an "insecure" CNAME record is
+ encountered, then it and all subsequent results (in particular, the
+ final result) MUST be considered "insecure" regardless of whether any
+ earlier CNAME records leading to the "insecure" record were "secure".
+
+ Note that a security-aware non-validating stub resolver may return to
+ the SMTP client an "insecure" reply received from a validating
+ recursive resolver that contains a CNAME record along with additional
+ answers recursively obtained starting at the target of the CNAME. In
+ this case, the only possible conclusion is that some record in the
+ set of records returned is "insecure", and it is in fact possible
+ that the initial CNAME record and a subset of the subsequent records
+ are "secure".
+
+ If the SMTP client needs to determine the security status of the DNS
+ zone containing the initial CNAME record, it may need to issue a
+ separate query of type "CNAME" that returns only the initial CNAME
+ record. In particular in Section 2.2.2 when insecure A or AAAA
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 12]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ records are found for an SMTP server via a CNAME alias, it may be
+ necessary to perform an additional CNAME query to determine whether
+ the DNS zone in which the alias is published is signed.
+
+2.2. TLS discovery
+
+ As noted previously (in Section 1.3.1), opportunistic TLS with SMTP
+ servers that advertise TLS support via STARTTLS is subject to an MITM
+ downgrade attack. Also some SMTP servers that are not, in fact, TLS
+ capable erroneously advertise STARTTLS by default and clients need to
+ be prepared to retry cleartext delivery after STARTTLS fails. In
+ contrast, DNSSEC validated TLSA records MUST NOT be published for
+ servers that do not support TLS. Clients can safely interpret their
+ presence as a commitment by the server operator to implement TLS and
+ STARTTLS.
+
+ This memo defines four actions to be taken after the search for a
+ TLSA record returns secure usable results, secure unusable results,
+ insecure or no results or an error signal. The term "usable" in this
+ context is in the sense of Section 4.1 of [RFC6698]. Specifically,
+ if the DNS lookup for a TLSA record returns:
+
+ A secure TLSA RRset with at least one usable record: A connection to
+ the MTA MUST be made using authenticated and encrypted TLS, using
+ the techniques discussed in the rest of this document. Failure to
+ establish an authenticated TLS connection MUST result in falling
+ back to the next SMTP server or delayed delivery.
+
+ A secure non-empty TLSA RRset where all the records are unusable: A
+ connection to the MTA MUST be made via TLS, but authentication is
+ not required. Failure to establish an encrypted TLS connection
+ MUST result in falling back to the next SMTP server or delayed
+ delivery.
+
+ An insecure TLSA RRset or DNSSEC validated proof-of-non-existent TLSA
+ records:
+ A connection to the MTA SHOULD be made using (pre-DANE)
+ opportunistic TLS, this includes using cleartext delivery when the
+ remote SMTP server does not appear to support TLS. The MTA MAY
+ retry in cleartext when delivery via TLS fails either during the
+ handshake or even during data transfer.
+
+ Any lookup error: Lookup errors, including "bogus" and
+ "indeterminate", as explained in Section 2.1.1 MUST result in
+ falling back to the next SMTP server or delayed delivery.
+
+ An SMTP client MAY be configured to require DANE verified delivery
+ for some destinations. We will call such a configuration "mandatory
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 13]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ DANE TLS". With mandatory DANE TLS, delivery proceeds only when
+ "secure" TLSA records are used to establish an encrypted and
+ authenticated TLS channel with the SMTP server.
+
+ When the original next-hop destination is an address literal, rather
+ than a DNS domain, DANE TLS does not apply. Delivery proceeds using
+ any relevant security policy configured by the MTA administrator.
+ Similarly, when an MX RRset incorrectly lists a network address in
+ lieu of an MX hostname, if an MTA chooses to connect to the network
+ address in the non-conformant MX record, DANE TLSA does not apply for
+ such a connection.
+
+ In the subsections that follow we explain how to locate the SMTP
+ servers and the associated TLSA records for a given next-hop
+ destination domain. We also explain which name or names are to be
+ used in identity checks of the SMTP server certificate.
+
+2.2.1. MX resolution
+
+ In this section we consider next-hop domains that are subject to MX
+ resolution and have MX records. The TLSA records and the associated
+ base domain are derived separately for each MX hostname that is used
+ to attempt message delivery. DANE TLS can authenticate message
+ delivery to the intended next-hop domain only when the MX records are
+ obtained securely via a DNSSEC validated lookup.
+
+ MX records MUST be sorted by preference; an MX hostname with a worse
+ (numerically higher) MX preference that has TLSA records MUST NOT
+ preempt an MX hostname with a better (numerically lower) preference
+ that has no TLSA records. In other words, prevention of delivery
+ loops by obeying MX preferences MUST take precedence over channel
+ security considerations. Even with two equal-preference MX records,
+ an MTA is not obligated to choose the MX hostname that offers more
+ security. Domains that want secure inbound mail delivery need to
+ ensure that all their SMTP servers and MX records are configured
+ accordingly.
+
+ In the language of [RFC5321] Section 5.1, the original next-hop
+ domain is the "initial name". If the MX lookup of the initial name
+ results in a CNAME alias, the MTA replaces the initial name with the
+ resulting name and performs a new lookup with the new name. MTAs
+ typically support recursion in CNAME expansion, so this replacement
+ is performed repeatedly (up to the MTA's recursion limit) until the
+ ultimate non-CNAME domain is found.
+
+ If the MX RRset (or any CNAME leading to it) is "insecure" (see
+ Section 2.1.1), DANE TLS need not apply, and delivery MAY proceed via
+ pre-DANE opportunistic TLS. That said, the protocol in this memo is
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 14]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ an "opportunistic security" protocol, meaning that it strives to
+ communicate with each peer as securely as possible, while maintaining
+ broad interoperability. Therefore, the SMTP client MAY proceed to
+ use DANE TLS (as described in Section 2.2.2 below) even with MX hosts
+ obtained via an "insecure" MX RRset. For example, when a hosting
+ provider has a signed DNS zone and publishes TLSA records for its
+ SMTP servers, hosted domains that are not signed may still benefit
+ from the provider's TLSA records. Deliveries via the provider's SMTP
+ servers will not be subject to active attacks when sending SMTP
+ clients elect to make use of the provider's TLSA records.
+
+ When the MX records are not (DNSSEC) signed, an active attacker can
+ redirect SMTP clients to MX hosts of his choice. Such redirection is
+ tamper-evident when SMTP servers found via "insecure" MX records are
+ recorded as the next-hop relay in the MTA delivery logs in their
+ original (rather than CNAME expanded) form. Sending MTAs SHOULD log
+ unexpanded MX hostnames when these result from insecure MX lookups.
+ Any successful authentication via an insecurely determined MX host
+ MUST NOT be misrepresented in the mail logs as secure delivery to the
+ intended next-hop domain. When DANE TLS is mandatory (Section 6) for
+ a given destination, delivery MUST be delayed when the MX RRset is
+ not "secure".
+
+ Otherwise, assuming no DNS errors (Section 2.1.1), the MX RRset is
+ "secure", and the SMTP client MUST treat each MX hostname as a
+ separate non-MX destination for opportunistic DANE TLS as described
+ in Section 2.2.2. When, for a given MX hostname, no TLSA records are
+ found, or only "insecure" TLSA records are found, DANE TLSA is not
+ applicable with the SMTP server in question and delivery proceeds to
+ that host as with pre-DANE opportunistic TLS. To avoid downgrade
+ attacks, any errors during TLSA lookups MUST, as explained in
+ Section 2.1.1, cause the SMTP server in question to be treated as
+ unreachable.
+
+2.2.2. Non-MX destinations
+
+ This section describes the algorithm used to locate the TLSA records
+ and associated TLSA base domain for an input domain not subject to MX
+ resolution. Such domains include:
+
+ o Each MX hostname used in a message delivery attempt for an
+ original next-hop destination domain subject to MX resolution.
+ Note, MTAs are not obligated to support CNAME expansion of MX
+ hostnames.
+
+ o Any administrator configured relay hostname, not subject to MX
+ resolution. This frequently involves configuration set by the MTA
+ administrator to handle some or all mail.
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 15]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ o A next-hop destination domain subject to MX resolution that has no
+ MX records. In this case the domain's name is implicitly also its
+ sole SMTP server name.
+
+ Note that DNS queries with type TLSA are mishandled by load balancing
+ nameservers that serve the MX hostnames of some large email
+ providers. The DNS zones served by these nameservers are not signed
+ and contain no TLSA records, but queries for TLSA records fail,
+ rather than returning the non-existence of the requested TLSA
+ records.
+
+ To avoid problems delivering mail to domains whose SMTP servers are
+ served by the problem nameservers the SMTP client MUST perform any A
+ and/or AAAA queries for the destination before attempting to locate
+ the associated TLSA records. This lookup is needed in any case to
+ determine whether the destination domain is reachable and the DNSSEC
+ validation status of the chain of CNAME queries required to reach the
+ ultimate address records.
+
+ If no address records are found, the destination is unreachable. If
+ address records are found, but the DNSSEC validation status of the
+ first query response is "insecure" (see Section 2.1.3), the SMTP
+ client SHOULD NOT proceed to search for any associated TLSA records.
+ With the problem domains, TLSA queries will lead to DNS lookup errors
+ and cause messages to be consistently delayed and ultimately returned
+ to the sender. We don't expect to find any "secure" TLSA records
+ associated with a TLSA base domain that lies in an unsigned DNS zone.
+ Therefore, skipping TLSA lookups in this case will also reduce
+ latency with no detrimental impact on security.
+
+ If the A and/or AAAA lookup of the "initial name" yields a CNAME, we
+ replace it with the resulting name as if it were the initial name and
+ perform a lookup again using the new name. This replacement is
+ performed recursively (up to the MTA's recursion limit).
+
+ We consider the following cases for handling a DNS response for an A
+ or AAAA DNS lookup:
+
+ Not found: When the DNS queries for A and/or AAAA records yield
+ neither a list of addresses nor a CNAME (or CNAME expansion is not
+ supported) the destination is unreachable.
+
+
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 16]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ Non-CNAME: The answer is not a CNAME alias. If the address RRset
+ is "secure", TLSA lookups are performed as described in
+ Section 2.2.3 with the initial name as the candidate TLSA base
+ domain. If no "secure" TLSA records are found, DANE TLS is not
+ applicable and mail delivery proceeds with pre-DANE opportunistic
+ TLS (which, being best-effort, degrades to cleartext delivery when
+ STARTTLS is not available or the TLS handshake fails).
+
+ Insecure CNAME: The input domain is a CNAME alias, but the ultimate
+ network address RRset is "insecure" (see Section 2.1.1). If the
+ initial CNAME response is also "insecure", DANE TLS does not
+ apply. Otherwise, this case is treated just like the non-CNAME
+ case above, where a search is performed for a TLSA record with the
+ original input domain as the candidate TLSA base domain.
+
+ Secure CNAME: The input domain is a CNAME alias, and the ultimate
+ network address RRset is "secure" (see Section 2.1.1). Two
+ candidate TLSA base domains are tried: the fully CNAME-expanded
+ initial name and, failing that, then the initial name itself.
+
+ In summary, if it is possible to securely obtain the full, CNAME-
+ expanded, DNSSEC-validated address records for the input domain, then
+ that name is the preferred TLSA base domain. Otherwise, the
+ unexpanded input-MX domain is the candidate TLSA base domain. When
+ no "secure" TLSA records are found at either the CNAME-expanded or
+ unexpanded domain, then DANE TLS does not apply for mail delivery via
+ the input domain in question. And, as always, errors, bogus or
+ indeterminate results for any query in the process MUST result in
+ delaying or abandoning delivery.
+
+2.2.3. TLSA record lookup
+
+ Each candidate TLSA base domain (the original or fully CNAME-expanded
+ name of a non-MX destination or a particular MX hostname of an MX
+ destination) is in turn prefixed with service labels of the form
+ "_<port>._tcp". The resulting domain name is used to issue a DNSSEC
+ query with the query type set to TLSA ([RFC6698] Section 7.1).
+
+ For SMTP, the destination TCP port is typically 25, but this may be
+ different with custom routes specified by the MTA administrator in
+ which case the SMTP client MUST use the appropriate number in the
+ "_<port>" prefix in place of "_25". If, for example, the candidate
+ base domain is "mx.example.com", and the SMTP connection is to port
+ 25, the TLSA RRset is obtained via a DNSSEC query of the form:
+
+ _25._tcp.mx.example.com. IN TLSA ?
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 17]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ The query response may be a CNAME, or the actual TLSA RRset. If the
+ response is a CNAME, the SMTP client (through the use of its
+ security-aware stub resolver) restarts the TLSA query at the target
+ domain, following CNAMEs as appropriate and keeping track of whether
+ the entire chain is "secure". If any "insecure" records are
+ encountered, or the TLSA records don't exist, the next candidate TLSA
+ base domain is tried instead.
+
+ If the ultimate response is a "secure" TLSA RRset, then the candidate
+ TLSA base domain will be the actual TLSA base domain and the TLSA
+ RRset will constitute the TLSA records for the destination. If none
+ of the candidate TLSA base domains yield "secure" TLSA records then
+ delivery MAY proceed via pre-DANE opportunistic TLS. SMTP clients
+ MAY elect to use "insecure" TLSA records to avoid STARTTLS downgrades
+ or even to skip SMTP servers that fail authentication, but MUST NOT
+ misrepresent authentication success as either a secure connection to
+ the SMTP server or as a secure delivery to the intended next-hop
+ domain.
+
+ TLSA record publishers may leverage CNAMEs to reference a single
+ authoritative TLSA RRset specifying a common Certification Authority
+ or a common end entity certificate to be used with multiple TLS
+ services. Such CNAME expansion does not change the SMTP client's
+ notion of the TLSA base domain; thus, when _25._tcp.mx.example.com is
+ a CNAME, the base domain remains mx.example.com and this is still the
+ reference identifier used together with the next-hop domain in peer
+ certificate name checks.
+
+ Note that shared end entity certificate associations expose the
+ publishing domain to substitution attacks, where an MITM attacker can
+ reroute traffic to a different server that shares the same end entity
+ certificate. Such shared end entity TLSA records SHOULD be avoided
+ unless the servers in question are functionally equivalent or employ
+ mutually incompatible protocols (an active attacker gains nothing by
+ diverting client traffic from one such server to another).
+
+ A better example, employing a shared trust anchor rather than shared
+ end-entity certificates, is illustrated by the DNSSEC validated
+ records below:
+
+ example.com. IN MX 0 mx1.example.com.
+ example.com. IN MX 0 mx2.example.com.
+ _25._tcp.mx1.example.com. IN CNAME tlsa201._dane.example.com.
+ _25._tcp.mx2.example.com. IN CNAME tlsa201._dane.example.com.
+ tlsa201._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c149a...
+
+ The SMTP servers mx1.example.com and mx2.example.com will be expected
+ to have certificates issued under a common trust anchor, but each MX
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 18]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ hostname's TLSA base domain remains unchanged despite the above CNAME
+ records. Correspondingly, each SMTP server will be associated with a
+ pair of reference identifiers consisting of its hostname plus the
+ next-hop domain "example.com".
+
+ If, during TLSA resolution (including possible CNAME indirection), at
+ least one "secure" TLSA record is found (even if not usable because
+ it is unsupported by the implementation or support is
+ administratively disabled), then the corresponding host has signaled
+ its commitment to implement TLS. The SMTP client MUST NOT deliver
+ mail via the corresponding host unless a TLS session is negotiated
+ via STARTTLS. This is required to avoid MITM STARTTLS downgrade
+ attacks.
+
+ As noted previously (in Section Section 2.2.2), when no "secure" TLSA
+ records are found at the fully CNAME-expanded name, the original
+ unexpanded name MUST be tried instead. This supports customers of
+ hosting providers where the provider's zone cannot be validated with
+ DNSSEC, but the customer has shared appropriate key material with the
+ hosting provider to enable TLS via SNI. Intermediate names that
+ arise during CNAME expansion that are neither the original, nor the
+ final name, are never candidate TLSA base domains, even if "secure".
+
+3. DANE authentication
+
+ This section describes which TLSA records are applicable to SMTP
+ opportunistic DANE TLS and how to apply such records to authenticate
+ the SMTP server. With opportunistic DANE TLS, both the TLS support
+ implied by the presence of DANE TLSA records and the verification
+ parameters necessary to authenticate the TLS peer are obtained
+ together. In contrast to protocols where channel security policy is
+ set exclusively by the client, authentication via this protocol is
+ expected to be less prone to connection failure caused by
+ incompatible configuration of the client and server.
+
+3.1. TLSA certificate usages
+
+ The DANE TLSA specification [RFC6698] defines multiple TLSA RR types
+ via combinations of 3 numeric parameters. The numeric values of
+ these parameters were later given symbolic names in [RFC7218]. The
+ rest of the TLSA record is the "certificate association data field",
+ which specifies the full or digest value of a certificate or public
+ key. The parameters are:
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 19]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ The TLSA Certificate Usage field: Section 2.1.1 of [RFC6698]
+ specifies four values: PKIX-TA(0), PKIX-EE(1), DANE-TA(2), and
+ DANE-EE(3). There is an additional private-use value:
+ PrivCert(255). All other values are reserved for use by future
+ specifications.
+
+ The selector field: Section 2.1.2 of [RFC6698] specifies two values:
+ Cert(0) and SPKI(1). There is an additional private-use value:
+ PrivSel(255). All other values are reserved for use by future
+ specifications.
+
+ The matching type field: Section 2.1.3 of [RFC6698] specifies three
+ values: Full(0), SHA2-256(1) and SHA2-512(2). There is an
+ additional private-use value: PrivMatch(255). All other values
+ are reserved for use by future specifications.
+
+ We may think of TLSA Certificate Usage values 0 through 3 as a
+ combination of two one-bit flags. The low bit chooses between trust
+ anchor (TA) and end entity (EE) certificates. The high bit chooses
+ between public PKI issued and domain-issued certificates.
+
+ The selector field specifies whether the TLSA RR matches the whole
+ certificate: Cert(0), or just its subjectPublicKeyInfo: SPKI(1). The
+ subjectPublicKeyInfo is an ASN.1 DER ([X.690]) encoding of the
+ certificate's algorithm id, any parameters and the public key data.
+
+ The matching type field specifies how the TLSA RR Certificate
+ Association Data field is to be compared with the certificate or
+ public key. A value of Full(0) means an exact match: the full DER
+ encoding of the certificate or public key is given in the TLSA RR. A
+ value of SHA2-256(1) means that the association data matches the
+ SHA2-256 digest of the certificate or public key, and likewise
+ SHA2-512(2) means a SHA2-512 digest is used.
+
+ Since opportunistic DANE TLS will be used by non-interactive MTAs,
+ with no user to "press OK" when authentication fails, reliability of
+ peer authentication is paramount. Server operators are advised to
+ publish TLSA records that are least likely to fail authentication due
+ to interoperability or operational problems. Because DANE TLS relies
+ on coordinated changes to DNS and SMTP server settings, the best
+ choice of records to publish will depend on site-specific practices.
+
+
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 20]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ The certificate usage element of a TLSA record plays a critical role
+ in determining how the corresponding certificate association data
+ field is used to authenticate server's certificate chain. The next
+ two subsections explain the process for certificate usages DANE-EE(3)
+ and DANE-TA(2). The third subsection briefly explains why
+ certificate usages PKIX-TA(0) and PKIX-EE(1) are not applicable with
+ opportunistic DANE TLS.
+
+ In summary, we recommend the use of either "DANE-EE(3) SPKI(1)
+ SHA2-256(1)" or "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA records
+ depending on site needs. Other combinations of TLSA parameters are
+ either explicitly unsupported, or offer little to recommend them over
+ these two.
+
+ The mandatory to support digest algorithm in [RFC6698] is
+ SHA2-256(1). When the server's TLSA RRset includes records with a
+ matching type indicating a digest record (i.e., a value other than
+ Full(0)), a TLSA record with a SHA2-256(1) matching type SHOULD be
+ provided along with any other digest published, since some SMTP
+ clients may support only SHA2-256(1). If at some point the SHA2-256
+ digest algorithm is tarnished by new cryptanalytic attacks,
+ publishers will need to include an appropriate stronger digest in
+ their TLSA records, initially along with, and ultimately in place of,
+ SHA2-256.
+
+3.1.1. Certificate usage DANE-EE(3)
+
+ Authentication via certificate usage DANE-EE(3) TLSA records involves
+ simply checking that the server's leaf certificate matches the TLSA
+ record. In particular the binding of the server public key to its
+ name is based entirely on the TLSA record association. The server
+ MUST be considered authenticated even if none of the names in the
+ certificate match the client's reference identity for the server.
+
+ Similarly, the expiration date of the server certificate MUST be
+ ignored, the validity period of the TLSA record key binding is
+ determined by the validity interval of the TLSA record DNSSEC
+ signature.
+
+ With DANE-EE(3) servers need not employ SNI (may ignore the client's
+ SNI message) even when the server is known under independent names
+ that would otherwise require separate certificates. It is instead
+ sufficient for the TLSA RRsets for all the domains in question to
+ match the server's default certificate. Of course with SMTP servers
+ it is simpler still to publish the same MX hostname for all the
+ hosted domains.
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 21]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ For domains where it is practical to make coordinated changes in DNS
+ TLSA records during SMTP server key rotation, it is often best to
+ publish end-entity DANE-EE(3) certificate associations. DANE-EE(3)
+ certificates don't suddenly stop working when leaf or intermediate
+ certificates expire, and don't fail when the server operator neglects
+ to configure all the required issuer certificates in the server
+ certificate chain.
+
+ TLSA records published for SMTP servers SHOULD, in most cases, be
+ "DANE-EE(3) SPKI(1) SHA2-256(1)" records. Since all DANE
+ implementations are required to support SHA2-256, this record type
+ works for all clients and need not change across certificate renewals
+ with the same key.
+
+3.1.2. Certificate usage DANE-TA(2)
+
+ Some domains may prefer to avoid the operational complexity of
+ publishing unique TLSA RRs for each TLS service. If the domain
+ employs a common issuing Certification Authority to create
+ certificates for multiple TLS services, it may be simpler to publish
+ the issuing authority as a trust anchor (TA) for the certificate
+ chains of all relevant services. The TLSA query domain (TLSA base
+ domain with port and protocol prefix labels) for each service issued
+ by the same TA may then be set to a CNAME alias that points to a
+ common TLSA RRset that matches the TA. For example:
+
+ example.com. IN MX 0 mx1.example.com.
+ example.com. IN MX 0 mx2.example.com.
+ _25._tcp.mx1.example.com. IN CNAME tlsa201._dane.example.com.
+ _25._tcp.mx2.example.com. IN CNAME tlsa201._dane.example.com.
+ tlsa201._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c14....
+
+ With usage DANE-TA(2) the server certificates will need to have names
+ that match one of the client's reference identifiers (see [RFC6125]).
+ The server MAY employ SNI to select the appropriate certificate to
+ present to the client.
+
+ SMTP servers that rely on certificate usage DANE-TA(2) TLSA records
+ for TLS authentication MUST include the TA certificate as part of the
+ certificate chain presented in the TLS handshake server certificate
+ message even when it is a self-signed root certificate. At this
+ time, many SMTP servers are not configured with a comprehensive list
+ of trust anchors, nor are they expected to at any point in the
+ future. Some MTAs will ignore all locally trusted certificates when
+ processing usage DANE-TA(2) TLSA records. Thus even when the TA
+ happens to be a public Certification Authority known to the SMTP
+ client, authentication is likely to fail unless the TA certificate is
+ included in the TLS server certificate message.
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 22]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ TLSA records with selector Full(0) are discouraged. While these
+ potentially obviate the need to transmit the TA certificate in the
+ TLS server certificate message, client implementations may not be
+ able to augment the server certificate chain with the data obtained
+ from DNS, especially when the TLSA record supplies a bare key
+ (selector SPKI(1)). Since the server will need to transmit the TA
+ certificate in any case, server operators SHOULD publish TLSA records
+ with a selector other than Full(0) and avoid potential
+ interoperability issues with large TLSA records containing full
+ certificates or keys.
+
+ TLSA Publishers employing DANE-TA(2) records SHOULD publish records
+ with a selector of Cert(0). Such TLSA records are associated with
+ the whole trust anchor certificate, not just with the trust anchor
+ public key. In particular, the SMTP client SHOULD then apply any
+ relevant constraints from the trust anchor certificate, such as, for
+ example, path length constraints.
+
+ While a selector of SPKI(1) may also be employed, the resulting TLSA
+ record will not specify the full trust anchor certificate content,
+ and elements of the trust anchor certificate other than the public
+ key become mutable. This may, for example, allow a subsidiary CA to
+ issue a chain that violates the trust anchor's path length or name
+ constraints.
+
+3.1.3. Certificate usages PKIX-TA(0) and PKIX-EE(1)
+
+ As noted in the introduction, SMTP clients cannot, without relying on
+ DNSSEC for secure MX records and DANE for STARTTLS support signaling,
+ perform server identity verification or prevent STARTTLS downgrade
+ attacks. The use of PKIX CAs offers no added security since an
+ attacker capable of compromising DNSSEC is free to replace any PKIX-
+ TA(0) or PKIX-EE(1) TLSA records with records bearing any convenient
+ non-PKIX certificate usage.
+
+ SMTP servers SHOULD NOT publish TLSA RRs with certificate usage PKIX-
+ TA(0) or PKIX-EE(1). SMTP clients cannot be expected to be
+ configured with a suitably complete set of trusted public CAs.
+ Lacking a complete set of public CAs, clients would not be able to
+ verify the certificates of SMTP servers whose issuing root CAs are
+ not trusted by the client.
+
+ Opportunistic DANE TLS needs to interoperate without bilateral
+ coordination of security settings between client and server systems.
+ Therefore, parameter choices that are fragile in the absence of
+ bilateral coordination are unsupported. Nothing is lost since the
+ PKIX certificate usages cannot aid SMTP TLS security, they can only
+ impede SMTP TLS interoperability.
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 23]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ SMTP client treatment of TLSA RRs with certificate usages PKIX-TA(0)
+ or PKIX-EE(1) is undefined. SMTP clients should generally treat such
+ TLSA records as unusable.
+
+3.2. Certificate matching
+
+ When at least one usable "secure" TLSA record is found, the SMTP
+ client MUST use TLSA records to authenticate the SMTP server.
+ Messages MUST NOT be delivered via the SMTP server if authentication
+ fails, otherwise the SMTP client is vulnerable to MITM attacks.
+
+3.2.1. DANE-EE(3) name checks
+
+ The SMTP client MUST NOT perform certificate name checks with
+ certificate usage DANE-EE(3); see Section 3.1.1 above.
+
+3.2.2. DANE-TA(2) name checks
+
+ To match a server via a TLSA record with certificate usage DANE-
+ TA(2), the client MUST perform name checks to ensure that it has
+ reached the correct server. In all DANE-TA(2) cases the SMTP client
+ MUST include the TLSA base domain as one of the valid reference
+ identifiers for matching the server certificate.
+
+ TLSA records for MX hostnames: If the TLSA base domain was obtained
+ indirectly via a "secure" MX lookup (including any CNAME-expanded
+ name of an MX hostname), then the original next-hop domain used in
+ the MX lookup MUST be included as as a second reference
+ identifier. The CNAME-expanded original next-hop domain MUST be
+ included as a third reference identifier if different from the
+ original next-hop domain. When the client MTA is employing DANE
+ TLS security despite "insecure" MX redirection the MX hostname is
+ the only reference identifier.
+
+ TLSA records for Non-MX hostnames: If MX records were not used
+ (e.g., if none exist) and the TLSA base domain is the CNAME-
+ expanded original next-hop domain, then the original next-hop
+ domain MUST be included as a second reference identifier.
+
+ Accepting certificates with the original next-hop domain in addition
+ to the MX hostname allows a domain with multiple MX hostnames to
+ field a single certificate bearing a single domain name (i.e., the
+ email domain) across all the SMTP servers. This also aids
+ interoperability with pre-DANE SMTP clients that are configured to
+ look for the email domain name in server certificates. For example,
+ with "secure" DNS records as below:
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 24]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ exchange.example.org. IN CNAME mail.example.org.
+ mail.example.org. IN CNAME example.com.
+ example.com. IN MX 10 mx10.example.com.
+ example.com. IN MX 15 mx15.example.com.
+ example.com. IN MX 20 mx20.example.com.
+ ;
+ mx10.example.com. IN A 192.0.2.10
+ _25._tcp.mx10.example.com. IN TLSA 2 0 1 ...
+ ;
+ mx15.example.com. IN CNAME mxbackup.example.com.
+ mxbackup.example.com. IN A 192.0.2.15
+ ; _25._tcp.mxbackup.example.com. IN TLSA ? (NXDOMAIN)
+ _25._tcp.mx15.example.com. IN TLSA 2 0 1 ...
+ ;
+ mx20.example.com. IN CNAME mxbackup.example.net.
+ mxbackup.example.net. IN A 198.51.100.20
+ _25._tcp.mxbackup.example.net. IN TLSA 2 0 1 ...
+
+ Certificate name checks for delivery of mail to exchange.example.org
+ via any of the associated SMTP servers MUST accept at least the names
+ "exchange.example.org" and "example.com", which are respectively the
+ original and fully expanded next-hop domain. When the SMTP server is
+ mx10.example.com, name checks MUST accept the TLSA base domain
+ "mx10.example.com". If, despite the fact that MX hostnames are
+ required to not be aliases, the MTA supports delivery via
+ "mx15.example.com" or "mx20.example.com" then name checks MUST accept
+ the respective TLSA base domains "mx15.example.com" and
+ "mxbackup.example.net".
+
+3.2.3. Reference identifier matching
+
+ When name checks are applicable (certificate usage DANE-TA(2)), if
+ the server certificate contains a Subject Alternative Name extension
+ ([RFC5280]), with at least one DNS-ID ([RFC6125]) then only the DNS-
+ IDs are matched against the client's reference identifiers. The CN-
+ ID ([RFC6125]) is only considered when no DNS-IDs are present. The
+ server certificate is considered matched when one of its presented
+ identifiers ([RFC5280]) matches any of the client's reference
+ identifiers.
+
+ Wildcards are valid in either DNS-IDs or the CN-ID when applicable.
+ The wildcard character must be entire first label of the DNS-ID or
+ CN-ID. Thus, "*.example.com" is valid, while "smtp*.example.com" and
+ "*smtp.example.com" are not. SMTP clients MUST support wildcards
+ that match the first label of the reference identifier, with the
+ remaining labels matching verbatim. For example, the DNS-ID
+ "*.example.com" matches the reference identifier "mx1.example.com".
+ SMTP clients MAY, subject to local policy allow wildcards to match
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 25]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ multiple reference identifier labels, but servers cannot expect broad
+ support for such a policy. Therefore any wildcards in server
+ certificates SHOULD match exactly one label in either the TLSA base
+ domain or the next-hop domain.
+
+4. Server key management
+
+ Two TLSA records MUST be published before employing a new EE or TA
+ public key or certificate, one matching the currently deployed key
+ and the other matching the new key scheduled to replace it. Once
+ sufficient time has elapsed for all DNS caches to expire the previous
+ TLSA RRset and related signature RRsets, servers may be configured to
+ use the new EE private key and associated public key certificate or
+ may employ certificates signed by the new trust anchor.
+
+ Once the new public key or certificate is in use, the TLSA RR that
+ matches the retired key can be removed from DNS, leaving only RRs
+ that match keys or certificates in active use.
+
+ As described in Section 3.1.2, when server certificates are validated
+ via a DANE-TA(2) trust anchor, and CNAME records are employed to
+ store the TA association data at a single location, the
+ responsibility of updating the TLSA RRset shifts to the operator of
+ the trust anchor. Before a new trust anchor is used to sign any new
+ server certificates, its certificate (digest) is added to the
+ relevant TLSA RRset. After enough time elapses for the original TLSA
+ RRset to age out of DNS caches, the new trust anchor can start
+ issuing new server certificates. Once all certificates issued under
+ the previous trust anchor have expired, its associated RRs can be
+ removed from the TLSA RRset.
+
+ In the DANE-TA(2) key management model server operators do not
+ generally need to update DNS TLSA records after initially creating a
+ CNAME record that references the centrally operated DANE-TA(2) RRset.
+ If a particular server's key is compromised, its TLSA CNAME SHOULD be
+ replaced with a DANE-EE(3) association until the certificate for the
+ compromised key expires, at which point it can return to using a
+ CNAME record. If the central trust anchor is compromised, all
+ servers need to be issued new keys by a new TA, and an updated DANE-
+ TA(2) TLSA RRset needs to be published containing just the new TA.
+
+ SMTP servers cannot expect broad CRL or OCSP support from SMTP
+ clients. As outlined above, with DANE, compromised server or trust
+ anchor keys can be "revoked" by removing them from the DNS without
+ the need for client-side support for OCSP or CRLs.
+
+5. Digest algorithm agility
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 26]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ While [RFC6698] specifies multiple digest algorithms, it does not
+ specify a protocol by which the SMTP client and TLSA record publisher
+ can agree on the strongest shared algorithm. Such a protocol would
+ allow the client and server to avoid exposure to any deprecated
+ weaker algorithms that are published for compatibility with less
+ capable clients, but should be ignored when possible. Such a
+ protocol is specified in [I-D.ietf-dane-ops]. SMTP clients and
+ servers that implement this specification MUST comply with the
+ requirements outlined under "Digest Algorithm Agility" in
+ [I-D.ietf-dane-ops].
+
+6. Mandatory TLS Security
+
+ An MTA implementing this protocol may require a stronger security
+ assurance when sending email to selected destinations. The sending
+ organization may need to send sensitive email and/or may have
+ regulatory obligations to protect its content. This protocol is not
+ in conflict with such a requirement, and in fact can often simplify
+ authenticated delivery to such destinations.
+
+ Specifically, with domains that publish DANE TLSA records for their
+ MX hostnames, a sending MTA can be configured to use the receiving
+ domains's DANE TLSA records to authenticate the corresponding SMTP
+ server. Authentication via DANE TLSA records is easier to manage, as
+ changes in the receiver's expected certificate properties are made on
+ the receiver end and don't require manually communicated
+ configuration changes. With mandatory DANE TLS, when no usable TLSA
+ records are found, message delivery is delayed. Thus, mail is only
+ sent when an authenticated TLS channel is established to the remote
+ SMTP server.
+
+ Administrators of mail servers that employ mandatory DANE TLS, need
+ to carefully monitor their mail logs and queues. If a partner domain
+ unwittingly misconfigures their TLSA records, disables DNSSEC, or
+ misconfigures SMTP server certificate chains, mail will be delayed
+ and may bounce if the issue is not resolved in a timely manner.
+
+7. Note on DANE for Message User Agents
+
+ We note that the SMTP protocol is also used between Message User
+ Agents (MUAs) and Message Submission Agents (MSAs) [RFC6409]. In
+ [RFC6186] a protocol is specified that enables an MUA to dynamically
+ locate the MSA based on the user's email address. SMTP connection
+ security considerations for MUAs implementing [RFC6186] are largely
+ analogous to connection security requirements for MTAs, and this
+ specification could be applied largely verbatim with DNS MX records
+ replaced by corresponding DNS Service (SRV) records
+ [I-D.ietf-dane-srv].
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 27]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ However, until MUAs begin to adopt the dynamic configuration
+ mechanisms of [RFC6186] they are adequately served by more
+ traditional static TLS security policies. Specification of DANE TLS
+ for Message User Agent (MUA) to Message Submission Agent (MSA) SMTP
+ is left to future documents that focus specifically on SMTP security
+ between MUAs and MSAs.
+
+8. Interoperability considerations
+
+8.1. SNI support
+
+ To ensure that the server sends the right certificate chain, the SMTP
+ client MUST send the TLS SNI extension containing the TLSA base
+ domain. This precludes the use of the backward compatible SSL 2.0
+ compatible SSL HELLO by the SMTP client. The minimum SSL/TLS client
+ HELLO version for SMTP clients performing DANE authentication is SSL
+ 3.0, but a client that offers SSL 3.0 MUST also offer at least TLS
+ 1.0 and MUST include the SNI extension. Servers that don't make use
+ of SNI MAY negotiate SSL 3.0 if offered by the client.
+
+ Each SMTP server MUST present a certificate chain (see [RFC5246]
+ Section 7.4.2) that matches at least one of the TLSA records. The
+ server MAY rely on SNI to determine which certificate chain to
+ present to the client. Clients that don't send SNI information may
+ not see the expected certificate chain.
+
+ If the server's TLSA records match the server's default certificate
+ chain, the server need not support SNI. In either case, the server
+ need not include the SNI extension in its TLS HELLO as simply
+ returning a matching certificate chain is sufficient. Servers MUST
+ NOT enforce the use of SNI by clients, as the client may be using
+ unauthenticated opportunistic TLS and may not expect any particular
+ certificate from the server. If the client sends no SNI extension,
+ or sends an SNI extension for an unsupported domain, the server MUST
+ simply send some fallback certificate chain of its choice. The
+ reason for not enforcing strict matching of the requested SNI
+ hostname is that DANE TLS clients are typically willing to accept
+ multiple server names, but can only send one name in the SNI
+ extension. The server's fallback certificate may match a different
+ name acceptable to the client, e.g., the original next-hop domain.
+
+8.2. Anonymous TLS cipher suites
+
+ Since many SMTP servers either do not support or do not enable any
+ anonymous TLS cipher suites, SMTP client TLS HELLO messages SHOULD
+ offer to negotiate a typical set of non-anonymous cipher suites
+ required for interoperability with such servers. An SMTP client
+ employing pre-DANE opportunistic TLS MAY in addition include one or
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 28]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ more anonymous TLS cipher suites in its TLS HELLO. SMTP servers,
+ that need to interoperate with opportunistic TLS clients SHOULD be
+ prepared to interoperate with such clients by either always selecting
+ a mutually supported non-anonymous cipher suite or by correctly
+ handling client connections that negotiate anonymous cipher suites.
+
+ Note that while SMTP server operators are under no obligation to
+ enable anonymous cipher suites, no security is gained by sending
+ certificates to clients that will ignore them. Indeed support for
+ anonymous cipher suites in the server makes audit trails more
+ informative. Log entries that record connections that employed an
+ anonymous cipher suite record the fact that the clients did not care
+ to authenticate the server.
+
+9. Operational Considerations
+
+9.1. Client Operational Considerations
+
+ An operational error on the sending or receiving side that cannot be
+ corrected in a timely manner may, at times, lead to consistent
+ failure to deliver time-sensitive email. The sending MTA
+ administrator may have to choose between letting email queue until
+ the error is resolved and disabling opportunistic or mandatory DANE
+ TLS for one or more destinations. The choice to disable DANE TLS
+ security should not be made lightly. Every reasonable effort should
+ be made to determine that problems with mail delivery are the result
+ of an operational error, and not an attack. A fallback strategy may
+ be to configure explicit out-of-band TLS security settings if
+ supported by the sending MTA.
+
+ SMTP clients may deploy opportunistic DANE TLS incrementally by
+ enabling it only for selected sites, or may occasionally need to
+ disable opportunistic DANE TLS for peers that fail to interoperate
+ due to misconfiguration or software defects on either end. Some
+ implementations MAY support DANE TLS in an "audit only" mode in which
+ failure to achieve the requisite security level is logged as a
+ warning and delivery proceeds at a reduced security level. Unless
+ local policy specifies "audit only" or that opportunistic DANE TLS is
+ not to be used for a particular destination, an SMTP client MUST NOT
+ deliver mail via a server whose certificate chain fails to match at
+ least one TLSA record when usable TLSA records are found for that
+ server.
+
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 29]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+9.2. Publisher Operational Considerations
+
+ SMTP servers that publish certificate usage DANE-TA(2) associations
+ MUST include the TA certificate in their TLS server certificate
+ chain, even when that TA certificate is a self-signed root
+ certificate.
+
+ TLSA Publishers MUST follow the guidelines in the "TLSA Publisher
+ Requirements" section of [I-D.ietf-dane-ops].
+
+ TLSA Publishers SHOULD follow the TLSA publication size guidance
+ found in [I-D.ietf-dane-ops] under "DANE DNS Record Size Guidelines".
+
+10. Security Considerations
+
+ This protocol leverages DANE TLSA records to implement MITM resistant
+ opportunistic security ([I-D.dukhovni-opportunistic-security]) for
+ SMTP. For destination domains that sign their MX records and publish
+ signed TLSA records for their MX hostnames, this protocol allows
+ sending MTAs to securely discover both the availability of TLS and
+ how to authenticate the destination.
+
+ This protocol does not aim to secure all SMTP traffic, as that is not
+ practical until DNSSEC and DANE adoption are universal. The
+ incremental deployment provided by following this specification is a
+ best possible path for securing SMTP. This protocol coexists and
+ interoperates with the existing insecure Internet email backbone.
+
+ The protocol does not preclude existing non-opportunistic SMTP TLS
+ security arrangements, which can continue to be used as before via
+ manual configuration with negotiated out-of-band key and TLS
+ configuration exchanges.
+
+ Opportunistic SMTP TLS depends critically on DNSSEC for downgrade
+ resistance and secure resolution of the destination name. If DNSSEC
+ is compromised, it is not possible to fall back on the public CA PKI
+ to prevent MITM attacks. A successful breach of DNSSEC enables the
+ attacker to publish TLSA usage 3 certificate associations, and
+ thereby bypass any security benefit the legitimate domain owner might
+ hope to gain by publishing usage 0 or 1 TLSA RRs. Given the lack of
+ public CA PKI support in existing MTA deployments, avoiding
+ certificate usages 0 and 1 simplifies implementation and deployment
+ with no adverse security consequences.
+
+ Implementations must strictly follow the portions of this
+ specification that indicate when it is appropriate to initiate a non-
+ authenticated connection or cleartext connection to a SMTP server.
+ Specifically, in order to prevent downgrade attacks on this protocol,
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 30]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ implementation must not initiate a connection when this specification
+ indicates a particular SMTP server must be considered unreachable.
+
+11. IANA considerations
+
+ This specification requires no support from IANA.
+
+12. Acknowledgements
+
+ The authors would like to extend great thanks to Tony Finch, who
+ started the original version of a DANE SMTP document. His work is
+ greatly appreciated and has been incorporated into this document.
+ The authors would like to additionally thank Phil Pennock for his
+ comments and advice on this document.
+
+ Acknowledgments from Viktor: Thanks to Paul Hoffman who motivated me
+ to begin work on this memo and provided feedback on early drafts.
+ Thanks to Patrick Koetter, Perry Metzger and Nico Williams for
+ valuable review comments. Thanks also to Wietse Venema who created
+ Postfix, and whose advice and feedback were essential to the
+ development of the Postfix DANE implementation.
+
+13. References
+
+13.1. Normative References
+
+ [I-D.ietf-dane-ops]
+ Dukhovni, V. and W. Hardaker, "Updates to and Operational
+ Guidance for the DANE Protocol", draft-ietf-dane-ops-06
+ (work in progress), August 2014.
+
+ [RFC1035] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
+ Transport Layer Security", RFC 3207, February 2002.
+
+ [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "DNS Security Introduction and Requirements", RFC
+ 4033, March 2005.
+
+ [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Resource Records for the DNS Security Extensions",
+ RFC 4034, March 2005.
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 31]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Protocol Modifications for the DNS Security
+ Extensions", RFC 4035, March 2005.
+
+ [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+ [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, May 2008.
+
+ [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
+ October 2008.
+
+ [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
+ Extension Definitions", RFC 6066, January 2011.
+
+ [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, March 2011.
+
+ [RFC6186] Daboo, C., "Use of SRV Records for Locating Email
+ Submission/Access Services", RFC 6186, March 2011.
+
+ [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
+ DNS", RFC 6672, June 2012.
+
+ [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
+ of Named Entities (DANE) Transport Layer Security (TLS)
+ Protocol: TLSA", RFC 6698, August 2012.
+
+ [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify
+ Conversations about DNS-Based Authentication of Named
+ Entities (DANE)", RFC 7218, April 2014.
+
+ [X.690] International Telecommunications Union, "Recommendation
+ ITU-T X.690 (2002) | ISO/IEC 8825-1:2002, Information
+ technology - ASN.1 encoding rules: Specification of Basic
+ Encoding Rules (BER), Canonical Encoding Rules (CER) and
+ Distinguished Encoding Rules (DER)", July 2002.
+
+13.2. Informative References
+
+ [I-D.dukhovni-opportunistic-security]
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 32]
+\f
+Internet-Draft SMTP security via opportunistic DANE TLS August 2014
+
+
+ Dukhovni, V., "Opportunistic Security: Some Protection
+ Most of the Time", draft-dukhovni-opportunistic-
+ security-03 (work in progress), August 2014.
+
+ [I-D.ietf-dane-srv]
+ Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-
+ Based Authentication of Named Entities (DANE) TLSA Records
+ with SRV Records", draft-ietf-dane-srv-07 (work in
+ progress), July 2014.
+
+ [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July
+ 2009.
+
+ [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",
+ STD 72, RFC 6409, November 2011.
+
+Authors' Addresses
+
+ Viktor Dukhovni
+ Two Sigma
+
+ Email: ietf-dane@dukhovni.org
+
+
+ Wes Hardaker
+ Parsons
+ P.O. Box 382
+ Davis, CA 95617
+ US
+
+ Email: ietf@hardakers.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dukhovni & Hardaker Expires February 18, 2015 [Page 33]
the next hop does not support DSN.
Adding it to a redirect router makes no difference.
+
Certificate name checking
--------------------------------------------------------------
The X509 certificates used for TLS are supposed be verified
component FQDN).
+DANE
+------------------------------------------------------------
+DNS-based Authentication of Named Entities, as applied
+to SMTP over TLS, provides assurance to a client that
+it is actually talking to the server it wants to rather
+than some attacker operating a Man In The Middle (MITM)
+operation. The latter can terminate the TLS connection
+you make, and make another one to the server (so both
+you and the server still think you have an encrypted
+connection) and, if one of the "well known" set of
+Certificate Authorities has been suborned - something
+which *has* been seen already (2014), a verifiable
+certificate (if you're using normal root CAs, eg. the
+Mozilla set, as your trust anchors).
+
+What DANE does is replace the CAs with the DNS as the
+trust anchor. The assurance is limited to a) the possibility
+that the DNS has been suborned, b) mistakes made by the
+admins of the target server. The attack surface presented
+by (a) is thought to be smaller than that of the set
+of root CAs.
+
+DANE scales better than having to maintain (and
+side-channel communicate) copies of server certificates
+for every possible target server. It also scales
+(slightly) better than having to maintain on an SMTP
+client a copy of the standard CAs bundle. It also
+means not having to pay a CA for certificates.
+
+DANE requires a server operator to do three things:
+1) run DNSSEC. This provides assurance to clients
+that DNS lookups they do for the server have not
+been tampered with. The domain MX record applying
+to this server, its A record, its TLSA record and
+any associated CNAME records must all be covered by
+DNSSEC.
+2) add TLSA DNS records. These say what the server
+certificate for a TLS connection should be.
+3) offer a server certificate, or certificate chain,
+in TLS connections which is traceable to the one
+defined by (one of?) the TSLA records
+
+There are no changes to Exim specific to server-side
+operation of DANE.
+
+The TLSA record for the server may have "certificate
+usage" of DANE_TA(2) or DANE_EE(3). The latter specifies
+the End Entity directly, i.e. the certificate involved
+is that of the server (and should be the sole one transmitted
+during the TLS handshake); this is appropriate for a
+single system, using a self-signed certificate.
+ DANE_TA usage is effectively declaring a specific CA
+to be used; this might be a private CA or a public,
+well-known one. A private CA at simplest is just
+a self-signed certificate which is used to sign
+cerver certificates, but running one securely does
+require careful arrangement. If a private CA is used
+then either all clients must be primed with it, or
+(probably simpler) the server TLS handshake must transmit
+the entire certificate chain from CA to server-certificate.
+If a public CA is used then all clients must be primed with it
+(losing one advantage of DANE) - but the attack surface is
+reduced from all public CAs to that single CA.
+DANE_TA is commonly used for several services and/or
+servers, each having a TLSA query-domain CNAME record,
+all of which point to a single TLSA record.
+
+The TLSA record should have a Selector field of SPKI(1)
+and a Matching Type field of SHA2-512(2).
+
+At the time of writing, https://www.huque.com/bin/gen_tlsa
+is useful for quickly generating TLSA records; and commands like
+
+ openssl x509 -in -pubkey -noout <certificate.pem \
+ | openssl rsa -outform der -pubin 2>/dev/null \
+ | openssl sha512 \
+ | awk '{print $2}'
+
+are workable for 4th-field hashes.
+
+For use with the DANE_TA model, server certificates
+must have a correct name (SubjectName or SubjectAltName).
+
+The use of OCSP-stapling should be considered, allowing
+for fast revocation of certificates (which would otherwise
+be limited by the DNS TTL on the TLSA records). However,
+this is likely to only be usable with DANE_TA. NOTE: the
+default of requesting OCSP for all hosts is modified iff
+DANE is in use, to:
+
+ hosts_request_ocsp = ${if or { {= {0}{$tls_out_tlsa_usage}} \
+ {= {4}{$tls_out_tlsa_usage}} } \
+ {*}{}}
+
+The (new) variable $tls_out_tlsa_usage is a bitfield with
+numbered bits set for TLSA record usage codes.
+The zero above means DANE was not in use,
+the four means that only DANE_TA usage TLSA records were
+found. If the definition of hosts_require_ocsp or
+hosts_request_ocsp includes the string "tls_out_tlsa_usage",
+they are re-expanded in time to control the OCSP request.
+
+This modification of hosts_request_ocsp is only done if
+it has the default value of "*". Admins who change it, and
+those who use hosts_require_ocsp, should consider the interaction
+with DANE in their OCSP settings.
+
+
+For client-side DANE there are two new smtp transport options,
+hosts_try_dane and hosts_require_dane. They do the obvious thing.
+[ should they be domain-based rather than host-based? ]
+
+DANE will only be usable if the target host has DNSSEC-secured
+MX, A and TLSA records.
+
+(TODO: specify when fallback happens vs. when the host is not used)
+
+If dane is in use the following transport options are ignored:
+ tls_verify_hosts
+ tls_try_verify_hosts
+ tls_verify_certificates
+ tls_crl
+ tls_verify_cert_hostnames
+
+Currently dnssec_request_domains must be active (need to think about that)
+and dnssec_require_domains is ignored.
+
+If verification was successful using DANE then the "CV" item
+in the delivery log line will show as "CV=dane".
+
+There is a new variable $tls_out_dane which will have "yes" if
+verification succeeded using DANE and "no" otherwise (only useful
+in combination with EXPERIMENTAL_TPDA), and a new variable
+$tls_out_tlsa_usage (detailed above).
+
--------------------------------------------------------------
End of file
--- /dev/null
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) P. Hoffman
+Request for Comments: 6698 VPN Consortium
+Category: Standards Track J. Schlyter
+ISSN: 2070-1721 Kirei AB
+ August 2012
+
+
+ The DNS-Based Authentication of Named Entities (DANE)
+ Transport Layer Security (TLS) Protocol: TLSA
+
+Abstract
+
+ Encrypted communication on the Internet often uses Transport Layer
+ Security (TLS), which depends on third parties to certify the keys
+ used. This document improves on that situation by enabling the
+ administrators of domain names to specify the keys used in that
+ domain's TLS servers. This requires matching improvements in TLS
+ client software, but no change in TLS server software.
+
+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/rfc6698.
+
+Copyright Notice
+
+ Copyright (c) 2012 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.
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 1]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Background and Motivation ..................................3
+ 1.2. Securing the Association of a Domain Name with a
+ Server's Certificate .......................................4
+ 1.3. Method for Securing Certificate Associations ...............5
+ 1.4. Terminology ................................................6
+ 2. The TLSA Resource Record ........................................7
+ 2.1. TLSA RDATA Wire Format .....................................7
+ 2.1.1. The Certificate Usage Field .........................7
+ 2.1.2. The Selector Field ..................................8
+ 2.1.3. The Matching Type Field .............................9
+ 2.1.4. The Certificate Association Data Field ..............9
+ 2.2. TLSA RR Presentation Format ................................9
+ 2.3. TLSA RR Examples ..........................................10
+ 3. Domain Names for TLSA Certificate Associations .................10
+ 4. Use of TLSA Records in TLS .....................................11
+ 4.1. Usable Certificate Associations ...........................11
+ 5. TLSA and DANE Use Cases and Requirements .......................13
+ 6. Mandatory-to-Implement Features ................................15
+ 7. IANA Considerations ............................................15
+ 7.1. TLSA RRtype ...............................................15
+ 7.2. TLSA Certificate Usages ...................................15
+ 7.3. TLSA Selectors ............................................16
+ 7.4. TLSA Matching Types .......................................16
+ 8. Security Considerations ........................................16
+ 8.1. Comparing DANE to Public CAs ..............................18
+ 8.1.1. Risk of Key Compromise .............................19
+ 8.1.2. Impact of Key Compromise ...........................20
+ 8.1.3. Detection of Key Compromise ........................20
+ 8.1.4. Spoofing Hostnames .................................20
+ 8.2. DNS Caching ...............................................21
+ 8.3. External DNSSEC Validators ................................21
+ 9. Acknowledgements ...............................................22
+ 10. References ....................................................22
+ 10.1. Normative References .....................................22
+ 10.2. Informative References ...................................23
+ Appendix A. Operational Considerations for Deploying TLSA
+ Records ...............................................25
+ A.1. Creating TLSA Records ......................................25
+ A.1.1. Ambiguities and Corner Cases When TLS Clients
+ Build Trust Chains .....................................26
+ A.1.2. Choosing a Selector Type ...............................26
+ A.2. Provisioning TLSA Records in DNS ...........................28
+ A.2.1. Provisioning TLSA Records with Aliases .................28
+ A.3. Securing the Last Hop ......................................30
+ A.4. Handling Certificate Rollover ..............................31
+
+
+
+Hoffman & Schlyter Standards Track [Page 2]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ Appendix B. Pseudocode for Using TLSA .............................32
+ B.1. Helper Functions ...........................................32
+ B.2. Main TLSA Pseudocode .......................................33
+ Appendix C. Examples ..............................................35
+
+1. Introduction
+
+1.1. Background and Motivation
+
+ Applications that communicate over the Internet often need to prevent
+ eavesdropping, tampering, or forgery of their communications. The
+ Transport Layer Security (TLS) protocol provides this kind of
+ communications security over the Internet, using channel encryption.
+
+ The security properties of encryption systems depend strongly on the
+ keys that they use. If secret keys are revealed, or if public keys
+ can be replaced by fake keys (that is, a key not corresponding to the
+ entity identified in the certificate), these systems provide little
+ or no security.
+
+ TLS uses certificates to bind keys and names. A certificate combines
+ a published key with other information such as the name of the
+ service that uses the key, and this combination is digitally signed
+ by another key. Having a key in a certificate is only helpful if one
+ trusts the other key that signed the certificate. If that other key
+ was itself revealed or substituted, then its signature is worthless
+ in proving anything about the first key.
+
+ On the Internet, this problem has been solved for years by entities
+ called "Certification Authorities" (CAs). CAs protect their secret
+ key vigorously, while supplying their public key to the software
+ vendors who build TLS clients. They then sign certificates, and
+ supply those to TLS servers. TLS client software uses a set of these
+ CA keys as "trust anchors" to validate the signatures on certificates
+ that the client receives from TLS servers. Client software typically
+ allows any CA to usefully sign any other certificate.
+
+ The public CA model upon which TLS has depended is fundamentally
+ vulnerable because it allows any of these CAs to issue a certificate
+ for any domain name. A single trusted CA that betrays its trust,
+ either voluntarily or by providing less-than-vigorous protection for
+ its secrets and capabilities, can undermine the security offered by
+ any certificates employed with TLS. This problem arises because a
+ compromised CA can issue a replacement certificate that contains a
+ fake key. Recent experiences with compromises of CAs or their
+ trusted partners have led to very serious security problems, such as
+ the governments of multiple countries attempting to wiretap and/or
+ subvert major TLS-protected web sites trusted by millions of users.
+
+
+
+Hoffman & Schlyter Standards Track [Page 3]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ The DNS Security Extensions (DNSSEC) provide a similar model that
+ involves trusted keys signing the information for untrusted keys.
+ However, DNSSEC provides three significant improvements. Keys are
+ tied to names in the Domain Name System (DNS), rather than to
+ arbitrary identifying strings; this is more convenient for Internet
+ protocols. Signed keys for any domain are accessible online through
+ a straightforward query using the standard DNSSEC protocol, so there
+ is no problem distributing the signed keys. Most significantly, the
+ keys associated with a domain name can only be signed by a key
+ associated with the parent of that domain name; for example, the keys
+ for "example.com" can only be signed by the keys for "com", and the
+ keys for "com" can only be signed by the DNS root. This prevents an
+ untrustworthy signer from compromising anyone's keys except those in
+ their own subdomains. Like TLS, DNSSEC relies on public keys that
+ come built into the DNSSEC client software, but these keys come only
+ from a single root domain rather than from a multiplicity of CAs.
+
+ DNS-Based Authentication of Named Entities (DANE) offers the option
+ to use the DNSSEC infrastructure to store and sign keys and
+ certificates that are used by TLS. DANE is envisioned as a
+ preferable basis for binding public keys to DNS names, because the
+ entities that vouch for the binding of public key data to DNS names
+ are the same entities responsible for managing the DNS names in
+ question. While the resulting system still has residual security
+ vulnerabilities, it restricts the scope of assertions that can be
+ made by any entity, consistent with the naming scope imposed by the
+ DNS hierarchy. As a result, DANE embodies the security "principle of
+ least privilege" that is lacking in the current public CA model.
+
+1.2. Securing the Association of a Domain Name with a Server's
+ Certificate
+
+ A TLS client begins a connection by exchanging messages with a TLS
+ server. For many application protocols, it looks up the server's
+ name using the DNS to get an Internet Protocol (IP) address
+ associated with the name. It then begins a connection to a
+ particular port at that address, and sends an initial message there.
+ However, the client does not yet know whether an adversary is
+ intercepting and/or altering its communication before it reaches the
+ TLS server. It does not even know whether the real TLS server
+ associated with that domain name has ever received its initial
+ messages.
+
+ The first response from the server in TLS may contain a certificate.
+ In order for the TLS client to authenticate that it is talking to the
+ expected TLS server, the client must validate that this certificate
+ is associated with the domain name used by the client to get to the
+ server. Currently, the client must extract the domain name from the
+
+
+
+Hoffman & Schlyter Standards Track [Page 4]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ certificate and must successfully validate the certificate, including
+ chaining to a trust anchor.
+
+ There is a different way to authenticate the association of the
+ server's certificate with the intended domain name without trusting
+ an external CA. Given that the DNS administrator for a domain name
+ is authorized to give identifying information about the zone, it
+ makes sense to allow that administrator to also make an authoritative
+ binding between the domain name and a certificate that might be used
+ by a host at that domain name. The easiest way to do this is to use
+ the DNS, securing the binding with DNSSEC.
+
+ There are many use cases for such functionality. [RFC6394] lists the
+ ones to which the DNS RRtype in this document apply. [RFC6394] also
+ lists many requirements, most of which this document is believed to
+ meet. Section 5 covers the applicability of this document to the use
+ cases in detail. The protocol in this document can generally be
+ referred to as the "DANE TLSA" protocol. ("TLSA" does not stand for
+ anything; it is just the name of the RRtype.)
+
+ This document applies to both TLS [RFC5246] and Datagram TLS (DTLS)
+ [RFC6347]. In order to make the document more readable, it mostly
+ only talks about "TLS", but in all cases, it means "TLS or DTLS".
+ Although the references in this paragraph are to TLS and DTLS
+ version 1.2, the DANE TLSA protocol can also be used with earlier
+ versions of TLS and DTLS.
+
+ This document only relates to securely associating certificates for
+ TLS and DTLS with host names; retrieving certificates from DNS for
+ other protocols is handled in other documents. For example, keys for
+ IPsec are covered in [RFC4025], and keys for Secure SHell (SSH) are
+ covered in [RFC4255].
+
+1.3. Method for Securing Certificate Associations
+
+ A certificate association is formed from a piece of information
+ identifying a certificate and the domain name where the server
+ application runs. The combination of a trust anchor and a domain
+ name can also be a certificate association.
+
+ A DNS query can return multiple certificate associations, such as in
+ the case of a server that is changing from one certificate to another
+ (described in more detail in Appendix A.4).
+
+ This document only applies to PKIX [RFC5280] certificates, not
+ certificates of other formats.
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 5]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ This document defines a secure method to associate the certificate
+ that is obtained from the TLS server with a domain name using DNS;
+ the DNS information needs to be protected by DNSSEC. Because the
+ certificate association was retrieved based on a DNS query, the
+ domain name in the query is by definition associated with the
+ certificate. Note that this document does not cover how to associate
+ certificates with domain names for application protocols that depend
+ on SRV, NAPTR, and similar DNS resource records. It is expected that
+ future documents will cover methods for making those associations,
+ and those documents may or may not need to update this one.
+
+ DNSSEC, which is defined in [RFC4033], [RFC4034], and [RFC4035], uses
+ cryptographic keys and digital signatures to provide authentication
+ of DNS data. Information that is retrieved from the DNS and that is
+ validated using DNSSEC is thereby proved to be the authoritative
+ data. The DNSSEC signature needs to be validated on all responses
+ that use DNSSEC in order to assure the proof of origin of the data.
+
+ This document does not specify how DNSSEC validation occurs because
+ there are many different proposals for how a client might get
+ validated DNSSEC results, such as from a DNSSEC-aware resolver that
+ is coded in the application, from a trusted DNSSEC resolver on the
+ machine on which the application is running, or from a trusted DNSSEC
+ resolver with which the application is communicating over an
+ authenticated and integrity-protected channel or network. This is
+ described in more detail in Section 7 of [RFC4033].
+
+ This document only relates to getting the DNS information for the
+ certificate association securely using DNSSEC; other secure DNS
+ mechanisms are out of scope.
+
+1.4. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+ This document also makes use of standard PKIX, DNSSEC, TLS, and DNS
+ terminology. See [RFC5280], [RFC4033], [RFC5246], and STD 13
+ [RFC1034] [RFC1035], respectively, for these terms. In addition,
+ terms related to TLS-protected application services and DNS names are
+ taken from [RFC6125].
+
+
+
+
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 6]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+2. The TLSA Resource Record
+
+ The TLSA DNS resource record (RR) is used to associate a TLS server
+ certificate or public key with the domain name where the record is
+ found, thus forming a "TLSA certificate association". The semantics
+ of how the TLSA RR is interpreted are given later in this document.
+
+ The type value for the TLSA RR type is defined in Section 7.1.
+
+ The TLSA RR is class independent.
+
+ The TLSA RR has no special Time to Live (TTL) requirements.
+
+2.1. TLSA RDATA Wire Format
+
+ The RDATA for a TLSA RR consists of a one-octet certificate usage
+ field, a one-octet selector field, a one-octet matching type field,
+ and the certificate association data field.
+
+ 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Cert. Usage | Selector | Matching Type | /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
+ / /
+ / Certificate Association Data /
+ / /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+2.1.1. The Certificate Usage Field
+
+ A one-octet value, called "certificate usage", specifies the provided
+ association that will be used to match the certificate presented in
+ the TLS handshake. This value is defined in a new IANA registry (see
+ Section 7.2) in order to make it easier to add additional certificate
+ usages in the future. The certificate usages defined in this
+ document are:
+
+ 0 -- Certificate usage 0 is used to specify a CA certificate, or
+ the public key of such a certificate, that MUST be found in any of
+ the PKIX certification paths for the end entity certificate given
+ by the server in TLS. This certificate usage is sometimes
+ referred to as "CA constraint" because it limits which CA can be
+ used to issue certificates for a given service on a host. The
+ presented certificate MUST pass PKIX certification path
+ validation, and a CA certificate that matches the TLSA record MUST
+ be included as part of a valid certification path. Because this
+ certificate usage allows both trust anchors and CA certificates,
+
+
+
+Hoffman & Schlyter Standards Track [Page 7]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ the certificate might or might not have the basicConstraints
+ extension present.
+
+ 1 -- Certificate usage 1 is used to specify an end entity
+ certificate, or the public key of such a certificate, that MUST be
+ matched with the end entity certificate given by the server in
+ TLS. This certificate usage is sometimes referred to as "service
+ certificate constraint" because it limits which end entity
+ certificate can be used by a given service on a host. The target
+ certificate MUST pass PKIX certification path validation and MUST
+ match the TLSA record.
+
+ 2 -- Certificate usage 2 is used to specify a certificate, or the
+ public key of such a certificate, that MUST be used as the trust
+ anchor when validating the end entity certificate given by the
+ server in TLS. This certificate usage is sometimes referred to as
+ "trust anchor assertion" and allows a domain name administrator to
+ specify a new trust anchor -- for example, if the domain issues
+ its own certificates under its own CA that is not expected to be
+ in the end users' collection of trust anchors. The target
+ certificate MUST pass PKIX certification path validation, with any
+ certificate matching the TLSA record considered to be a trust
+ anchor for this certification path validation.
+
+ 3 -- Certificate usage 3 is used to specify a certificate, or the
+ public key of such a certificate, that MUST match the end entity
+ certificate given by the server in TLS. This certificate usage is
+ sometimes referred to as "domain-issued certificate" because it
+ allows for a domain name administrator to issue certificates for a
+ domain without involving a third-party CA. The target certificate
+ MUST match the TLSA record. The difference between certificate
+ usage 1 and certificate usage 3 is that certificate usage 1
+ requires that the certificate pass PKIX validation, but PKIX
+ validation is not tested for certificate usage 3.
+
+ The certificate usages defined in this document explicitly only apply
+ to PKIX-formatted certificates in DER encoding [X.690]. If TLS
+ allows other formats later, or if extensions to this RRtype are made
+ that accept other formats for certificates, those certificates will
+ need their own certificate usage values.
+
+2.1.2. The Selector Field
+
+ A one-octet value, called "selector", specifies which part of the TLS
+ certificate presented by the server will be matched against the
+ association data. This value is defined in a new IANA registry (see
+ Section 7.3). The selectors defined in this document are:
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 8]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ 0 -- Full certificate: the Certificate binary structure as defined
+ in [RFC5280]
+
+ 1 -- SubjectPublicKeyInfo: DER-encoded binary structure as defined
+ in [RFC5280]
+
+ (Note that the use of "selector" in this document is completely
+ unrelated to the use of "selector" in DomainKeys Identified Mail
+ (DKIM) [RFC6376].)
+
+2.1.3. The Matching Type Field
+
+ A one-octet value, called "matching type", specifies how the
+ certificate association is presented. This value is defined in a new
+ IANA registry (see Section 7.4). The types defined in this document
+ are:
+
+ 0 -- Exact match on selected content
+
+ 1 -- SHA-256 hash of selected content [RFC6234]
+
+ 2 -- SHA-512 hash of selected content [RFC6234]
+
+ If the TLSA record's matching type is a hash, having the record use
+ the same hash algorithm that was used in the signature in the
+ certificate (if possible) will assist clients that support a small
+ number of hash algorithms.
+
+2.1.4. The Certificate Association Data Field
+
+ This field specifies the "certificate association data" to be
+ matched. These bytes are either raw data (that is, the full
+ certificate or its SubjectPublicKeyInfo, depending on the selector)
+ for matching type 0, or the hash of the raw data for matching types 1
+ and 2. The data refers to the certificate in the association, not to
+ the TLS ASN.1 Certificate object.
+
+2.2. TLSA RR Presentation Format
+
+ The presentation format of the RDATA portion (as defined in
+ [RFC1035]) is as follows:
+
+ o The certificate usage field MUST be represented as an 8-bit
+ unsigned integer.
+
+ o The selector field MUST be represented as an 8-bit unsigned
+ integer.
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 9]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ o The matching type field MUST be represented as an 8-bit unsigned
+ integer.
+
+ o The certificate association data field MUST be represented as a
+ string of hexadecimal characters. Whitespace is allowed within
+ the string of hexadecimal characters, as described in [RFC1035].
+
+2.3. TLSA RR Examples
+
+ In the following examples, the domain name is formed using the rules
+ in Section 3.
+
+ An example of a hashed (SHA-256) association of a PKIX CA
+ certificate:
+
+ _443._tcp.www.example.com. IN TLSA (
+ 0 0 1 d2abde240d7cd3ee6b4b28c54df034b9
+ 7983a1d16e8a410e4561cb106618e971 )
+
+ An example of a hashed (SHA-512) subject public key association of a
+ PKIX end entity certificate:
+
+ _443._tcp.www.example.com. IN TLSA (
+ 1 1 2 92003ba34942dc74152e2f2c408d29ec
+ a5a520e7f2e06bb944f4dca346baf63c
+ 1b177615d466f6c4b71c216a50292bd5
+ 8c9ebdd2f74e38fe51ffd48c43326cbc )
+
+ An example of a full certificate association of a PKIX end entity
+ certificate:
+
+ _443._tcp.www.example.com. IN TLSA (
+ 3 0 0 30820307308201efa003020102020... )
+
+3. Domain Names for TLSA Certificate Associations
+
+ Unless there is a protocol-specific specification that is different
+ than this one, TLSA resource records are stored at a prefixed DNS
+ domain name. The prefix is prepared in the following manner:
+
+ 1. The decimal representation of the port number on which a TLS-
+ based service is assumed to exist is prepended with an underscore
+ character ("_") to become the left-most label in the prepared
+ domain name. This number has no leading zeros.
+
+
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 10]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ 2. The protocol name of the transport on which a TLS-based service
+ is assumed to exist is prepended with an underscore character
+ ("_") to become the second left-most label in the prepared domain
+ name. The transport names defined for this protocol are "tcp",
+ "udp", and "sctp".
+
+ 3. The base domain name is appended to the result of step 2 to
+ complete the prepared domain name. The base domain name is the
+ fully qualified DNS domain name [RFC1035] of the TLS server, with
+ the additional restriction that every label MUST meet the rules
+ of [RFC0952]. The latter restriction means that, if the query is
+ for an internationalized domain name, it MUST use the A-label
+ form as defined in [RFC5890].
+
+ For example, to request a TLSA resource record for an HTTP server
+ running TLS on port 443 at "www.example.com",
+ "_443._tcp.www.example.com" is used in the request. To request a
+ TLSA resource record for an SMTP server running the STARTTLS protocol
+ on port 25 at "mail.example.com", "_25._tcp.mail.example.com" is
+ used.
+
+4. Use of TLSA Records in TLS
+
+ Section 2.1 of this document defines the mandatory matching rules for
+ the data from the TLSA certificate associations and the certificates
+ received from the TLS server.
+
+ The TLS session that is to be set up MUST be for the specific port
+ number and transport name that was given in the TLSA query.
+
+ Some specifications for applications that run over TLS, such as
+ [RFC2818] for HTTP, require that the server's certificate have a
+ domain name that matches the host name expected by the client. Some
+ specifications, such as [RFC6125], detail how to match the identity
+ given in a PKIX certificate with those expected by the user.
+
+ If a TLSA record has certificate usage 2, the corresponding TLS
+ server SHOULD send the certificate that is referenced just like it
+ currently sends intermediate certificates.
+
+4.1. Usable Certificate Associations
+
+ An implementation of this protocol makes a DNS query for TLSA
+ records, validates these records using DNSSEC, and uses the resulting
+ TLSA records and validation status to modify its responses to the TLS
+ server.
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 11]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ Determining whether a TLSA RRSet can be used MUST be based on the
+ DNSSEC validation state (as defined in [RFC4033]).
+
+ o A TLSA RRSet whose DNSSEC validation state is secure MUST be used
+ as a certificate association for TLS unless a local policy would
+ prohibit the use of the specific certificate association in the
+ secure TLSA RRSet.
+
+ o If the DNSSEC validation state on the response to the request for
+ the TLSA RRSet is bogus, this MUST cause TLS not to be started or,
+ if the TLS negotiation is already in progress, MUST cause the
+ connection to be aborted.
+
+ o A TLSA RRSet whose DNSSEC validation state is indeterminate or
+ insecure cannot be used for TLS and MUST be considered unusable.
+
+ Clients that validate the DNSSEC signatures themselves MUST use
+ standard DNSSEC validation procedures. Clients that rely on another
+ entity to perform the DNSSEC signature validation MUST use a secure
+ mechanism between themselves and the validator. Examples of secure
+ transports to other hosts include TSIG [RFC2845], SIG(0) [RFC2931],
+ and IPsec [RFC6071]. Note that it is not sufficient to use secure
+ transport to a DNS resolver that does not do DNSSEC signature
+ validation. See Section 8.3 for more security considerations related
+ to external validators.
+
+ If a certificate association contains a certificate usage, selector,
+ or matching type that is not understood by the TLS client, that
+ certificate association MUST be considered unusable. If the
+ comparison data for a certificate is malformed, the certificate
+ association MUST be considered unusable.
+
+ If a certificate association contains a matching type or certificate
+ association data that uses a cryptographic algorithm that is
+ considered too weak for the TLS client's policy, the certificate
+ association MUST be considered unusable.
+
+ If an application receives zero usable certificate associations from
+ a DNS request or from its cache, it processes TLS in the normal
+ fashion without any input from the TLSA records. If an application
+ receives one or more usable certificate associations, it attempts to
+ match each certificate association with the TLS server's end entity
+ certificate until a successful match is found. During the TLS
+ handshake, if none of the certificate associations matches the
+ certificate given by the TLS server, the TLS client MUST abort the
+ handshake.
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 12]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ An attacker who is able to divert a user to a server under his
+ control is also likely to be able to block DNS requests from the user
+ or DNS responses being sent to the user. Thus, in order to achieve
+ any security benefit from certificate usage 0 or 1, an application
+ that sends a request for TLSA records needs to get either a valid
+ signed response containing TLSA records or verification that the
+ domain is insecure or indeterminate. If a request for a TLSA record
+ does not meet one of those two criteria but the application continues
+ with the TLS handshake anyway, the application has gotten no benefit
+ from TLSA and SHOULD NOT make any internal or external indication
+ that TLSA was applied. If an application has a configuration setting
+ that has turned on TLSA use, or has any indication that TLSA is in
+ use (regardless of whether or not this is configurable), that
+ application either MUST NOT start a TLS connection or it MUST abort a
+ TLS handshake if both of the two criteria above are not met.
+
+ The application can perform the TLSA lookup before initiating the TLS
+ handshake, or do it during the TLS handshake: the choice is up to the
+ client.
+
+5. TLSA and DANE Use Cases and Requirements
+
+ The different types of certificate associations defined in TLSA are
+ matched with various sections of [RFC6394]. The use cases from
+ Section 3 of [RFC6394] are covered in this document as follows:
+
+ 3.1 CA Constraints -- Implemented using certificate usage 0.
+
+ 3.2 Certificate Constraints -- Implemented using certificate usage 1.
+
+ 3.3 Trust Anchor Assertion and Domain-Issued Certificates --
+ Implemented using certificate usages 2 and 3, respectively.
+
+ The requirements from Section 4 of [RFC6394] are covered in this
+ document as follows:
+
+ Multiple Ports -- The TLSA records for different application services
+ running on a single host can be distinguished through the service
+ name and port number prefixed to the host name (see Section 3).
+
+ No Downgrade -- Section 4 specifies the conditions under which a
+ client can process and act upon TLSA records. Specifically, if
+ the DNSSEC status for the TLSA resource record set is determined
+ to be bogus, the TLS connection (if started) will fail.
+
+ Encapsulation -- Encapsulation is covered in the TLSA response
+ semantics.
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 13]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ Predictability -- The appendices of this specification provide
+ operational considerations and implementation guidance in order to
+ enable application developers to form a consistent interpretation
+ of the recommended client behavior.
+
+ Opportunistic Security -- If a client conformant to this
+ specification can reliably determine the presence of a TLSA
+ record, it will attempt to use this information. Conversely, if a
+ client can reliably determine the absence of any TLSA record, it
+ will fall back to processing TLS in the normal fashion. This is
+ discussed in Section 4.
+
+ Combination -- Multiple TLSA records can be published for a given
+ host name, thus enabling the client to construct multiple TLSA
+ certificate associations that reflect different assertions. No
+ support is provided to combine two TLSA certificate associations
+ in a single operation.
+
+ Roll-over -- TLSA records are processed in the normal manner within
+ the scope of the DNS protocol, including the TTL expiration of the
+ records. This ensures that clients will not latch onto assertions
+ made by expired TLSA records, and will be able to transition from
+ using one public key or certificate usage to another.
+
+ Simple Key Management -- The SubjectPublicKeyInfo selector in the
+ TLSA record provides a mode that enables a domain holder to only
+ have to maintain a single long-lived public/private key pair
+ without the need to manage certificates. Appendix A outlines the
+ usefulness and the potential downsides to using this mode.
+
+ Minimal Dependencies -- This specification relies on DNSSEC to
+ protect the origin authenticity and integrity of the TLSA resource
+ record set. Additionally, if DNSSEC validation is not performed
+ on the system that wishes to use TLSA certificate bindings, this
+ specification requires that the "last mile" be over a secure
+ transport. There are no other deployment dependencies for this
+ approach.
+
+ Minimal Options -- The operating modes map precisely to the DANE use
+ cases and requirements. DNSSEC use is mandatory in that this
+ specification encourages applications to use only those TLSA
+ records that are shown to be validated.
+
+ Wildcards -- Wildcards are covered in a limited manner in the TLSA
+ request syntax; see Appendix A.
+
+ Redirection -- Redirection is covered in the TLSA request syntax; see
+ Appendix A.
+
+
+
+Hoffman & Schlyter Standards Track [Page 14]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+6. Mandatory-to-Implement Features
+
+ TLS clients conforming to this specification MUST be able to
+ correctly interpret TLSA records with certificate usages 0, 1, 2,
+ and 3. TLS clients conforming to this specification MUST be able to
+ compare a certificate association with a certificate from the TLS
+ handshake using selector types 0 and 1, and matching type 0 (no hash
+ used) and matching type 1 (SHA-256), and SHOULD be able to make such
+ comparisons with matching type 2 (SHA-512).
+
+7. IANA Considerations
+
+ IANA has made the assignments in this section.
+
+ In the following sections, "RFC Required" was chosen for TLSA
+ certificate usages and "Specification Required" for selectors and
+ matching types because of the amount of detail that is likely to be
+ needed for implementers to correctly implement new certificate usages
+ as compared to new selectors and matching types.
+
+7.1. TLSA RRtype
+
+ This document uses a new DNS RR type, TLSA, whose value (52) was
+ allocated by IANA from the Resource Record (RR) TYPEs subregistry of
+ the Domain Name System (DNS) Parameters registry.
+
+7.2. TLSA Certificate Usages
+
+ This document creates a new registry, "TLSA Certificate Usages". The
+ registry policy is "RFC Required". The initial entries in the
+ registry are:
+
+ Value Short description Reference
+ ----------------------------------------------------------
+ 0 CA constraint RFC 6698
+ 1 Service certificate constraint RFC 6698
+ 2 Trust anchor assertion RFC 6698
+ 3 Domain-issued certificate RFC 6698
+ 4-254 Unassigned
+ 255 Private use
+
+ Applications to the registry can request specific values that have
+ yet to be assigned.
+
+
+
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 15]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+7.3. TLSA Selectors
+
+ This document creates a new registry, "TLSA Selectors". The registry
+ policy is "Specification Required". The initial entries in the
+ registry are:
+
+ Value Short description Reference
+ ----------------------------------------------------------
+ 0 Full certificate RFC 6698
+ 1 SubjectPublicKeyInfo RFC 6698
+ 2-254 Unassigned
+ 255 Private use
+
+ Applications to the registry can request specific values that have
+ yet to be assigned.
+
+7.4. TLSA Matching Types
+
+ This document creates a new registry, "TLSA Matching Types". The
+ registry policy is "Specification Required". The initial entries in
+ the registry are:
+
+ Value Short description Reference
+ ----------------------------------------------------------
+ 0 No hash used RFC 6698
+ 1 SHA-256 RFC 6234
+ 2 SHA-512 RFC 6234
+ 3-254 Unassigned
+ 255 Private use
+
+ Applications to the registry can request specific values that have
+ yet to be assigned.
+
+8. Security Considerations
+
+ The security of the DNS RRtype described in this document relies on
+ the security of DNSSEC to verify that the TLSA record has not been
+ altered.
+
+ A rogue DNS administrator who changes the A, AAAA, and/or TLSA
+ records for a domain name can cause the client to go to an
+ unauthorized server that will appear authorized, unless the client
+ performs PKIX certification path validation and rejects the
+ certificate. That administrator could probably get a certificate
+ issued by some CA anyway, so this is not an additional threat.
+
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 16]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ If the authentication mechanism for adding or changing TLSA data in a
+ zone is weaker than the authentication mechanism for changing the A
+ and/or AAAA records, a man-in-the-middle who can redirect traffic to
+ his site may be able to impersonate the attacked host in TLS if he
+ can use the weaker authentication mechanism. A better design for
+ authenticating DNS would be to have the same level of authentication
+ used for all DNS additions and changes for a particular domain name.
+
+ Secure Socket Layer (SSL) proxies can sometimes act as a man-in-the-
+ middle for TLS clients. In these scenarios, the clients add a new
+ trust anchor whose private key is kept on the SSL proxy; the proxy
+ intercepts TLS requests, creates a new TLS session with the intended
+ host, and sets up a TLS session with the client using a certificate
+ that chains to the trust anchor installed in the client by the proxy.
+ In such environments, using TLSA records will prevent the SSL proxy
+ from functioning as expected because the TLS client will get a
+ certificate association from the DNS that will not match the
+ certificate that the SSL proxy uses with the client. The client,
+ seeing the proxy's new certificate for the supposed destination, will
+ not set up a TLS session.
+
+ Client treatment of any information included in the trust anchor is a
+ matter of local policy. This specification does not mandate that
+ such information be inspected or validated by the server's domain
+ name administrator.
+
+ If a server's certificate is revoked, or if an intermediate CA in a
+ chain between the server and a trust anchor has its certificate
+ revoked, a TLSA record with a certificate usage of 2 that matches the
+ revoked certificate would in essence override the revocation because
+ the client would treat that revoked certificate as a trust anchor and
+ thus not check its revocation status. Because of this, domain
+ administrators need to be responsible for being sure that the keys or
+ certificates used in TLSA records with a certificate usage of 2 are
+ in fact able to be used as reliable trust anchors.
+
+ Certificates that are delivered in TLSA with certificate usage 2
+ fundamentally change the way the TLS server's end entity certificate
+ is evaluated. For example, the server's certificate might chain to
+ an existing CA through an intermediate CA that has certain policy
+ restrictions, and the certificate would not pass those restrictions
+ and thus normally be rejected. That intermediate CA could issue
+ itself a new certificate without the policy restrictions and tell its
+ customers to use that certificate with certificate usage 2. This in
+ essence allows an intermediate CA to become a trust anchor for
+ certificates that the end user might have expected to chain to an
+ existing trust anchor.
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 17]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ If an administrator wishes to stop using a TLSA record, the
+ administrator can simply remove it from the DNS. Normal clients will
+ stop using the TLSA record after the TTL has expired. Replay attacks
+ against the TLSA record are not possible after the expiration date on
+ the RRsig of the TLSA record that was removed.
+
+ Generators of TLSA records should be aware that the client's full
+ trust of a certificate association retrieved from a TLSA record may
+ be a matter of local policy. While such trust is limited to the
+ specific domain name, protocol, and port for which the TLSA query was
+ made, local policy may decline to accept the certificate (for reasons
+ such as weak cryptography), as is also the case with PKIX trust
+ anchors.
+
+8.1. Comparing DANE to Public CAs
+
+ As stated above, the security of the DNS RRtype described in this
+ document relies on the security of DNSSEC to verify that the TLSA
+ record has not been altered. This section describes where the
+ security of public CAs and the security of TLSA are similar and
+ different. This section applies equally to other security-related
+ DNS RRtypes such as keys for IPsec and SSH.
+
+ DNSSEC forms certificates (the binding of an identity to a key) by
+ combining a DNSKEY, DS, or DLV resource record with an associated
+ RRSIG record. These records then form a signing chain extending from
+ the client's trust anchors to the RR of interest.
+
+ Although the DNSSEC protocol does not enforce it, DNSKEYs are often
+ marked with a SEP flag indicating whether the key is a Zone Signing
+ Key (ZSK) or a Key Signing Key (KSK). ZSKs protect records in the
+ zone (including DS and DLV records), and KSKs protect ZSK DNSKEY
+ records. This allows KSKs to be stored offline.
+
+ The TLSA RRtype allows keys from the DNSSEC PKI hierarchy to
+ authenticate keys wrapped in PKIX certificates for a particular host
+ name, protocol, and port.
+
+ With the exception of the DLV RRtype, all of these certificates
+ constrain the keys they identify to names that are within the zone
+ signing the certificate. In order for a domain's DLV resource
+ records to be honored, the domain must be configured as a DLV domain,
+ and the domain's DNSKEYs must be configured as trust anchors or be
+ authentic [RFC5074].
+
+
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 18]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+8.1.1. Risk of Key Compromise
+
+ The risk that a given certificate that has a valid signing chain is
+ fake is related to the number of keys that can contribute to the
+ validation of the certificate, the quality of protection each private
+ key receives, the value of each key to an attacker, and the value of
+ falsifying the certificate.
+
+ DNSSEC allows any set of domains to be configured as trust anchors
+ and/or DLVs, but most clients are likely to use the root zone as
+ their only trust anchor. Also, because a given DNSKEY can only sign
+ resource records for that zone, the number of private keys capable of
+ compromising a given TLSA resource record is limited to the number of
+ zones between the TLSA resource record and the nearest trust anchor,
+ plus any configured DLV domains. Typically, this will be six keys,
+ half of which will be KSKs.
+
+ PKIX only describes how to validate a certificate based on a client-
+ chosen set of trust anchors, but says nothing about how many trust
+ anchors to use or how they should be constrained. As currently
+ deployed, most PKIX clients use a large number of trust anchors
+ provided with the client or operating system software. These trust
+ anchors are selected carefully, but with a desire for broad
+ interoperability. The trust anchors and CA certificates for public
+ CAs rarely have name constraints applied.
+
+ A combination of technical protections, process controls, and
+ personnel experience contribute to the quality of security that keys
+ receive.
+
+ o The security surrounding DNSSEC DNSKEYs varies significantly. The
+ KSK/ZSK split allows the KSK to be stored offline and protected
+ more carefully than the ZSK, but not all domains do so. The
+ security applied to a zone's DNSKEYs should be proportional to the
+ value of the domain, but that is difficult to estimate. For
+ example, the root DNSKEY has protections and controls comparable
+ to or exceeding those of public CAs. On the other end of the
+ spectrum, small domains might provide no more protection to their
+ keys than they do to their other data.
+
+ o The security surrounding public CAs also varies. However, due to
+ financial incentives and standards imposed by clients for
+ acceptance into their trust anchor stores, CAs generally employ
+ security experts and protect their keys carefully, though highly
+ public compromises have occurred.
+
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 19]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+8.1.2. Impact of Key Compromise
+
+ The impact of a key compromise differs significantly between the two
+ models.
+
+ o DNSKEYs are inherently limited in what they can sign, so a
+ compromise of the DNSKEY for "example.com" provides no avenue of
+ attack against "example.org". Even the impact of a compromise of
+ .com's DNSKEY, while considerable, would be limited to .com
+ domains. Only the compromise of the root DNSKEY would have the
+ equivalent impact of an unconstrained public CA.
+
+ o Public CAs are not typically constrained in what names they can
+ sign, and therefore a compromise of even one CA allows the
+ attacker to generate a certificate for any name in the DNS. A
+ domain holder can get a certificate from any willing CA, or even
+ multiple CAs simultaneously, making it impossible for a client to
+ determine whether the certificate it is validating is legitimate
+ or fraudulent.
+
+ Because a TLSA certificate association is constrained to its
+ associated name, protocol, and port, the PKIX certificate is
+ similarly constrained, even if its public CAs signing the certificate
+ (if any) are not.
+
+8.1.3. Detection of Key Compromise
+
+ If a key is compromised, rapid and reliable detection is important in
+ order to limit the impact of the compromise. In this regard, neither
+ model prevents an attacker from near-invisibly attacking their
+ victim, provided that the necessary keys are compromised.
+
+ If a public CA is compromised, only the victim will see the
+ fraudulent certificate, as there is typically no publicly accessible
+ directory of all the certificates issued by a CA that can be
+ inspected. DNS resource records are typically published publicly.
+ However, the attacker could also allow the uncompromised records to
+ be published to the Internet as usual but provide a compromised DNS
+ view to the victim to achieve the same effect.
+
+8.1.4. Spoofing Hostnames
+
+ Some CAs implement technical controls to ensure that certificates are
+ not issued to domains with names similar to domains that are popular
+ and prone to attack. Of course, an attacker can attempt to
+ circumvent this restriction by finding a CA willing to issue the
+ certificate anyway. However, by using DNSSEC and TLSA, the attacker
+ can circumvent this check completely.
+
+
+
+Hoffman & Schlyter Standards Track [Page 20]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+8.2. DNS Caching
+
+ Implementations of this protocol rely heavily on the DNS, and are
+ thus prone to security attacks based on the deliberate
+ mis-association of TLSA records and DNS names. Implementations need
+ to be cautious in assuming the continuing validity of an association
+ between a TLSA record and a DNS name.
+
+ In particular, implementations SHOULD rely on their DNS resolver for
+ confirmation of an association between a TLSA record and a DNS name,
+ rather than caching the result of previous domain name lookups. Many
+ platforms already can cache domain name lookups locally when
+ appropriate, and they SHOULD be configured to do so. It is proper
+ for these lookups to be cached, however, only when the TTL (Time To
+ Live) information reported by the DNS makes it likely that the cached
+ information will remain useful.
+
+ If implementations cache the results of domain name lookups in order
+ to achieve a performance improvement, they MUST observe the TTL
+ information reported by DNS. Implementations that fail to follow
+ this rule could be spoofed or have access denied when a previously
+ accessed server's TLSA record changes, such as during a certificate
+ rollover.
+
+8.3. External DNSSEC Validators
+
+ Due to a lack of DNSSEC support in the most commonly deployed stub
+ resolvers today, some ISPs have begun checking DNSSEC in the
+ recursive resolvers they provide to their customers, setting the
+ Authentic Data (AD) flag as appropriate. DNSSEC-aware clients could
+ use that data, ignoring the fact that the DNSSEC data has been
+ validated externally. Because there is typically no authentication
+ of the recursive resolver or integrity protection of the data and AD
+ flag between the client and the recursive resolver, this can be
+ trivially spoofed by an attacker.
+
+ However, even with secure communications between a host and the
+ external validating resolver, there is a risk that the external
+ validator could become compromised. Nothing prevents a compromised
+ external DNSSEC validator from claiming that all the records it
+ provides are secure, even if the data is falsified, unless the client
+ checks the DNSSEC data itself (rendering the external validator
+ unnecessary).
+
+ For this reason, DNSSEC validation is best performed on-host, even
+ when a secure path to an external validator is available.
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 21]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+9. Acknowledgements
+
+ Many of the ideas in this document have been discussed over many
+ years. More recently, the ideas have been discussed by the authors
+ and others in a more focused fashion. In particular, some of the
+ ideas and words here originated with Paul Vixie, Dan Kaminsky, Jeff
+ Hodges, Phillip Hallam-Baker, Simon Josefsson, Warren Kumari, Adam
+ Langley, Ben Laurie, Ilari Liusvaara, Ondrej Mikle, Scott Schmit,
+ Ondrej Sury, Richard Barnes, Jim Schaad, Stephen Farrell, Suresh
+ Krishnaswamy, Peter Palfrader, Pieter Lexis, Wouter Wijngaards, John
+ Gilmore, and Murray Kucherawy.
+
+ This document has also been greatly helped by many active
+ participants of the DANE Working Group.
+
+10. References
+
+10.1. Normative References
+
+ [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
+ STD 13, RFC 1034, November 1987.
+
+ [RFC1035] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "DNS Security Introduction and Requirements",
+ RFC 4033, March 2005.
+
+ [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Resource Records for the DNS Security Extensions",
+ RFC 4034, March 2005.
+
+ [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Protocol Modifications for the DNS Security
+ Extensions", RFC 4035, March 2005.
+
+ [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+ [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, May 2008.
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 22]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ [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, March 2011.
+
+ [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+ Security Version 1.2", RFC 6347, January 2012.
+
+10.2. Informative References
+
+ [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
+ host table specification", RFC 952, October 1985.
+
+ [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+ specifying the location of services (DNS SRV)", RFC 2782,
+ February 2000.
+
+ [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
+
+ [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
+ Wellington, "Secret Key Transaction Authentication for DNS
+ (TSIG)", RFC 2845, May 2000.
+
+ [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
+ ( SIG(0)s)", RFC 2931, September 2000.
+
+ [RFC4025] Richardson, M., "A Method for Storing IPsec Keying
+ Material in DNS", RFC 4025, March 2005.
+
+ [RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely
+ Publish Secure Shell (SSH) Key Fingerprints", RFC 4255,
+ January 2006.
+
+ [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
+ RFC 4641, September 2006.
+
+ [RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074,
+ November 2007.
+
+ [RFC5890] Klensin, J., "Internationalized Domain Names for
+ Applications (IDNA): Definitions and Document Framework",
+ RFC 5890, August 2010.
+
+ [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
+ Extensions: Extension Definitions", RFC 6066,
+ January 2011.
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 23]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and
+ Internet Key Exchange (IKE) Document Roadmap", RFC 6071,
+ February 2011.
+
+ [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
+ (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.
+
+ [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
+ "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376,
+ September 2011.
+
+ [RFC6394] Barnes, R., "Use Cases and Requirements for DNS-Based
+ Authentication of Named Entities (DANE)", RFC 6394,
+ October 2011.
+
+ [X.690] "Recommendation ITU-T X.690 (2002) | ISO/IEC 8825-1:2002,
+ Information technology - ASN.1 encoding rules:
+ Specification of Basic Encoding Rules (BER), Canonical
+ Encoding Rules (CER) and Distinguished Encoding Rules
+ (DER)", July 2002.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 24]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+Appendix A. Operational Considerations for Deploying TLSA Records
+
+A.1. Creating TLSA Records
+
+ When creating TLSA records, care must be taken to avoid
+ misconfigurations. Section 4 of this document states that a TLSA
+ RRSet whose validation state is secure MUST be used. This means that
+ the existence of such a RRSet effectively disables other forms of
+ name and path validation. A misconfigured TLSA RRSet will
+ effectively disable access to the TLS server for all conforming
+ clients, and this document does not provide any means of making a
+ gradual transition to using TLSA.
+
+ When creating TLSA records with certificate usage 0 (CA certificate)
+ or usage 2 (trust anchor), one needs to understand the implications
+ when choosing between selector type 0 (Full certificate) and 1
+ (SubjectPublicKeyInfo). A careful choice is required because
+ different methods for building trust chains are used by different TLS
+ clients. The following outlines the cases that one ought to be aware
+ of and discusses the implications of the choice of selector type.
+
+ Certificate usage 2 is not affected by the different types of chain
+ building when the end entity certificate is the same as the trust
+ anchor certificate.
+
+A.1.1. Ambiguities and Corner Cases When TLS Clients Build Trust Chains
+
+ TLS clients can implement their own chain-building code rather than
+ rely on the chain presented by the TLS server. This means that,
+ except for the end entity certificate, any certificate presented in
+ the suggested chain might or might not be present in the final chain
+ built by the client.
+
+ Certificates that the client can use to replace certificates from the
+ original chain include:
+
+ o Client's trust anchors
+
+ o Certificates cached locally
+
+ o Certificates retrieved from a URI listed in an Authority
+ Information Access X.509v3 extension
+
+ CAs frequently reissue certificates with different validity periods,
+ signature algorithms (such as a different hash algorithm in the
+ signature algorithm), CA key pairs (such as for a cross-certificate),
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 25]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ or PKIX extensions where the public key and subject remain the same.
+ These reissued certificates are the certificates that the TLS client
+ can use in place of an original certificate.
+
+ Clients are known to exchange or remove certificates that could cause
+ TLSA certificate associations that rely on the full certificate to
+ fail. For example:
+
+ o The client considers the signature algorithm of a certificate to
+ no longer be sufficiently secure.
+
+ o The client might not have an associated root certificate in its
+ trust store and instead uses a cross-certificate with an identical
+ subject and public key.
+
+A.1.2. Choosing a Selector Type
+
+ In this section, "false-negative failure" means that a client will
+ not accept the TLSA certificate association for a certificate
+ designated by the DNS administrator. Also, "false-positive
+ acceptance" means that the client accepts a TLSA association for a
+ certificate that is not designated by the DNS administrator.
+
+A.1.2.1. Selector Type 0 (Full Certificate)
+
+ The "Full certificate" selector provides the most precise
+ specification of a TLSA certificate association, capturing all
+ fields of the PKIX certificate. For a DNS administrator, the best
+ course to avoid false-negative failures in the client when using this
+ selector is:
+
+ 1. If a CA issued a replacement certificate, don't associate to CA
+ certificates that have a signature algorithm with a hash that is
+ considered weak by local policy.
+
+ 2. Determine how common client applications process the TLSA
+ certificate association using a fresh client installation -- that
+ is, with the local certificate cache empty.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 26]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+A.1.2.2. Selector Type 1 (SubjectPublicKeyInfo)
+
+ A SubjectPublicKeyInfo selector gives greater flexibility in avoiding
+ some false-negative failures caused by trust-chain-building
+ algorithms used in clients.
+
+ One specific use case ought to be noted: creating a TLSA certificate
+ association to CA certificate I1 that directly signed end entity
+ certificate S1 of the server. The case can be illustrated by the
+ following graph:
+
+ +----+ +----+
+ | I1 | | I2 |
+ +----+ +----+
+ | |
+ v v
+ +----+ +----+
+ | S1 | | S1 |
+ +----+ +----+
+ Certificate chain sent by A different validation path
+ server in TLS handshake built by the TLS client
+
+ I2 is a reissued version of CA certificate I1 (that is, it has a
+ different hash in its signature algorithm).
+
+ In the above scenario, both certificates I1 and I2 that sign S1 need
+ to have identical SubjectPublicKeyInfo fields because the key used to
+ sign S1 is fixed. An association to SubjectPublicKeyInfo (selector
+ type 1) will always succeed in such a case, but an association with a
+ full certificate (selector type 0) might not work due to a false-
+ negative failure.
+
+ The attack surface is a bit broader compared to the "Full
+ certificate" selector: the DNS administrator might unintentionally
+ specify an association that would lead to false-positive acceptance.
+
+ o The administrator must know or trust that the CA does not engage
+ in bad practices, such as not sharing the key of I1 for unrelated
+ CA certificates (which would lead to trust-chain redirection). If
+ possible, the administrator ought to review all CA certificates
+ that have the same SubjectPublicKeyInfo field.
+
+ o The administrator ought to understand whether some PKIX extension
+ may adversely affect security of the association. If possible,
+ administrators ought to review all CA certificates that share the
+ SubjectPublicKeyInfo.
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 27]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ o The administrator ought to understand that any CA could, in the
+ future, issue a certificate that contains the same
+ SubjectPublicKeyInfo. Therefore, new chains can crop up in the
+ future without any warning.
+
+ Using the SubjectPublicKeyInfo selector for association with a
+ certificate in a chain above I1 needs to be decided on a case-by-case
+ basis: there are too many possibilities based on the issuing CA's
+ practices. Unless the full implications of such an association are
+ understood by the administrator, using selector type 0 is a better
+ option from a security perspective.
+
+A.2. Provisioning TLSA Records in DNS
+
+A.2.1. Provisioning TLSA Records with Aliases
+
+ The TLSA resource record is not special in the DNS; it acts exactly
+ like any other RRtype where the queried name has one or more labels
+ prefixed to the base name, such as the SRV RRtype [RFC2782]. This
+ affects the way that the TLSA resource record is used when aliasing
+ in the DNS.
+
+ Note that the IETF sometimes adds new types of aliasing in the DNS.
+ If that happens in the future, those aliases might affect TLSA
+ records, hopefully in a good way.
+
+A.2.1.1. Provisioning TLSA Records with CNAME Records
+
+ Using CNAME to alias in DNS only aliases from the exact name given,
+ not any zones below the given name. For example, assume that a zone
+ file has only the following:
+
+ sub1.example.com. IN CNAME sub2.example.com.
+
+ In this case, a request for the A record at "bottom.sub1.example.com"
+ would not return any records because the CNAME given only aliases the
+ name given. Assume, instead, the zone file has the following:
+
+ sub3.example.com. IN CNAME sub4.example.com.
+ bottom.sub3.example.com. IN CNAME bottom.sub4.example.com.
+
+ In this case, a request for the A record at bottom.sub3.example.com
+ would in fact return whatever value for the A record exists at
+ bottom.sub4.example.com.
+
+
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 28]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ Application implementations and full-service resolvers request DNS
+ records using libraries that automatically follow CNAME (and DNAME)
+ aliasing. This allows hosts to put TLSA records in their own zones
+ or to use CNAME to do redirection.
+
+ If the owner of the original domain wants a TLSA record for the same,
+ they simply enter it under the defined prefix:
+
+ ; No TLSA record in target domain
+ ;
+ sub5.example.com. IN CNAME sub6.example.com.
+ _443._tcp.sub5.example.com. IN TLSA 1 1 1 308202c5308201ab...
+ sub6.example.com. IN A 192.0.2.1
+ sub6.example.com. IN AAAA 2001:db8::1
+
+ If the owner of the original domain wants to have the target domain
+ host the TLSA record, the original domain uses a CNAME record:
+
+ ; TLSA record for original domain has CNAME to target domain
+ ;
+ sub5.example.com. IN CNAME sub6.example.com.
+ _443._tcp.sub5.example.com. IN CNAME _443._tcp.sub6.example.com.
+ sub6.example.com. IN A 192.0.2.1
+ sub6.example.com. IN AAAA 2001:db8::1
+ _443._tcp.sub6.example.com. IN TLSA 1 1 1 536a570ac49d9ba4...
+
+ Note that it is acceptable for both the original domain and the
+ target domain to have TLSA records, but the two records are
+ unrelated. Consider the following:
+
+ ; TLSA record in both the original and target domain
+ ;
+ sub5.example.com. IN CNAME sub6.example.com.
+ _443._tcp.sub5.example.com. IN TLSA 1 1 1 308202c5308201ab...
+ sub6.example.com. IN A 192.0.2.1
+ sub6.example.com. IN AAAA 2001:db8::1
+ _443._tcp.sub6.example.com. IN TLSA 1 1 1 ac49d9ba4570ac49...
+
+ In this example, someone looking for the TLSA record for
+ sub5.example.com would always get the record whose value starts with
+ "308202c5308201ab"; the TLSA record whose value starts with
+ "ac49d9ba4570ac49" would only be sought by someone who is looking for
+ the TLSA record for sub6.example.com, and never for sub5.example.com.
+ Note that deploying different certificates for multiple services
+ located at a shared TLS listener often requires the use of TLS SNI
+ (Server Name Indication) [RFC6066].
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 29]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ Note that these methods use the normal method for DNS aliasing using
+ CNAME: the DNS client requests the record type that they actually
+ want.
+
+A.2.1.2. Provisioning TLSA Records with DNAME Records
+
+ Using DNAME records allows a zone owner to alias an entire subtree of
+ names below the name that has the DNAME. This allows the wholesale
+ aliasing of prefixed records such as those used by TLSA, SRV, and so
+ on without aliasing the name itself. However, because DNAME can only
+ be used for subtrees of a base name, it is rarely used to alias
+ individual hosts that might also be running TLS.
+
+ ; TLSA record in target domain, visible in original domain via DNAME
+ ;
+ sub5.example.com. IN CNAME sub6.example.com.
+ _tcp.sub5.example.com. IN DNAME _tcp.sub6.example.com.
+ sub6.example.com. IN A 192.0.2.1
+ sub6.example.com. IN AAAA 2001:db8::1
+ _443._tcp.sub6.example.com. IN TLSA 1 1 1 536a570ac49d9ba4...
+
+A.2.1.3. Provisioning TLSA Records with Wildcards
+
+ Wildcards are generally not terribly useful for RRtypes that require
+ prefixing because one can only wildcard at a layer below the host
+ name. For example, if one wants to have the same TLSA record for
+ every TCP port for www.example.com, the result might be:
+
+ *._tcp.www.example.com. IN TLSA 1 1 1 5c1502a6549c423b...
+
+ This is possibly useful in some scenarios where the same service is
+ offered on many ports or the same certificate and/or key is used for
+ all services on a host. Note that the domain being searched for is
+ not necessarily related to the domain name found in the certificate,
+ so a certificate with a wildcard in it is not searched for using a
+ wildcard in the search request.
+
+A.3. Securing the Last Hop
+
+ As described in Section 4, an application processing TLSA records
+ must know the DNSSEC validity of those records. There are many ways
+ for the application to determine this securely, and this
+ specification does not mandate any single method.
+
+
+
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 30]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ Some common methods for an application to know the DNSSEC validity of
+ TLSA records include:
+
+ o The application can have its own DNS resolver and DNSSEC
+ validation stack.
+
+ o The application can communicate through a trusted channel (such as
+ requests to the operating system under which the application is
+ running) to a local DNS resolver that does DNSSEC validation.
+
+ o The application can communicate through a secured channel (such as
+ requests running over TLS, IPsec, TSIG, or SIG(0)) to a non-local
+ DNS resolver that does DNSSEC validation.
+
+ o The application can communicate through a secured channel (such as
+ requests running over TLS, IPsec, TSIG, or SIG(0)) to a non-local
+ DNS resolver that does not do DNSSEC validation, but gets
+ responses through a secured channel from a different DNS resolver
+ that does DNSSEC validation.
+
+A.4. Handling Certificate Rollover
+
+ Certificate rollover is handled in much the same way as for rolling
+ DNSSEC zone signing keys using the pre-publish key rollover method
+ [RFC4641]. Suppose example.com has a single TLSA record for a TLS
+ service on TCP port 990:
+
+ _990._tcp.example.com IN TLSA 1 1 1 1CFC98A706BCF3683015...
+
+ To start the rollover process, obtain or generate the new certificate
+ or SubjectPublicKeyInfo to be used after the rollover and generate
+ the new TLSA record. Add that record alongside the old one:
+
+ _990._tcp.example.com IN TLSA 1 1 1 1CFC98A706BCF3683015...
+ _990._tcp.example.com IN TLSA 1 1 1 62D5414CD1CC657E3D30...
+
+ After the new records have propagated to the authoritative
+ nameservers and the TTL of the old record has expired, switch to the
+ new certificate on the TLS server. Once this has occurred, the old
+ TLSA record can be removed:
+
+ _990._tcp.example.com IN TLSA 1 1 1 62D5414CD1CC657E3D30...
+
+ This completes the certificate rollover.
+
+
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 31]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+Appendix B. Pseudocode for Using TLSA
+
+ This appendix describes, in pseudocode format, the interactions given
+ earlier in this specification. If the steps below disagree with the
+ text earlier in the document, the steps earlier in the document ought
+ to be considered correct and this text incorrect.
+
+ Note that this pseudocode is more strict than the normative text.
+ For instance, it forces an order on the evaluation of criteria, which
+ is not mandatory from the normative text.
+
+B.1. Helper Functions
+
+ // implement the function for exiting
+ function Finish (F) = {
+ if (F == ABORT_TLS) {
+ abort the TLS handshake or prevent TLS from starting
+ exit
+ }
+
+ if (F == NO_TLSA) {
+ fall back to non-TLSA certificate validation
+ exit
+ }
+
+ if (F == ACCEPT) {
+ accept the TLS connection
+ exit
+ }
+
+ // unreachable
+ }
+
+ // implement the selector function
+ function Select (S, X) = {
+ // Full certificate
+ if (S == 0) {
+ return X in DER encoding
+ }
+
+ // SubjectPublicKeyInfo
+ if (S == 1) {
+ return X.SubjectPublicKeyInfo in DER encoding
+ }
+
+ // unreachable
+ }
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 32]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ // implement the matching function
+ function Match (M, X, Y) {
+ // Exact match on selected content
+ if (M == 0) {
+ return (X == Y)
+ }
+
+ // SHA-256 hash of selected content
+ if (M == 1) {
+ return (SHA-256(X) == Y)
+ }
+
+ // SHA-512 hash of selected content
+ if (M == 2) {
+ return (SHA-512(X) == Y)
+ }
+
+ // unreachable
+ }
+
+B.2. Main TLSA Pseudocode
+
+ TLS connect using [transport] to [name] on [port] and receiving end
+ entity cert C for the TLS server:
+
+ (TLSArecords, ValState) = DNSSECValidatedLookup(
+ domainname=_[port]._[transport].[name], RRtype=TLSA)
+
+ // check for states that would change processing
+ if (ValState == BOGUS) {
+ Finish(ABORT_TLS)
+ }
+ if ((ValState == INDETERMINATE) or (ValState == INSECURE)) {
+ Finish(NO_TLSA)
+ }
+ // if here, ValState must be SECURE
+
+ for each R in TLSArecords {
+ // unusable records include unknown certUsage, unknown
+ // selectorType, unknown matchingType, erroneous RDATA, and
+ // prohibited by local policy
+ if (R is unusable) {
+ remove R from TLSArecords
+ }
+ }
+ if (length(TLSArecords) == 0) {
+ Finish(NO_TLSA)
+ }
+
+
+
+Hoffman & Schlyter Standards Track [Page 33]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ // A TLS client might have multiple trust anchors that it might use
+ // when validating the TLS server's end entity (EE) certificate.
+ // Also, there can be multiple PKIX certification paths for the
+ // certificates given by the server in TLS. Thus, there are
+ // possibly many chains that might need to be tested during
+ // PKIX path validation.
+
+ for each R in TLSArecords {
+
+ // pass PKIX certificate validation and chain through a CA cert
+ // that comes from TLSA
+ if (R.certUsage == 0) {
+ for each PKIX certification path H {
+ if (C passes PKIX certification path validation in H) {
+ for each D in H {
+ if ((D is a CA certificate) and
+ Match(R.matchingType, Select(R.selectorType, D),
+ R.cert)) {
+ Finish(ACCEPT)
+ }
+ }
+ }
+ }
+ }
+
+ // pass PKIX certificate validation and match EE cert from TLSA
+ if (R.certUsage == 1) {
+ for each PKIX certification path H {
+ if ((C passes PKIX certificate validation in H) and
+ Match(R.matchingType, Select(R.selectorType, C),
+ R.cert)) {
+ Finish(ACCEPT)
+ }
+ }
+ }
+
+ // pass PKIX certification validation using TLSA record as the
+ // trust anchor
+ if (R.certUsage == 2) {
+ // the following assert() is merely a formalization of the
+ // "trust anchor" condition for a certificate D matching R
+ assert(Match(R.matchingType, Select(R.selectorType, D), R.cert))
+
+
+
+
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 34]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ for each PKIX certification path H that has certificate D
+ matching R as the trust anchor {
+ if (C passes PKIX validation in H) {
+ Finish(ACCEPT);
+ }
+ }
+ }
+
+ // match the TLSA record and the TLS certificate
+ if (R.certUsage == 3) {
+ if Match(R.matchingType, Select(R.selectorType, C), R.cert)
+ Finish(ACCEPT)
+ }
+ }
+
+ }
+
+ // if here, then none of the TLSA records ended in "Finish(ACCEPT)"
+ // so abort TLS
+ Finish(ABORT_TLS)
+
+Appendix C. Examples
+
+ The following are examples of self-signed certificates that have been
+ generated with various selectors and matching types. They were
+ generated with one piece of software, and validated by an individual
+ using other tools.
+
+ S = Selector
+ M = Matching Type
+
+ S M Association Data
+ 0 0 30820454308202BC020900AB58D24E77AD2AF6300D06092A86
+ 4886F70D0101050500306C310B3009060355040613024E4C31163014
+ 0603550408130D4E6F6F72642D486F6C6C616E643112301006035504
+ 071309416D7374657264616D310C300A060355040A13034F53333123
+ 30210603550403131A64616E652E6B6965762E70726163746963756D
+ 2E6F73332E6E6C301E170D3132303131363136353730335A170D3232
+ 303131333136353730335A306C310B3009060355040613024E4C3116
+ 30140603550408130D4E6F6F72642D486F6C6C616E64311230100603
+ 5504071309416D7374657264616D310C300A060355040A13034F5333
+ 312330210603550403131A64616E652E6B6965762E70726163746963
+ 756D2E6F73332E6E6C308201A2300D06092A864886F70D0101010500
+ 0382018F003082018A0282018100E62C84A5AFE59F0A2A6B250DEE68
+ 7AC8C5C604F57D26CEB2119140FFAC38C4B9CBBE8923082E7F81626B
+ 6AD5DEA0C8771C74E3CAA7F613054AEFA3673E48FFE47B3F7AF987DE
+ 281A68230B24B9DA1A98DCBE51195B60E42FD7517C328D983E26A827
+ C877AB914EE4C1BFDEAD48BD25BE5F2C473BA9C1CBBDDDA0C374D0D5
+
+
+
+Hoffman & Schlyter Standards Track [Page 35]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ 8C389CC3D6D8C20662E19CF768F32441B7F7D14AEA8966CE7C32A172
+ 2AB38623D008029A9E4702883F8B977A1A1E5292BF8AD72239D40393
+ 37B86A3AC60FA001290452177BF1798609A05A130F033457A5212629
+ FBDDB8E70E2A9E6556873C4F7CA46AE4A8B178F05FB319005E1C1C7D
+ 4BD77DFA34035563C126AA2C3328B900E7990AC9787F01DA82F74C3D
+ 4B6674CCECE1FD4C6EF9E6644F4635EDEDA39D8B0E2F7C8E06DAE775
+ 6213BD3D60831175BE290442B4AFC5AE6F46B769855A067C1097E617
+ 962529E166F22AEE10DDB981B8CD6FF17D3D70723169038DBFBC1A44
+ 9C8D0D31BC683C5F3CE26148E42EC9BBD4D9F261569B25B53C1D7FC2
+ DDFF6B4CAC050203010001300D06092A864886F70D01010505000382
+ 0181002B2ABE063E9C86AC4A1F7835372091079C8276A9C2C5D1EC57
+ 64DE523FDDABDEAB3FD34E6FE6CBA054580A6785A663595D90132B93
+ D473929E81FA0887D2FFF78A81C7D014B97778AB6AC9E5E690F6F5A9
+ E92BB5FBAB71B857AE69B6E18BDCCB0BA6FCD9D4B084A34F3635148C
+ 495D48FE635903B888EC1DEB2610548EDD48D63F86513A4562469831
+ 48C0D5DB82D73A4C350A42BB661D763430FC6C8E5F9D13EA1B76AA52
+ A4C358E5EA04000F794618303AB6CEEA4E9A8E9C74D73C1B0B7BAF16
+ DEDE7696B5E2F206F777100F5727E1684D4132F5E692F47AF6756EA8
+ B421000BE031B5D8F0220E436B51FB154FE9595333C13A2403F9DE08
+ E5DDC5A22FD6182E339593E26374450220BC14F3E40FF33F084526B0
+ 9C34250702E8A352B332CCCB0F9DE2CF2B338823B92AFC61C0B6B8AB
+ DB5AF718ED8DDA97C298E46B82A01B14814868CFA4F2C36268BFFF4A
+ 591F42658BF75918902D3E426DFE1D5FF0FC6A212071F6DA8BD833FE
+ 2E560D87775E8EE9333C05B6FB8EB56589D910DB5EA903
+
+ 0 1 EFDDF0D915C7BDC5782C0881E1B2A95AD099FBDD06D7B1F779
+ 82D9364338D955
+
+ 0 2 81EE7F6C0ECC6B09B7785A9418F54432DE630DD54DC6EE9E3C
+ 49DE547708D236D4C413C3E97E44F969E635958AA410495844127C04
+ 883503E5B024CF7A8F6A94
+
+ 1 0 308201A2300D06092A864886F70D01010105000382018F0030
+ 82018A0282018100E62C84A5AFE59F0A2A6B250DEE687AC8C5C604F5
+ 7D26CEB2119140FFAC38C4B9CBBE8923082E7F81626B6AD5DEA0C877
+ 1C74E3CAA7F613054AEFA3673E48FFE47B3F7AF987DE281A68230B24
+ B9DA1A98DCBE51195B60E42FD7517C328D983E26A827C877AB914EE4
+ C1BFDEAD48BD25BE5F2C473BA9C1CBBDDDA0C374D0D58C389CC3D6D8
+ C20662E19CF768F32441B7F7D14AEA8966CE7C32A1722AB38623D008
+ 029A9E4702883F8B977A1A1E5292BF8AD72239D4039337B86A3AC60F
+ A001290452177BF1798609A05A130F033457A5212629FBDDB8E70E2A
+ 9E6556873C4F7CA46AE4A8B178F05FB319005E1C1C7D4BD77DFA3403
+ 5563C126AA2C3328B900E7990AC9787F01DA82F74C3D4B6674CCECE1
+ FD4C6EF9E6644F4635EDEDA39D8B0E2F7C8E06DAE7756213BD3D6083
+ 1175BE290442B4AFC5AE6F46B769855A067C1097E617962529E166F2
+ 2AEE10DDB981B8CD6FF17D3D70723169038DBFBC1A449C8D0D31BC68
+ 3C5F3CE26148E42EC9BBD4D9F261569B25B53C1D7FC2DDFF6B4CAC05
+ 0203010001
+
+
+
+Hoffman & Schlyter Standards Track [Page 36]
+\f
+RFC 6698 DNS-Based Authentication for TLS August 2012
+
+
+ 1 1 8755CDAA8FE24EF16CC0F2C918063185E433FAAF1415664911
+ D9E30A924138C4
+
+ 1 2 D43165B4CDF8F8660AECCCC5344D9D9AE45FFD7E6AAB7AB9EE
+ C169B58E11F227ED90C17330CC17B5CCEF0390066008C720CEC6AAE5
+ 33A934B3A2D7E232C94AB4
+
+Authors' Addresses
+
+ Paul Hoffman
+ VPN Consortium
+
+ EMail: paul.hoffman@vpnc.org
+
+
+ Jakob Schlyter
+ Kirei AB
+
+ EMail: jakob@kirei.se
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman & Schlyter Standards Track [Page 37]
+\f
OBJ_WITH_CONTENT_SCAN = malware.o mime.o regex.o spam.o spool_mbox.o
OBJ_WITH_OLD_DEMIME = demime.o
-OBJ_EXPERIMENTAL = bmi_spam.o spf.o srs.o dcc.o dmarc.o
+OBJ_EXPERIMENTAL = bmi_spam.o spf.o srs.o dcc.o dmarc.o dane.o
# Targets for final binaries; the main one has a build number which is
# updated each time. We don't bother with that for the auxiliaries.
# Dependencies for EXPERIMENTAL_* modules
bmi_spam.o: $(HDRS) bmi_spam.c
-spf.o: $(HDRS) spf.h spf.c
-srs.o: $(HDRS) srs.h srs.c
+dane.o: $(HDRS) dane.c dane-gnu.c dane-openssl.c
dcc.o: $(HDRS) dcc.h dcc.c
dmarc.o: $(HDRS) dmarc.h dmarc.c
+spf.o: $(HDRS) spf.h spf.c
+srs.o: $(HDRS) srs.h srs.c
# The module containing tables of available lookups, routers, auths, and
# transports must be rebuilt if any of them are. However, because the makefiles
ln -s ../src/srs.h srs.h
ln -s ../src/dcc.c dcc.c
ln -s ../src/dcc.h dcc.h
+ln -s ../src/dane.c dane.c
+ln -s ../src/dane-gnu.c dane-gnu.c
+ln -s ../src/dane-openssl.c dane-openssl.c
+ln -s ../src/danessl.h danessl.h
# End of MakeLinks
# Uncomment the following line to add DSN support
# EXPERIMENTAL_DSN=yes
+# Uncomment the following line to add DANE support
+# EXPERIMENTAL_DANE=yes
+
###############################################################################
# THESE ARE THINGS YOU MIGHT WANT TO SPECIFY #
###############################################################################
/* EXPERIMENTAL features */
#define EXPERIMENTAL_BRIGHTMAIL
#define EXPERIMENTAL_CERTNAMES
+#define EXPERIMENTAL_DANE
#define EXPERIMENTAL_DCC
#define EXPERIMENTAL_DMARC
#define EXPERIMENTAL_DSN
--- /dev/null
+/*************************************************
+* Exim - an Internet mail transport agent *
+*************************************************/
+
+/* Copyright (c) University of Cambridge 1995 - 2013 */
+/* See the file NOTICE for conditions of use and distribution. */
+
+/* This file (will) provide DANE support for Exim using the GnuTLS library,
+but is not yet an available supported implementation. This file is #included
+into dane.c when USE_GNUTLS has been set. */
+
+/* As of March 2014, the reference implementation for DANE that we are
+using was written by Viktor Dukhovny and it supports OpenSSL only. At
+some point we will add GnuTLS support, but for right now just abort the
+build and explain why. */
+
+
+#error No support for DANE using GnuTLS yet.
+
+
+/* End of dane-gnu.c */
--- /dev/null
+#include <stdio.h>
+#include <string.h>
+#include <stdint.h>
+
+#include <openssl/opensslv.h>
+#include <openssl/err.h>
+#include <openssl/crypto.h>
+#include <openssl/safestack.h>
+#include <openssl/objects.h>
+#include <openssl/x509.h>
+#include <openssl/x509v3.h>
+#include <openssl/evp.h>
+
+#if OPENSSL_VERSION_NUMBER < 0x1000000fL
+# error "OpenSSL 1.0.0 or higher required"
+#else /* remainder of file */
+
+#include "danessl.h"
+
+#define DANE_F_ADD_SKID 100
+#define DANE_F_CHECK_END_ENTITY 101
+#define DANE_F_GROW_CHAIN 102
+#define DANE_F_LIST_ALLOC 103
+#define DANE_F_MATCH 104
+#define DANE_F_PUSH_EXT 105
+#define DANE_F_SET_TRUST_ANCHOR 106
+#define DANE_F_SSL_CTX_DANE_INIT 107
+#define DANE_F_SSL_DANE_ADD_TLSA 108
+#define DANE_F_SSL_DANE_INIT 109
+#define DANE_F_SSL_DANE_LIBRARY_INIT 110
+#define DANE_F_VERIFY_CERT 111
+#define DANE_F_WRAP_CERT 112
+
+#define DANE_R_BAD_CERT 100
+#define DANE_R_BAD_CERT_PKEY 101
+#define DANE_R_BAD_DATA_LENGTH 102
+#define DANE_R_BAD_DIGEST 103
+#define DANE_R_BAD_NULL_DATA 104
+#define DANE_R_BAD_PKEY 105
+#define DANE_R_BAD_SELECTOR 106
+#define DANE_R_BAD_USAGE 107
+#define DANE_R_DANE_INIT 108
+#define DANE_R_DANE_SUPPORT 109
+#define DANE_R_LIBRARY_INIT 110
+#define DANE_R_NOSIGN_KEY 111
+#define DANE_R_SCTX_INIT 112
+
+#ifndef OPENSSL_NO_ERR
+# define DANE_F_PLACEHOLDER 0 /* FIRST! Value TBD */
+static ERR_STRING_DATA dane_str_functs[] =
+{
+ {DANE_F_PLACEHOLDER, "DANE library"}, /* FIRST!!! */
+ {DANE_F_ADD_SKID, "add_skid"},
+ {DANE_F_CHECK_END_ENTITY, "check_end_entity"},
+ {DANE_F_GROW_CHAIN, "grow_chain"},
+ {DANE_F_LIST_ALLOC, "list_alloc"},
+ {DANE_F_MATCH, "match"},
+ {DANE_F_PUSH_EXT, "push_ext"},
+ {DANE_F_SET_TRUST_ANCHOR, "set_trust_anchor"},
+ {DANE_F_SSL_CTX_DANE_INIT, "SSL_CTX_dane_init"},
+ {DANE_F_SSL_DANE_ADD_TLSA, "SSL_dane_add_tlsa"},
+ {DANE_F_SSL_DANE_INIT, "SSL_dane_init"},
+ {DANE_F_SSL_DANE_LIBRARY_INIT, "SSL_dane_library_init"},
+ {DANE_F_VERIFY_CERT, "verify_cert"},
+ {DANE_F_WRAP_CERT, "wrap_cert"},
+ {0, NULL}
+};
+static ERR_STRING_DATA dane_str_reasons[] =
+{
+ {DANE_R_BAD_CERT, "Bad TLSA record certificate"},
+ {DANE_R_BAD_CERT_PKEY, "Bad TLSA record certificate public key"},
+ {DANE_R_BAD_DATA_LENGTH, "Bad TLSA record digest length"},
+ {DANE_R_BAD_DIGEST, "Bad TLSA record digest"},
+ {DANE_R_BAD_NULL_DATA, "Bad TLSA record null data"},
+ {DANE_R_BAD_PKEY, "Bad TLSA record public key"},
+ {DANE_R_BAD_SELECTOR, "Bad TLSA record selector"},
+ {DANE_R_BAD_USAGE, "Bad TLSA record usage"},
+ {DANE_R_DANE_INIT, "SSL_dane_init() required"},
+ {DANE_R_DANE_SUPPORT, "DANE library features not supported"},
+ {DANE_R_LIBRARY_INIT, "SSL_dane_library_init() required"},
+ {DANE_R_SCTX_INIT, "SSL_CTX_dane_init() required"},
+ {DANE_R_NOSIGN_KEY, "Certificate usage 2 requires EC support"},
+ {0, NULL}
+};
+#endif /*OPENSSL_NO_ERR*/
+
+#define DANEerr(f, r) ERR_PUT_error(err_lib_dane, (f), (r), __FILE__, __LINE__)
+
+static int err_lib_dane = -1;
+static int dane_idx = -1;
+
+#ifdef X509_V_FLAG_PARTIAL_CHAIN /* OpenSSL >= 1.0.2 */
+static int wrap_to_root = 0;
+#else
+static int wrap_to_root = 1;
+#endif
+
+static void (*cert_free)(void *) = (void (*)(void *)) X509_free;
+static void (*pkey_free)(void *) = (void (*)(void *)) EVP_PKEY_free;
+
+typedef struct dane_list
+{
+ struct dane_list *next;
+ void *value;
+} *dane_list;
+
+#define LINSERT(h, e) do { (e)->next = (h); (h) = (e); } while (0)
+
+typedef struct dane_host_list
+{
+ struct dane_host_list *next;
+ char *value;
+} *dane_host_list;
+
+typedef struct dane_data
+{
+ size_t datalen;
+ unsigned char data[0];
+} *dane_data;
+
+typedef struct dane_data_list
+{
+ struct dane_data_list *next;
+ dane_data value;
+} *dane_data_list;
+
+typedef struct dane_mtype
+{
+ int mdlen;
+ const EVP_MD *md;
+ dane_data_list data;
+} *dane_mtype;
+
+typedef struct dane_mtype_list
+{
+ struct dane_mtype_list *next;
+ dane_mtype value;
+} *dane_mtype_list;
+
+typedef struct dane_selector
+{
+ uint8_t selector;
+ dane_mtype_list mtype;
+} *dane_selector;
+
+typedef struct dane_selector_list
+{
+ struct dane_selector_list *next;
+ dane_selector value;
+} *dane_selector_list;
+
+typedef struct dane_pkey_list
+{
+ struct dane_pkey_list *next;
+ EVP_PKEY *value;
+} *dane_pkey_list;
+
+typedef struct dane_cert_list
+{
+ struct dane_cert_list *next;
+ X509 *value;
+} *dane_cert_list;
+
+typedef struct ssl_dane
+{
+ int (*verify)(X509_STORE_CTX *);
+ STACK_OF(X509) *roots;
+ STACK_OF(X509) *chain;
+ const char *thost; /* TLSA base domain */
+ char *mhost; /* Matched, peer name */
+ dane_pkey_list pkeys;
+ dane_cert_list certs;
+ dane_host_list hosts;
+ dane_selector_list selectors[SSL_DANE_USAGE_LAST + 1];
+ int depth;
+ int multi; /* Multi-label wildcards? */
+ int count; /* Number of TLSA records */
+} ssl_dane;
+
+#ifndef X509_V_ERR_HOSTNAME_MISMATCH
+# define X509_V_ERR_HOSTNAME_MISMATCH X509_V_ERR_APPLICATION_VERIFICATION
+#endif
+
+static int
+match(dane_selector_list slist, X509 *cert, int depth)
+{
+int matched;
+
+/*
+ * Note, set_trust_anchor() needs to know whether the match was for a
+ * pkey digest or a certificate digest. We return MATCHED_PKEY or
+ * MATCHED_CERT accordingly.
+ */
+#define MATCHED_CERT (SSL_DANE_SELECTOR_CERT + 1)
+#define MATCHED_PKEY (SSL_DANE_SELECTOR_SPKI + 1)
+
+/*
+ * Loop over each selector, mtype, and associated data element looking
+ * for a match.
+ */
+for(matched = 0; !matched && slist; slist = slist->next)
+ {
+ dane_mtype_list m;
+ unsigned char mdbuf[EVP_MAX_MD_SIZE];
+ unsigned char *buf = NULL;
+ unsigned char *buf2;
+ unsigned int len = 0;
+
+ /*
+ * Extract ASN.1 DER form of certificate or public key.
+ */
+ switch(slist->value->selector)
+ {
+ case SSL_DANE_SELECTOR_CERT:
+ len = i2d_X509(cert, NULL);
+ buf2 = buf = (unsigned char *) OPENSSL_malloc(len);
+ if(buf) i2d_X509(cert, &buf2);
+ break;
+ case SSL_DANE_SELECTOR_SPKI:
+ len = i2d_X509_PUBKEY(X509_get_X509_PUBKEY(cert), NULL);
+ buf2 = buf = (unsigned char *) OPENSSL_malloc(len);
+ if(buf) i2d_X509_PUBKEY(X509_get_X509_PUBKEY(cert), &buf2);
+ break;
+ }
+
+ if(!buf)
+ {
+ DANEerr(DANE_F_MATCH, ERR_R_MALLOC_FAILURE);
+ return 0;
+ }
+ OPENSSL_assert(buf2 - buf == len);
+
+ /*
+ * Loop over each mtype and data element
+ */
+ for(m = slist->value->mtype; !matched && m; m = m->next)
+ {
+ dane_data_list d;
+ unsigned char *cmpbuf = buf;
+ unsigned int cmplen = len;
+
+ /*
+ * If it is a digest, compute the corresponding digest of the
+ * DER data for comparison, otherwise, use the full object.
+ */
+ if(m->value->md)
+ {
+ cmpbuf = mdbuf;
+ if(!EVP_Digest(buf, len, cmpbuf, &cmplen, m->value->md, 0))
+ matched = -1;
+ }
+ for(d = m->value->data; !matched && d; d = d->next)
+ if( cmplen == d->value->datalen
+ && memcmp(cmpbuf, d->value->data, cmplen) == 0)
+ matched = slist->value->selector + 1;
+ }
+
+ OPENSSL_free(buf);
+ }
+
+return matched;
+}
+
+static int
+push_ext(X509 *cert, X509_EXTENSION *ext)
+{
+X509_EXTENSIONS *exts;
+
+if(ext)
+ {
+ if(!(exts = cert->cert_info->extensions))
+ exts = cert->cert_info->extensions = sk_X509_EXTENSION_new_null();
+ if (exts && sk_X509_EXTENSION_push(exts, ext))
+ return 1;
+ X509_EXTENSION_free(ext);
+ }
+DANEerr(DANE_F_PUSH_EXT, ERR_R_MALLOC_FAILURE);
+return 0;
+}
+
+static int
+add_ext(X509 *issuer, X509 *subject, int ext_nid, char *ext_val)
+{
+X509V3_CTX v3ctx;
+
+X509V3_set_ctx(&v3ctx, issuer, subject, 0, 0, 0);
+return push_ext(subject, X509V3_EXT_conf_nid(0, &v3ctx, ext_nid, ext_val));
+}
+
+static int
+set_serial(X509 *cert, AUTHORITY_KEYID *akid, X509 *subject)
+{
+int ret = 0;
+BIGNUM *bn;
+
+if(akid && akid->serial)
+ return (X509_set_serialNumber(cert, akid->serial));
+
+/*
+ * Add one to subject's serial to avoid collisions between TA serial and
+ * serial of signing root.
+ */
+if( (bn = ASN1_INTEGER_to_BN(X509_get_serialNumber(subject), 0)) != 0
+ && BN_add_word(bn, 1)
+ && BN_to_ASN1_INTEGER(bn, X509_get_serialNumber(cert)))
+ ret = 1;
+
+if(bn)
+ BN_free(bn);
+return ret;
+}
+
+static int
+add_akid(X509 *cert, AUTHORITY_KEYID *akid)
+{
+int nid = NID_authority_key_identifier;
+ASN1_STRING *id;
+unsigned char c = 0;
+int ret = 0;
+
+/*
+ * 0 will never be our subject keyid from a SHA-1 hash, but it could be
+ * our subject keyid if forced from child's akid. If so, set our
+ * authority keyid to 1. This way we are never self-signed, and thus
+ * exempt from any potential (off by default for now in OpenSSL)
+ * self-signature checks!
+ */
+id = (ASN1_STRING *) ((akid && akid->keyid) ? akid->keyid : 0);
+if(id && M_ASN1_STRING_length(id) == 1 && *M_ASN1_STRING_data(id) == c)
+ c = 1;
+
+if( (akid = AUTHORITY_KEYID_new()) != 0
+ && (akid->keyid = ASN1_OCTET_STRING_new()) != 0
+ && M_ASN1_OCTET_STRING_set(akid->keyid, (void *) &c, 1)
+ && X509_add1_ext_i2d(cert, nid, akid, 0, X509V3_ADD_APPEND))
+ ret = 1;
+if(akid)
+ AUTHORITY_KEYID_free(akid);
+return ret;
+}
+
+static int
+add_skid(X509 *cert, AUTHORITY_KEYID *akid)
+{
+int nid = NID_subject_key_identifier;
+
+if(!akid || !akid->keyid)
+ return add_ext(0, cert, nid, "hash");
+return X509_add1_ext_i2d(cert, nid, akid->keyid, 0, X509V3_ADD_APPEND) > 0;
+}
+
+static X509_NAME *
+akid_issuer_name(AUTHORITY_KEYID *akid)
+{
+if(akid && akid->issuer)
+ {
+ int i;
+ GENERAL_NAMES *gens = akid->issuer;
+
+ for(i = 0; i < sk_GENERAL_NAME_num(gens); ++i)
+ {
+ GENERAL_NAME *gn = sk_GENERAL_NAME_value(gens, i);
+
+ if(gn->type == GEN_DIRNAME)
+ return (gn->d.dirn);
+ }
+ }
+return 0;
+}
+
+static int
+set_issuer_name(X509 *cert, AUTHORITY_KEYID *akid)
+{
+X509_NAME *name = akid_issuer_name(akid);
+
+/*
+ * If subject's akid specifies an authority key identifer issuer name, we
+ * must use that.
+ */
+return X509_set_issuer_name(cert,
+ name ? name : X509_get_subject_name(cert));
+}
+
+static int
+grow_chain(ssl_dane *dane, int trusted, X509 *cert)
+{
+STACK_OF(X509) **xs = trusted ? &dane->roots : &dane->chain;
+static ASN1_OBJECT *serverAuth = 0;
+
+#define UNTRUSTED 0
+#define TRUSTED 1
+
+if( trusted && !serverAuth
+ && !(serverAuth = OBJ_nid2obj(NID_server_auth)))
+ {
+ DANEerr(DANE_F_GROW_CHAIN, ERR_R_MALLOC_FAILURE);
+ return 0;
+ }
+if(!*xs && !(*xs = sk_X509_new_null()))
+ {
+ DANEerr(DANE_F_GROW_CHAIN, ERR_R_MALLOC_FAILURE);
+ return 0;
+ }
+
+if(cert)
+ {
+ if(trusted && !X509_add1_trust_object(cert, serverAuth))
+ return 0;
+ CRYPTO_add(&cert->references, 1, CRYPTO_LOCK_X509);
+ if (!sk_X509_push(*xs, cert))
+ {
+ X509_free(cert);
+ DANEerr(DANE_F_GROW_CHAIN, ERR_R_MALLOC_FAILURE);
+ return 0;
+ }
+ }
+return 1;
+}
+
+static int
+wrap_issuer(ssl_dane *dane, EVP_PKEY *key, X509 *subject, int depth, int top)
+{
+int ret = 1;
+X509 *cert = 0;
+AUTHORITY_KEYID *akid;
+X509_NAME *name = X509_get_issuer_name(subject);
+EVP_PKEY *newkey = key ? key : X509_get_pubkey(subject);
+
+#define WRAP_MID 0 /* Ensure intermediate. */
+#define WRAP_TOP 1 /* Ensure self-signed. */
+
+if(!name || !newkey || !(cert = X509_new()))
+ return 0;
+
+/*
+ * Record the depth of the trust-anchor certificate.
+ */
+if(dane->depth < 0)
+ dane->depth = depth + 1;
+
+/*
+ * XXX: Uncaught error condition:
+ *
+ * The return value is NULL both when the extension is missing, and when
+ * OpenSSL rans out of memory while parsing the extension.
+ */
+ERR_clear_error();
+akid = X509_get_ext_d2i(subject, NID_authority_key_identifier, 0, 0);
+/* XXX: Should we peek at the error stack here??? */
+
+/*
+ * If top is true generate a self-issued root CA, otherwise an
+ * intermediate CA and possibly its self-signed issuer.
+ *
+ * CA cert valid for +/- 30 days
+ */
+if( !X509_set_version(cert, 2)
+ || !set_serial(cert, akid, subject)
+ || !X509_set_subject_name(cert, name)
+ || !set_issuer_name(cert, akid)
+ || !X509_gmtime_adj(X509_get_notBefore(cert), -30 * 86400L)
+ || !X509_gmtime_adj(X509_get_notAfter(cert), 30 * 86400L)
+ || !X509_set_pubkey(cert, newkey)
+ || !add_ext(0, cert, NID_basic_constraints, "CA:TRUE")
+ || (!top && !add_akid(cert, akid))
+ || !add_skid(cert, akid)
+ || ( !top && wrap_to_root
+ && !wrap_issuer(dane, newkey, cert, depth, WRAP_TOP)))
+ ret = 0;
+
+if(akid)
+ AUTHORITY_KEYID_free(akid);
+if(!key)
+ EVP_PKEY_free(newkey);
+if(ret)
+ ret = grow_chain(dane, !top && wrap_to_root ? UNTRUSTED : TRUSTED, cert);
+if(cert)
+ X509_free(cert);
+return ret;
+}
+
+static int
+wrap_cert(ssl_dane *dane, X509 *tacert, int depth)
+{
+if(dane->depth < 0)
+ dane->depth = depth + 1;
+
+/*
+ * If the TA certificate is self-issued, or need not be, use it directly.
+ * Otherwise, synthesize requisuite ancestors.
+ */
+if( !wrap_to_root
+ || X509_check_issued(tacert, tacert) == X509_V_OK)
+ return grow_chain(dane, TRUSTED, tacert);
+
+if(wrap_issuer(dane, 0, tacert, depth, WRAP_MID))
+ return grow_chain(dane, UNTRUSTED, tacert);
+return 0;
+}
+
+static int
+ta_signed(ssl_dane *dane, X509 *cert, int depth)
+{
+dane_cert_list x;
+dane_pkey_list k;
+EVP_PKEY *pk;
+int done = 0;
+
+/*
+ * First check whether issued and signed by a TA cert, this is cheaper
+ * than the bare-public key checks below, since we can determine whether
+ * the candidate TA certificate issued the certificate to be checked
+ * first (name comparisons), before we bother with signature checks
+ * (public key operations).
+ */
+for (x = dane->certs; !done && x; x = x->next)
+ {
+ if(X509_check_issued(x->value, cert) == X509_V_OK)
+ {
+ if(!(pk = X509_get_pubkey(x->value)))
+ {
+ /*
+ * The cert originally contained a valid pkey, which does
+ * not just vanish, so this is most likely a memory error.
+ */
+ done = -1;
+ break;
+ }
+ /* Check signature, since some other TA may work if not this. */
+ if(X509_verify(cert, pk) > 0)
+ done = wrap_cert(dane, x->value, depth) ? 1 : -1;
+ EVP_PKEY_free(pk);
+ }
+ }
+
+/*
+ * With bare TA public keys, we can't check whether the trust chain is
+ * issued by the key, but we can determine whether it is signed by the
+ * key, so we go with that.
+ *
+ * Ideally, the corresponding certificate was presented in the chain, and we
+ * matched it by its public key digest one level up. This code is here
+ * to handle adverse conditions imposed by sloppy administrators of
+ * receiving systems with poorly constructed chains.
+ *
+ * We'd like to optimize out keys that should not match when the cert's
+ * authority key id does not match the key id of this key computed via
+ * the RFC keyid algorithm (SHA-1 digest of public key bit-string sans
+ * ASN1 tag and length thus also excluding the unused bits field that is
+ * logically part of the length). However, some CAs have a non-standard
+ * authority keyid, so we lose. Too bad.
+ *
+ * This may push errors onto the stack when the certificate signature is
+ * not of the right type or length, throw these away,
+ */
+for(k = dane->pkeys; !done && k; k = k->next)
+ if(X509_verify(cert, k->value) > 0)
+ done = wrap_issuer(dane, k->value, cert, depth, WRAP_MID) ? 1 : -1;
+ else
+ ERR_clear_error();
+
+return done;
+}
+
+static int
+set_trust_anchor(X509_STORE_CTX *ctx, ssl_dane *dane, X509 *cert)
+{
+int matched = 0;
+int n;
+int i;
+int depth = 0;
+EVP_PKEY *takey;
+X509 *ca;
+STACK_OF(X509) *in = ctx->untrusted; /* XXX: Accessor? */
+
+if(!grow_chain(dane, UNTRUSTED, 0))
+ return -1;
+
+/*
+ * Accept a degenerate case: depth 0 self-signed trust-anchor.
+ */
+if(X509_check_issued(cert, cert) == X509_V_OK)
+ {
+ dane->depth = 0;
+ matched = match(dane->selectors[SSL_DANE_USAGE_TRUSTED_CA], cert, 0);
+ if(matched > 0 && !grow_chain(dane, TRUSTED, cert))
+ matched = -1;
+ return matched;
+ }
+
+/* Make a shallow copy of the input untrusted chain. */
+if(!(in = sk_X509_dup(in)))
+ {
+ DANEerr(DANE_F_SET_TRUST_ANCHOR, ERR_R_MALLOC_FAILURE);
+ return -1;
+ }
+
+/*
+ * At each iteration we consume the issuer of the current cert. This
+ * reduces the length of the "in" chain by one. If no issuer is found,
+ * we are done. We also stop when a certificate matches a TA in the
+ * peer's TLSA RRset.
+ *
+ * Caller ensures that the initial certificate is not self-signed.
+ */
+for(n = sk_X509_num(in); n > 0; --n, ++depth)
+ {
+ for(i = 0; i < n; ++i)
+ if(X509_check_issued(sk_X509_value(in, i), cert) == X509_V_OK)
+ break;
+
+ /*
+ * Final untrusted element with no issuer in the peer's chain, it may
+ * however be signed by a pkey or cert obtained via a TLSA RR.
+ */
+ if(i == n)
+ break;
+
+ /* Peer's chain contains an issuer ca. */
+ ca = sk_X509_delete(in, i);
+
+ /* If not a trust anchor, record untrusted ca and continue. */
+ if((matched = match(dane->selectors[SSL_DANE_USAGE_TRUSTED_CA], ca, depth+1))
+ == 0)
+ {
+ if(grow_chain(dane, UNTRUSTED, ca))
+ {
+ if(!X509_check_issued(ca, ca) == X509_V_OK)
+ {
+ /* Restart with issuer as subject */
+ cert = ca;
+ continue;
+ }
+ /* Final self-signed element, skip ta_signed() check. */
+ cert = 0;
+ }
+ else
+ matched = -1;
+ }
+ else if(matched == MATCHED_CERT)
+ {
+ if(!wrap_cert(dane, ca, depth))
+ matched = -1;
+ }
+ else if(matched == MATCHED_PKEY)
+ {
+ if( !(takey = X509_get_pubkey(ca))
+ || !wrap_issuer(dane, takey, cert, depth, WRAP_MID))
+ {
+ if(takey)
+ EVP_PKEY_free(takey);
+ else
+ DANEerr(DANE_F_SET_TRUST_ANCHOR, ERR_R_MALLOC_FAILURE);
+ matched = -1;
+ }
+ }
+ break;
+ }
+
+/* Shallow free the duplicated input untrusted chain. */
+sk_X509_free(in);
+
+/*
+ * When the loop exits, if "cert" is set, it is not self-signed and has
+ * no issuer in the chain, we check for a possible signature via a DNS
+ * obtained TA cert or public key.
+ */
+if(matched == 0 && cert)
+ matched = ta_signed(dane, cert, depth);
+
+return matched;
+}
+
+static int
+check_end_entity(X509_STORE_CTX *ctx, ssl_dane *dane, X509 *cert)
+{
+int matched;
+
+matched = match(dane->selectors[SSL_DANE_USAGE_FIXED_LEAF], cert, 0);
+if(matched > 0)
+ if(!ctx->chain)
+ {
+ if( (ctx->chain = sk_X509_new_null())
+ && sk_X509_push(ctx->chain, cert))
+ CRYPTO_add(&cert->references, 1, CRYPTO_LOCK_X509);
+ else
+ {
+ DANEerr(DANE_F_CHECK_END_ENTITY, ERR_R_MALLOC_FAILURE);
+ return -1;
+ }
+ }
+return matched;
+}
+
+static int
+match_name(const char *certid, ssl_dane *dane)
+{
+int multi = dane->multi;
+dane_host_list hosts;
+
+for(hosts = dane->hosts; hosts; hosts = hosts->next)
+ {
+ int match_subdomain = 0;
+ const char *domain = hosts->value;
+ const char *parent;
+ int idlen;
+ int domlen;
+
+ if(*domain == '.' && domain[1] != '\0')
+ {
+ ++domain;
+ match_subdomain = 1;
+ }
+
+ /*
+ * Sub-domain match: certid is any sub-domain of hostname.
+ */
+ if(match_subdomain)
+ {
+ if( (idlen = strlen(certid)) > (domlen = strlen(domain)) + 1
+ && certid[idlen - domlen - 1] == '.'
+ && !strcasecmp(certid + (idlen - domlen), domain))
+ return 1;
+ else
+ continue;
+ }
+
+ /*
+ * Exact match and initial "*" match. The initial "*" in a certid
+ * matches one (if multi is false) or more hostname components under
+ * the condition that the certid contains multiple hostname components.
+ */
+ if( !strcasecmp(certid, domain)
+ || ( certid[0] == '*' && certid[1] == '.' && certid[2] != 0
+ && (parent = strchr(domain, '.')) != 0
+ && (idlen = strlen(certid + 1)) <= (domlen = strlen(parent))
+ && strcasecmp(multi ? parent + domlen - idlen : parent, certid+1) == 0))
+ return 1;
+ }
+return 0;
+}
+
+static char *
+check_name(char *name, int len)
+{
+char *cp = name + len;
+
+while(len > 0 && !*--cp)
+ --len; /* Ignore trailing NULs */
+if(len <= 0)
+ return 0;
+for(cp = name; *cp; cp++)
+ {
+ char c = *cp;
+ if (!((c >= 'a' && c <= 'z') ||
+ (c >= '0' && c <= '9') ||
+ (c >= 'A' && c <= 'Z') ||
+ (c == '.' || c == '-') ||
+ (c == '*')))
+ return 0; /* Only LDH, '.' and '*' */
+ }
+if(cp - name != len) /* Guard against internal NULs */
+ return 0;
+return name;
+}
+
+static char *
+parse_dns_name(const GENERAL_NAME *gn)
+{
+if(gn->type != GEN_DNS)
+ return 0;
+if(ASN1_STRING_type(gn->d.ia5) != V_ASN1_IA5STRING)
+ return 0;
+return check_name((char *) ASN1_STRING_data(gn->d.ia5),
+ ASN1_STRING_length(gn->d.ia5));
+}
+
+static char *
+parse_subject_name(X509 *cert)
+{
+X509_NAME *name = X509_get_subject_name(cert);
+X509_NAME_ENTRY *entry;
+ASN1_STRING *entry_str;
+unsigned char *namebuf;
+int nid = NID_commonName;
+int len;
+int i;
+
+if(!name || (i = X509_NAME_get_index_by_NID(name, nid, -1)) < 0)
+ return 0;
+if(!(entry = X509_NAME_get_entry(name, i)))
+ return 0;
+if(!(entry_str = X509_NAME_ENTRY_get_data(entry)))
+ return 0;
+
+if((len = ASN1_STRING_to_UTF8(&namebuf, entry_str)) < 0)
+ return 0;
+if(len <= 0 || check_name((char *) namebuf, len) == 0)
+ {
+ OPENSSL_free(namebuf);
+ return 0;
+ }
+return (char *) namebuf;
+}
+
+static int
+name_check(ssl_dane *dane, X509 *cert)
+{
+int matched = 0;
+BOOL got_altname = FALSE;
+GENERAL_NAMES *gens;
+
+gens = X509_get_ext_d2i(cert, NID_subject_alt_name, 0, 0);
+if(gens)
+ {
+ int n = sk_GENERAL_NAME_num(gens);
+ int i;
+
+ for(i = 0; i < n; ++i)
+ {
+ const GENERAL_NAME *gn = sk_GENERAL_NAME_value(gens, i);
+ const char *certid;
+
+ if(gn->type != GEN_DNS)
+ continue;
+ got_altname = TRUE;
+ certid = parse_dns_name(gn);
+ if(certid && *certid)
+ {
+ if((matched = match_name(certid, dane)) == 0)
+ continue;
+ if(!(dane->mhost = OPENSSL_strdup(certid)))
+ matched = -1;
+ break;
+ }
+ }
+ GENERAL_NAMES_free(gens);
+ }
+
+/*
+ * XXX: Should the subjectName be skipped when *any* altnames are present,
+ * or only when DNS altnames are present?
+ */
+if(got_altname)
+ {
+ char *certid = parse_subject_name(cert);
+ if(certid != 0 && *certid && (matched = match_name(certid, dane)) != 0)
+ dane->mhost = certid; /* Already a copy */
+ }
+return matched;
+}
+
+static int
+verify_chain(X509_STORE_CTX *ctx)
+{
+dane_selector_list issuer_rrs;
+dane_selector_list leaf_rrs;
+int (*cb)(int, X509_STORE_CTX *) = ctx->verify_cb;
+int ssl_idx = SSL_get_ex_data_X509_STORE_CTX_idx();
+SSL *ssl = X509_STORE_CTX_get_ex_data(ctx, ssl_idx);
+ssl_dane *dane = SSL_get_ex_data(ssl, dane_idx);
+X509 *cert = ctx->cert; /* XXX: accessor? */
+int matched = 0;
+int chain_length = sk_X509_num(ctx->chain);
+
+DEBUG(D_tls) debug_printf("Dane verify-chain\n");
+
+issuer_rrs = dane->selectors[SSL_DANE_USAGE_LIMIT_ISSUER];
+leaf_rrs = dane->selectors[SSL_DANE_USAGE_LIMIT_LEAF];
+ctx->verify = dane->verify;
+
+if((matched = name_check(dane, cert)) < 0)
+ {
+ X509_STORE_CTX_set_error(ctx, X509_V_ERR_OUT_OF_MEM);
+ return 0;
+ }
+
+if(!matched)
+ {
+ ctx->error_depth = 0;
+ ctx->current_cert = cert;
+ X509_STORE_CTX_set_error(ctx, X509_V_ERR_HOSTNAME_MISMATCH);
+ if(!cb(0, ctx))
+ return 0;
+ }
+matched = 0;
+
+/*
+ * Satisfy at least one usage 0 or 1 constraint, unless we've already
+ * matched a usage 2 trust anchor.
+ *
+ * XXX: internal_verify() doesn't callback with top certs that are not
+ * self-issued. This should be fixed in a future OpenSSL.
+ */
+if(dane->roots && sk_X509_num(dane->roots))
+ {
+#ifndef NO_CALLBACK_WORKAROUND
+ X509 *top = sk_X509_value(ctx->chain, dane->depth);
+
+ if(X509_check_issued(top, top) != X509_V_OK)
+ {
+ ctx->error_depth = dane->depth;
+ ctx->current_cert = top;
+ if(!cb(1, ctx))
+ return 0;
+ }
+#endif
+ /* Pop synthetic trust-anchor ancestors off the chain! */
+ while (--chain_length > dane->depth)
+ X509_free(sk_X509_pop(ctx->chain));
+ }
+else if(issuer_rrs || leaf_rrs)
+ {
+ int n = chain_length;
+
+ /*
+ * Check for an EE match, then a CA match at depths > 0, and
+ * finally, if the EE cert is self-issued, for a depth 0 CA match.
+ */
+ if(leaf_rrs)
+ matched = match(leaf_rrs, cert, 0);
+ while(!matched && issuer_rrs && --n >= 0)
+ {
+ X509 *xn = sk_X509_value(ctx->chain, n);
+
+ if(n > 0 || X509_check_issued(xn, xn) == X509_V_OK)
+ matched = match(issuer_rrs, xn, n);
+ }
+
+ if(matched < 0)
+ {
+ X509_STORE_CTX_set_error(ctx, X509_V_ERR_OUT_OF_MEM);
+ return 0;
+ }
+
+ if(!matched)
+ {
+ ctx->current_cert = cert;
+ ctx->error_depth = 0;
+ X509_STORE_CTX_set_error(ctx, X509_V_ERR_CERT_UNTRUSTED);
+ if(!cb(0, ctx))
+ return 0;
+ }
+ }
+
+return ctx->verify(ctx);
+}
+
+static int
+verify_cert(X509_STORE_CTX *ctx, void *unused_ctx)
+{
+static int ssl_idx = -1;
+SSL *ssl;
+ssl_dane *dane;
+int (*cb)(int, X509_STORE_CTX *) = ctx->verify_cb;
+int matched;
+X509 *cert = ctx->cert; /* XXX: accessor? */
+
+DEBUG(D_tls) debug_printf("Dane verify-cert\n");
+
+if(ssl_idx < 0)
+ ssl_idx = SSL_get_ex_data_X509_STORE_CTX_idx();
+if(dane_idx < 0)
+ {
+ DANEerr(DANE_F_VERIFY_CERT, ERR_R_MALLOC_FAILURE);
+ return -1;
+ }
+
+ssl = X509_STORE_CTX_get_ex_data(ctx, ssl_idx);
+if(!(dane = SSL_get_ex_data(ssl, dane_idx)) || !cert)
+ return X509_verify_cert(ctx);
+
+if(dane->selectors[SSL_DANE_USAGE_FIXED_LEAF])
+ {
+ if((matched = check_end_entity(ctx, dane, cert)) > 0)
+ {
+ ctx->error_depth = 0;
+ ctx->current_cert = cert;
+ return cb(1, ctx);
+ }
+ if(matched < 0)
+ {
+ X509_STORE_CTX_set_error(ctx, X509_V_ERR_OUT_OF_MEM);
+ return -1;
+ }
+ }
+
+if(dane->selectors[SSL_DANE_USAGE_TRUSTED_CA])
+ {
+ if((matched = set_trust_anchor(ctx, dane, cert)) < 0)
+ {
+ X509_STORE_CTX_set_error(ctx, X509_V_ERR_OUT_OF_MEM);
+ return -1;
+ }
+ if(matched)
+ {
+ /*
+ * Check that setting the untrusted chain updates the expected
+ * structure member at the expected offset.
+ */
+ X509_STORE_CTX_trusted_stack(ctx, dane->roots);
+ X509_STORE_CTX_set_chain(ctx, dane->chain);
+ OPENSSL_assert(ctx->untrusted == dane->chain);
+ }
+ }
+
+/*
+ * Name checks and usage 0/1 constraint enforcement are delayed until
+ * X509_verify_cert() builds the full chain and calls our verify_chain()
+ * wrapper.
+ */
+dane->verify = ctx->verify;
+ctx->verify = verify_chain;
+
+return X509_verify_cert(ctx);
+}
+
+static dane_list
+list_alloc(size_t vsize)
+{
+void *value = (void *) OPENSSL_malloc(vsize);
+dane_list l;
+
+if(!value)
+ {
+ DANEerr(DANE_F_LIST_ALLOC, ERR_R_MALLOC_FAILURE);
+ return 0;
+ }
+if(!(l = (dane_list) OPENSSL_malloc(sizeof(*l))))
+ {
+ OPENSSL_free(value);
+ DANEerr(DANE_F_LIST_ALLOC, ERR_R_MALLOC_FAILURE);
+ return 0;
+ }
+l->next = 0;
+l->value = value;
+return l;
+}
+
+static void
+list_free(void *list, void (*f)(void *))
+{
+dane_list head;
+dane_list next;
+
+for(head = (dane_list) list; head; head = next)
+ {
+ next = head->next;
+ if (f && head->value)
+ f(head->value);
+ OPENSSL_free(head);
+ }
+}
+
+static void
+dane_mtype_free(void *p)
+{
+list_free(((dane_mtype) p)->data, OPENSSL_freeFunc);
+OPENSSL_free(p);
+}
+
+static void
+dane_selector_free(void *p)
+{
+list_free(((dane_selector) p)->mtype, dane_mtype_free);
+OPENSSL_free(p);
+}
+
+
+
+/*
+
+Tidy up once the connection is finished with.
+
+Arguments
+ ssl The ssl connection handle
+
+=> Before calling SSL_free()
+tls_close() and tls_getc() [the error path] are the obvious places.
+Could we do it earlier - right after verification? In tls_client_start()
+right after SSL_connect() returns, in that case.
+
+*/
+
+void
+DANESSL_cleanup(SSL *ssl)
+{
+ssl_dane *dane;
+int u;
+
+DEBUG(D_tls) debug_printf("Dane lib-cleanup\n");
+
+if(dane_idx < 0 || !(dane = SSL_get_ex_data(ssl, dane_idx)))
+ return;
+(void) SSL_set_ex_data(ssl, dane_idx, 0);
+
+if(dane->hosts)
+ list_free(dane->hosts, OPENSSL_freeFunc);
+if(dane->mhost)
+ OPENSSL_free(dane->mhost);
+for(u = 0; u <= SSL_DANE_USAGE_LAST; ++u)
+ if(dane->selectors[u])
+ list_free(dane->selectors[u], dane_selector_free);
+if(dane->pkeys)
+ list_free(dane->pkeys, pkey_free);
+if(dane->certs)
+ list_free(dane->certs, cert_free);
+if(dane->roots)
+ sk_X509_pop_free(dane->roots, X509_free);
+if(dane->chain)
+ sk_X509_pop_free(dane->chain, X509_free);
+OPENSSL_free(dane);
+}
+
+static dane_host_list
+host_list_init(const char **src)
+{
+dane_host_list head = NULL;
+
+while(*src)
+ {
+ dane_host_list elem = (dane_host_list) OPENSSL_malloc(sizeof(*elem));
+ if(!elem)
+ {
+ list_free(head, OPENSSL_freeFunc);
+ return 0;
+ }
+ elem->value = OPENSSL_strdup(*src++);
+ LINSERT(head, elem);
+ }
+return head;
+}
+
+
+
+
+/*
+
+Call this for each TLSA record found for the target, after the
+DANE setup has been done on the ssl connection handle.
+
+Arguments:
+ ssl Connection handle
+ usage TLSA record field
+ selector TLSA record field
+ mdname ??? message digest name?
+ data ??? TLSA record megalump?
+ dlen length of data
+
+Return
+ -1 on error
+ 0 action not taken
+ 1 record accepted
+*/
+
+int
+DANESSL_add_tlsa(SSL *ssl, uint8_t usage, uint8_t selector, const char *mdname,
+ unsigned const char *data, size_t dlen)
+{
+ssl_dane *dane;
+dane_selector_list s = 0;
+dane_mtype_list m = 0;
+dane_data_list d = 0;
+dane_cert_list xlist = 0;
+dane_pkey_list klist = 0;
+const EVP_MD *md = 0;
+
+DEBUG(D_tls) debug_printf("Dane add-tlsa: usage %u sel %u mdname \"%s\"\n",
+ usage, selector, mdname);
+
+if(dane_idx < 0 || !(dane = SSL_get_ex_data(ssl, dane_idx)))
+ {
+ DANEerr(DANE_F_SSL_DANE_ADD_TLSA, DANE_R_DANE_INIT);
+ return -1;
+ }
+
+if(usage > SSL_DANE_USAGE_LAST)
+ {
+ DANEerr(DANE_F_SSL_DANE_ADD_TLSA, DANE_R_BAD_USAGE);
+ return 0;
+ }
+if(selector > SSL_DANE_SELECTOR_LAST)
+ {
+ DANEerr(DANE_F_SSL_DANE_ADD_TLSA, DANE_R_BAD_SELECTOR);
+ return 0;
+ }
+if(mdname && !(md = EVP_get_digestbyname(mdname)))
+ {
+ DANEerr(DANE_F_SSL_DANE_ADD_TLSA, DANE_R_BAD_DIGEST);
+ return 0;
+ }
+if(!data)
+ {
+ DANEerr(DANE_F_SSL_DANE_ADD_TLSA, DANE_R_BAD_NULL_DATA);
+ return 0;
+ }
+if(mdname && dlen != EVP_MD_size(md))
+ {
+ DANEerr(DANE_F_SSL_DANE_ADD_TLSA, DANE_R_BAD_DATA_LENGTH);
+ return 0;
+ }
+
+if(!mdname)
+ {
+ X509 *x = 0;
+ EVP_PKEY *k = 0;
+ const unsigned char *p = data;
+
+#define xklistinit(lvar, ltype, var, freeFunc) do { \
+ (lvar) = (ltype) OPENSSL_malloc(sizeof(*(lvar))); \
+ if (!(lvar)) { \
+ DANEerr(DANE_F_SSL_DANE_ADD_TLSA, ERR_R_MALLOC_FAILURE); \
+ freeFunc((var)); \
+ return 0; \
+ } \
+ (lvar)->next = 0; \
+ lvar->value = var; \
+ } while (0)
+#define xkfreeret(ret) do { \
+ if (xlist) list_free(xlist, cert_free); \
+ if (klist) list_free(klist, pkey_free); \
+ return (ret); \
+ } while (0)
+
+ switch(selector)
+ {
+ case SSL_DANE_SELECTOR_CERT:
+ if(!d2i_X509(&x, &p, dlen) || dlen != p - data)
+ {
+ if (x)
+ X509_free(x);
+ DANEerr(DANE_F_SSL_DANE_ADD_TLSA, DANE_R_BAD_CERT);
+ return 0;
+ }
+ k = X509_get_pubkey(x);
+ EVP_PKEY_free(k);
+ if(!k)
+ {
+ X509_free(x);
+ DANEerr(DANE_F_SSL_DANE_ADD_TLSA, DANE_R_BAD_CERT_PKEY);
+ return 0;
+ }
+ if(usage == SSL_DANE_USAGE_TRUSTED_CA)
+ xklistinit(xlist, dane_cert_list, x, X509_free);
+ break;
+
+ case SSL_DANE_SELECTOR_SPKI:
+ if(!d2i_PUBKEY(&k, &p, dlen) || dlen != p - data)
+ {
+ if(k)
+ EVP_PKEY_free(k);
+ DANEerr(DANE_F_SSL_DANE_ADD_TLSA, DANE_R_BAD_PKEY);
+ return 0;
+ }
+ if(usage == SSL_DANE_USAGE_TRUSTED_CA)
+ xklistinit(klist, dane_pkey_list, k, EVP_PKEY_free);
+ break;
+ }
+ }
+
+/* Find insertion point and don't add duplicate elements. */
+for(s = dane->selectors[usage]; s; s = s->next)
+ if(s->value->selector == selector)
+ for(m = s->value->mtype; m; m = m->next)
+ if(m->value->md == md)
+ for(d = m->value->data; d; d = d->next)
+ if( d->value->datalen == dlen
+ && memcmp(d->value->data, data, dlen) == 0)
+ xkfreeret(1);
+
+if(!(d = (dane_data_list) list_alloc(sizeof(*d->value) + dlen)))
+ xkfreeret(0);
+d->value->datalen = dlen;
+memcpy(d->value->data, data, dlen);
+if(!m)
+ {
+ if(!(m = (dane_mtype_list) list_alloc(sizeof(*m->value))))
+ {
+ list_free(d, OPENSSL_freeFunc);
+ xkfreeret(0);
+ }
+ m->value->data = 0;
+ if((m->value->md = md) != 0)
+ m->value->mdlen = dlen;
+ if(!s)
+ {
+ if(!(s = (dane_selector_list) list_alloc(sizeof(*s->value))))
+ {
+ list_free(m, dane_mtype_free);
+ xkfreeret(0);
+ }
+ s->value->mtype = 0;
+ s->value->selector = selector;
+ LINSERT(dane->selectors[usage], s);
+ }
+ LINSERT(s->value->mtype, m);
+ }
+LINSERT(m->value->data, d);
+
+if(xlist)
+ LINSERT(dane->certs, xlist);
+else if(klist)
+ LINSERT(dane->pkeys, klist);
+++dane->count;
+return 1;
+}
+
+
+
+
+/*
+Call this once we have an ssl connection handle but before
+making the TLS connection.
+
+=> In tls_client_start() after the call to SSL_new()
+and before the call to SSL_connect(). Exactly where
+probably does not matter.
+We probably want to keep our existing SNI handling;
+call this with NULL.
+
+Arguments:
+ ssl Connection handle
+ sni_domain Optional peer server name
+ hostnames list of names to chack against peer cert
+
+Return
+ -1 on fatal error
+ 0 nonfatal error
+ 1 success
+*/
+
+int
+DANESSL_init(SSL *ssl, const char *sni_domain, const char **hostnames)
+{
+ssl_dane *dane;
+int i;
+#ifdef OPENSSL_INTERNAL
+SSL_CTX *sctx = SSL_get_SSL_CTX(ssl);
+
+
+if(sctx->app_verify_callback != verify_cert)
+ {
+ DANEerr(DANE_F_SSL_DANE_INIT, DANE_R_SCTX_INIT);
+ return -1;
+ }
+#else
+DEBUG(D_tls) debug_printf("Dane ssl-init\n");
+if(dane_idx < 0)
+ {
+ DANEerr(DANE_F_SSL_DANE_INIT, DANE_R_LIBRARY_INIT);
+ return -1;
+ }
+#endif
+
+if(sni_domain && !SSL_set_tlsext_host_name(ssl, sni_domain))
+ return 0;
+
+if(!(dane = (ssl_dane *) OPENSSL_malloc(sizeof(ssl_dane))))
+ {
+ DANEerr(DANE_F_SSL_DANE_INIT, ERR_R_MALLOC_FAILURE);
+ return 0;
+ }
+if(!SSL_set_ex_data(ssl, dane_idx, dane))
+ {
+ DANEerr(DANE_F_SSL_DANE_INIT, ERR_R_MALLOC_FAILURE);
+ OPENSSL_free(dane);
+ return 0;
+ }
+
+dane->verify = 0;
+dane->hosts = 0;
+dane->thost = 0;
+dane->pkeys = 0;
+dane->certs = 0;
+dane->chain = 0;
+dane->roots = 0;
+dane->depth = -1;
+dane->mhost = 0; /* Future SSL control interface */
+dane->multi = 0; /* Future SSL control interface */
+dane->count = 0;
+
+for(i = 0; i <= SSL_DANE_USAGE_LAST; ++i)
+ dane->selectors[i] = 0;
+
+if(hostnames && !(dane->hosts = host_list_init(hostnames)))
+ {
+ DANEerr(DANE_F_SSL_DANE_INIT, ERR_R_MALLOC_FAILURE);
+ DANESSL_cleanup(ssl);
+ return 0;
+ }
+
+return 1;
+}
+
+
+/*
+
+Call this once we have a context to work with, but
+before DANESSL_init()
+
+=> in tls_client_start(), after tls_init() call gives us the ctx,
+if we decide we want to (policy) and can (TLSA records available)
+replacing (? what about fallback) everything from testing tls_verify_hosts
+down to just before calling SSL_new() for the conn handle.
+
+Arguments
+ ctx SSL context
+
+Return
+ -1 Error
+ 1 Success
+*/
+
+int
+DANESSL_CTX_init(SSL_CTX *ctx)
+{
+DEBUG(D_tls) debug_printf("Dane ctx-init\n");
+if(dane_idx >= 0)
+ {
+ SSL_CTX_set_cert_verify_callback(ctx, verify_cert, 0);
+ return 1;
+ }
+DANEerr(DANE_F_SSL_CTX_DANE_INIT, DANE_R_LIBRARY_INIT);
+return -1;
+}
+
+static int
+init_once(volatile int *value, int (*init)(void), void (*postinit)(void))
+{
+int wlock = 0;
+
+CRYPTO_r_lock(CRYPTO_LOCK_SSL_CTX);
+if(*value < 0)
+ {
+ CRYPTO_r_unlock(CRYPTO_LOCK_SSL_CTX);
+ CRYPTO_w_lock(CRYPTO_LOCK_SSL_CTX);
+ wlock = 1;
+ if(*value < 0)
+ {
+ *value = init();
+ if(postinit)
+ postinit();
+ }
+ }
+if (wlock)
+ CRYPTO_w_unlock(CRYPTO_LOCK_SSL_CTX);
+else
+ CRYPTO_r_unlock(CRYPTO_LOCK_SSL_CTX);
+return *value;
+}
+
+static void
+dane_init(void)
+{
+/*
+ * Store library id in zeroth function slot, used to locate the library
+ * name. This must be done before we load the error strings.
+ */
+#ifndef OPENSSL_NO_ERR
+dane_str_functs[0].error |= ERR_PACK(err_lib_dane, 0, 0);
+ERR_load_strings(err_lib_dane, dane_str_functs);
+ERR_load_strings(err_lib_dane, dane_str_reasons);
+#endif
+
+/*
+ * Register SHA-2 digests, if implemented and not already registered.
+ */
+#if defined(LN_sha256) && defined(NID_sha256) && !defined(OPENSSL_NO_SHA256)
+if(!EVP_get_digestbyname(LN_sha224)) EVP_add_digest(EVP_sha224());
+if(!EVP_get_digestbyname(LN_sha256)) EVP_add_digest(EVP_sha256());
+#endif
+#if defined(LN_sha512) && defined(NID_sha512) && !defined(OPENSSL_NO_SHA512)
+if(!EVP_get_digestbyname(LN_sha384)) EVP_add_digest(EVP_sha384());
+if(!EVP_get_digestbyname(LN_sha512)) EVP_add_digest(EVP_sha512());
+#endif
+
+/*
+ * Register an SSL index for the connection-specific ssl_dane structure.
+ * Using a separate index makes it possible to add DANE support to
+ * existing OpenSSL releases that don't have a suitable pointer in the
+ * SSL structure.
+ */
+dane_idx = SSL_get_ex_new_index(0, 0, 0, 0, 0);
+}
+
+
+
+/*
+
+Call this once. Probably early in startup will do; may need
+to be after SSL library init.
+
+=> put after call to tls_init() for now
+
+Return
+ 1 Success
+ 0 Fail
+*/
+
+int
+DANESSL_library_init(void)
+{
+DEBUG(D_tls) debug_printf("Dane lib-init\n");
+if(err_lib_dane < 0)
+ init_once(&err_lib_dane, ERR_get_next_error_library, dane_init);
+
+#if defined(LN_sha256)
+/* No DANE without SHA256 support */
+if(dane_idx >= 0 && EVP_get_digestbyname(LN_sha256) != 0)
+ return 1;
+#endif
+
+DANEerr(DANE_F_SSL_DANE_LIBRARY_INIT, DANE_R_DANE_SUPPORT);
+return 0;
+}
+
+
+#endif /* OPENSSL_VERSION_NUMBER */
+/* vi: aw ai sw=2
+*/
--- /dev/null
+/*************************************************
+* Exim - an Internet mail transport agent *
+*************************************************/
+
+/* Copyright (c) University of Cambridge 1995 - 2012, 2014 */
+/* See the file NOTICE for conditions of use and distribution. */
+
+/* This module provides DANE (RFC6659) support for Exim. See also
+the draft RFC for DANE-over-SMTP, "SMTP security via opportunistic DANE TLS"
+(V. Dukhovni, W. Hardaker) - version 10, dated May 25, 2014.
+
+The code for DANE support with Openssl was provided by V.Dukhovni.
+
+No cryptographic code is included in Exim. All this module does is to call
+functions from the OpenSSL or GNU TLS libraries. */
+
+
+#include "exim.h"
+
+/* This module is compiled only when it is specifically requested in the
+build-time configuration. However, some compilers don't like compiling empty
+modules, so keep them happy with a dummy when skipping the rest. Make it
+reference itself to stop picky compilers complaining that it is unused, and put
+in a dummy argument to stop even pickier compilers complaining about infinite
+loops. */
+
+#ifndef EXPERIMENTAL_DANE
+static void dummy(int x) { dummy(x-1); }
+#else
+
+/* Enabling DANE without enabling TLS cannot work. Abort the compilation. */
+# ifndef SUPPORT_TLS
+# error DANE support requires that TLS support must be enabled. Abort build.
+# endif
+
+# ifdef USE_GNUTLS
+# include "dane-gnu.c"
+# else
+# include "dane-openssl.c"
+# endif
+
+
+#endif /* EXPERIMENTAL_DANE */
+
+/* End of dane.c */
--- /dev/null
+#ifndef HEADER_SSL_DANE_H
+#define HEADER_SSL_DANE_H
+
+#include <stdint.h>
+#include <openssl/ssl.h>
+
+/*-
+ * Certificate usages:
+ * https://tools.ietf.org/html/rfc6698#section-2.1.1
+ */
+#define SSL_DANE_USAGE_LIMIT_ISSUER 0
+#define SSL_DANE_USAGE_LIMIT_LEAF 1
+#define SSL_DANE_USAGE_TRUSTED_CA 2
+#define SSL_DANE_USAGE_FIXED_LEAF 3
+#define SSL_DANE_USAGE_LAST SSL_DANE_USAGE_FIXED_LEAF
+
+/*-
+ * Selectors:
+ * https://tools.ietf.org/html/rfc6698#section-2.1.2
+ */
+#define SSL_DANE_SELECTOR_CERT 0
+#define SSL_DANE_SELECTOR_SPKI 1
+#define SSL_DANE_SELECTOR_LAST SSL_DANE_SELECTOR_SPKI
+
+extern int DANESSL_library_init(void);
+extern int DANESSL_CTX_init(SSL_CTX *);
+extern int DANESSL_init(SSL *, const char *, const char **);
+extern void DANESSL_cleanup(SSL *);
+extern int DANESSL_add_tlsa(SSL *, uint8_t, uint8_t, const char *,
+ unsigned const char *, size_t);
+#endif
if ((log_extra_selector & LX_tls_certificate_verified) != 0 &&
addr->cipher != NULL)
s = string_append(s, sizep, ptrp, 2, US" CV=",
- testflag(addr, af_cert_verified)? "yes":"no");
+ testflag(addr, af_cert_verified)
+ ?
+#ifdef EXPERIMENTAL_DANE
+ testflag(addr, af_dane_verified)
+ ? "dane"
+ :
+#endif
+ "yes"
+ : "no");
if ((log_extra_selector & LX_tls_peerdn) != 0 && addr->peerdn != NULL)
s = string_append(s, sizep, ptrp, 3, US" DN=\"",
string_printing(addr->peerdn), US"\"");
tls_out.cipher = addr->cipher;
tls_out.peerdn = addr->peerdn;
tls_out.ocsp = addr->ocsp;
+# ifdef EXPERIMENTAL_DANE
+ tls_out.dane_verified = testflag(addr, af_dane_verified);
+# endif
#endif
delivery_log(LOG_MAIN, addr, logchar, NULL);
tls_out.cipher = NULL;
tls_out.peerdn = NULL;
tls_out.ocsp = OCSP_NOT_REQ;
+# ifdef EXPERIMENTAL_DANE
+ tls_out.dane_verified = FALSE;
+# endif
#endif
}
/* The certificate verification status goes into the flags */
if (tls_out.certificate_verified) setflag(addr, af_cert_verified);
+#ifdef EXPERIMENTAL_DANE
+ if (tls_out.dane_verified) setflag(addr, af_dane_verified);
+#endif
/* Use an X item only if there's something to send */
#ifdef SUPPORT_TLS
{
struct stat statbuf;
if (fstat(deliver_datafile, &statbuf) == 0 && statbuf.st_size > max)
+ {
if (emf_text)
fprintf(f, "%s", CS emf_text);
else
fprintf(f,
"------ The body of the message is " OFF_T_FMT " characters long; only the first\n"
"------ %d or so are included here.\n", statbuf.st_size, max);
+ }
}
fputc('\n', f);
/* For an SRV lookup, skip over the first two components (the service and
protocol names, which both start with an underscore). */
- if (type == T_SRV)
+ if (type == T_SRV || type == T_TLSA)
{
while (*checkname++ != '.');
while (*checkname++ != '.');
#ifdef EXPERIMENTAL_BRIGHTMAIL
fprintf(f, " Experimental_Brightmail");
#endif
+#ifdef EXPERIMENTAL_DANE
+ fprintf(f, " Experimental_DANE");
+#endif
#ifdef EXPERIMENTAL_DCC
fprintf(f, " Experimental_DCC");
#endif
{ "tls_out_bits", vtype_int, &tls_out.bits },
{ "tls_out_certificate_verified", vtype_int,&tls_out.certificate_verified },
{ "tls_out_cipher", vtype_stringptr, &tls_out.cipher },
+#ifdef EXPERIMENTAL_DANE
+ { "tls_out_dane", vtype_bool, &tls_out.dane_verified },
+#endif
{ "tls_out_ocsp", vtype_int, &tls_out.ocsp },
{ "tls_out_ourcert", vtype_cert, &tls_out.ourcert },
{ "tls_out_peercert", vtype_cert, &tls_out.peercert },
#if defined(SUPPORT_TLS)
{ "tls_out_sni", vtype_stringptr, &tls_out.sni },
#endif
+#ifdef EXPERIMENTAL_DANE
+ { "tls_out_tlsa_usage", vtype_int, &tls_out.tlsa_usage },
+#endif
{ "tls_peerdn", vtype_stringptr, &tls_in.peerdn }, /* mind the alphabetical order! */
#if defined(SUPPORT_TLS)
-1, /* tls_active */
0, /* tls_bits */
FALSE,/* tls_certificate_verified */
+#ifdef EXPERIMENTAL_DANE
+ FALSE,/* dane_verified */
+ 0, /* tlsa_usage */
+#endif
NULL, /* tls_cipher */
FALSE,/* tls_on_connect */
NULL, /* tls_on_connect_ports */
-1, /* tls_active */
0, /* tls_bits */
FALSE,/* tls_certificate_verified */
+#ifdef EXPERIMENTAL_DANE
+ FALSE,/* dane_verified */
+ 0, /* tlsa_usage */
+#endif
NULL, /* tls_cipher */
FALSE,/* tls_on_connect */
NULL, /* tls_on_connect_ports */
uschar *dns_again_means_nonexist = NULL;
int dns_csa_search_limit = 5;
BOOL dns_csa_use_reverse = TRUE;
+#ifdef EXPERIMENTAL_DANE
+int dns_dane_ok = -1;
+#endif
uschar *dns_ipv4_lookup = NULL;
int dns_retrans = 0;
int dns_retry = 0;
TRUE_UNSET /* retry_use_local_part: BOOL, but set neither
1 nor 0 so can detect unset */
#ifdef EXPERIMENTAL_TPDA
- ,NULL /* tpda_delivery_action */
+ ,NULL /* tpda_event_action */
#endif
};
int active; /* fd/socket when in a TLS session */
int bits; /* bits used in TLS session */
BOOL certificate_verified; /* Client certificate verified */
+#ifdef EXPERIMENTAL_DANE
+ BOOL dane_verified; /* ... via DANE */
+ int tlsa_usage; /* TLSA record(s) usage */
+#endif
uschar *cipher; /* Cipher used */
BOOL on_connect; /* For older MTAs that don't STARTTLS */
uschar *on_connect_ports; /* Ports always tls-on-connect */
extern int dns_csa_search_limit; /* How deep to search for CSA SRV records */
extern BOOL dns_csa_use_reverse; /* Check CSA in reverse DNS? (non-standard) */
extern uschar *dns_ipv4_lookup; /* For these domains, don't look for AAAA (or A6) */
+#ifdef EXPERIMENTAL_DANE
+extern int dns_dane_ok; /* Ok to use DANE when checking TLS authenticity */
+#endif
extern int dns_retrans; /* Retransmission time setting */
extern int dns_retry; /* Number of retries */
extern int dns_dnssec_ok; /* When constructing DNS query, set DO flag */
static int
set_address_from_dns(host_item *host, host_item **lastptr,
uschar *ignore_target_hosts, BOOL allow_ip, uschar **fully_qualified_name,
- BOOL dnssec_requested, BOOL dnssec_require)
+ BOOL dnssec_request, BOOL dnssec_require)
{
dns_record *rr;
host_item *thishostlast = NULL; /* Indicates not yet filled in anything */
dns_scan dnss;
int rc = dns_lookup(&dnsa, host->name, type, fully_qualified_name);
- lookup_dnssec_authenticated = !dnssec_requested ? NULL
+ lookup_dnssec_authenticated = !dnssec_request ? NULL
: dns_is_secure(&dnsa) ? US"yes" : US"no";
/* We want to return HOST_FIND_AGAIN if one of the A, A6, or AAAA lookups
if (rc != DNS_NOMATCH && rc != DNS_NODATA) v6_find_again = TRUE;
continue;
}
- if (dnssec_require && !dns_is_secure(&dnsa))
+
+ if (dnssec_request)
{
- log_write(L_host_lookup_failed, LOG_MAIN, "dnssec fail on %s for %.256s",
+ if (dns_is_secure(&dnsa))
+ {
+ DEBUG(D_host_lookup) debug_printf("%s A DNSSEC\n", host->name);
+ if (host->dnssec == DS_UNK) /* set in host_find_bydns() */
+ host->dnssec = DS_YES;
+ }
+ else
+ {
+ if (dnssec_require)
+ {
+ log_write(L_host_lookup_failed, LOG_MAIN,
+ "dnssec fail on %s for %.256s",
i>1 ? "A6" : i>0 ? "AAAA" : "A", host->name);
- continue;
+ continue;
+ }
+ if (host->dnssec == DS_YES) /* set in host_find_bydns() */
+ {
+ DEBUG(D_host_lookup) debug_printf("%s A cancel DNSSEC\n", host->name);
+ host->dnssec = DS_NO;
+ lookup_dnssec_authenticated = US"no";
+ }
+ }
}
/* Lookup succeeded: fill in the given host item with the first non-ignored
if (dnssec_request)
{
if (dns_is_secure(&dnsa))
- { dnssec = DS_YES; lookup_dnssec_authenticated = US"yes"; }
+ {
+ DEBUG(D_host_lookup) debug_printf("%s MX DNSSEC\n", host->name);
+ dnssec = DS_YES; lookup_dnssec_authenticated = US"yes";
+ }
else
- { dnssec = DS_NO; lookup_dnssec_authenticated = US"no"; }
+ {
+ dnssec = DS_NO; lookup_dnssec_authenticated = US"no";
+ }
}
switch (rc)
log_write(L_host_lookup_failed, LOG_MAIN,
"dnssec fail on MX for %.256s", host->name);
rc = DNS_FAIL;
- /*FALLTRHOUGH*/
+ /*FALLTHROUGH*/
case DNS_FAIL:
case DNS_AGAIN:
last = host; /* End of local chainlet */
host->mx = MX_NONE;
host->port = PORT_NONE;
- dnssec = DS_UNK;
+ host->dnssec = DS_UNK;
lookup_dnssec_authenticated = NULL;
rc = set_address_from_dns(host, &last, ignore_target_hosts, FALSE,
fully_qualified_name, dnssec_request, dnssec_require);
- if (dnssec_request)
- {
- if (dns_is_secure(&dnsa))
- { dnssec = DS_YES; lookup_dnssec_authenticated = US"yes"; }
- else
- { dnssec = DS_NO; lookup_dnssec_authenticated = US"no"; }
- }
-
/* If one or more address records have been found, check that none of them
are local. Since we know the host items all have their IP addresses
inserted, host_scan_for_local_hosts() can only return HOST_FOUND or
#ifdef SUPPORT_TLS
tls_in.certificate_verified = FALSE;
+# ifdef EXPERIMENTAL_DANE
+tls_in.dane_verified = FALSE;
+# endif
tls_in.cipher = NULL;
tls_in.ourcert = NULL;
tls_in.peercert = NULL;
if (Ustrncmp(p, "rozen", 5) == 0)
{
deliver_freeze = TRUE;
- sscanf(big_buffer+7, TIME_T_FMT, &deliver_frozen_at);
+ sscanf(CS big_buffer+7, TIME_T_FMT, &deliver_frozen_at);
}
break;
# define af_prdr_used 0x08000000 /* delivery used SMTP PRDR */
#endif
#define af_force_command 0x10000000 /* force_command in pipe transport */
+#ifdef EXPERIMENTAL_DANE
+# define af_dane_verified 0x20000000 /* TLS cert verify done with DANE */
+#endif
/* These flags must be propagated when a child is created */
#ifndef DISABLE_OCSP
# include <openssl/ocsp.h>
#endif
+#ifdef EXPERIMENTAL_DANE
+# include <danessl.h>
+#endif
+
#ifndef DISABLE_OCSP
# define EXIM_OCSP_SKEW_SECONDS (300L)
}
+#ifdef EXPERIMENTAL_DANE
+
+/* This gets called *by* the dane library verify callback, which interposes
+itself.
+*/
+static int
+verify_callback_client_dane(int state, X509_STORE_CTX * x509ctx)
+{
+X509 * cert = X509_STORE_CTX_get_current_cert(x509ctx);
+static uschar txt[256];
+#ifdef EXPERIMENTAL_TPDA
+int depth = X509_STORE_CTX_get_error_depth(x509ctx);
+#endif
+
+X509_NAME_oneline(X509_get_subject_name(cert), CS txt, sizeof(txt));
+
+DEBUG(D_tls) debug_printf("verify_callback_client_dane: %s\n", txt);
+tls_out.peerdn = txt;
+tls_out.peercert = X509_dup(cert);
+
+#ifdef EXPERIMENTAL_TPDA
+ if (client_static_cbinfo->event_action)
+ {
+ if (tpda_raise_event(client_static_cbinfo->event_action,
+ US"tls:cert", string_sprintf("%d", depth)) == DEFER)
+ {
+ log_write(0, LOG_MAIN, "DANE verify denied by event-action: "
+ "depth=%d cert=%s", depth, txt);
+ tls_out.certificate_verified = FALSE;
+ return 0; /* reject */
+ }
+ if (depth != 0)
+ {
+ X509_free(tls_out.peercert);
+ tls_out.peercert = NULL;
+ }
+ }
+#endif
+
+if (state == 1)
+ tls_out.dane_verified =
+ tls_out.certificate_verified = TRUE;
+return 1;
+}
+
+#endif /*EXPERIMENTAL_DANE*/
+
/*************************************************
* Information callback *
#endif /*!DISABLE_OCSP*/
-
/*************************************************
* Initialize for TLS *
*************************************************/
of the library. We allocate and return a context structure.
Arguments:
+ ctxp returned SSL context
host connected host, if client; NULL if server
dhparam DH parameter file
certificate certificate file
privatekey private key
ocsp_file file of stapling info (server); flag for require ocsp (client)
addr address if client; NULL if server (for some randomness)
- cbp place to put allocated context
+ cbp place to put allocated callback context
Returns: OK/DEFER/FAIL
*/
optional, set up appropriately. */
tls_in.certificate_verified = FALSE;
+#ifdef EXPERIMENTAL_DANE
+tls_in.dane_verified = FALSE;
+#endif
server_verify_callback_called = FALSE;
if (verify_check_host(&tls_verify_hosts) == OK)
+static int
+tls_client_basic_ctx_init(SSL_CTX * ctx,
+ host_item * host, smtp_transport_options_block * ob
+#ifdef EXPERIMENTAL_CERTNAMES
+ , tls_ext_ctx_cb * cbinfo
+#endif
+ )
+{
+int rc;
+/* stick to the old behaviour for compatibility if tls_verify_certificates is
+ set but both tls_verify_hosts and tls_try_verify_hosts is not set. Check only
+ the specified host patterns if one of them is defined */
+
+if ((!ob->tls_verify_hosts && !ob->tls_try_verify_hosts) ||
+ (verify_check_host(&ob->tls_verify_hosts) == OK))
+ {
+ if ((rc = setup_certs(ctx, ob->tls_verify_certificates,
+ ob->tls_crl, host, FALSE, verify_callback_client)) != OK)
+ return rc;
+ client_verify_optional = FALSE;
+
+#ifdef EXPERIMENTAL_CERTNAMES
+ if (ob->tls_verify_cert_hostnames)
+ {
+ if (!expand_check(ob->tls_verify_cert_hostnames,
+ US"tls_verify_cert_hostnames",
+ &cbinfo->verify_cert_hostnames))
+ return FAIL;
+ if (cbinfo->verify_cert_hostnames)
+ DEBUG(D_tls) debug_printf("Cert hostname to check: \"%s\"\n",
+ cbinfo->verify_cert_hostnames);
+ }
+#endif
+ }
+else if (verify_check_host(&ob->tls_try_verify_hosts) == OK)
+ {
+ if ((rc = setup_certs(ctx, ob->tls_verify_certificates,
+ ob->tls_crl, host, TRUE, verify_callback_client)) != OK)
+ return rc;
+ client_verify_optional = TRUE;
+ }
+
+return OK;
+}
+
+
+#ifdef EXPERIMENTAL_DANE
+static int
+tlsa_lookup(host_item * host, dns_answer * dnsa,
+ BOOL dane_required, BOOL * dane)
+{
+/* move this out to host.c given the similarity to dns_lookup() ? */
+uschar buffer[300];
+uschar * fullname = buffer;
+
+/* TLSA lookup string */
+(void)sprintf(CS buffer, "_%d._tcp.%.256s", host->port, host->name);
+
+switch (dns_lookup(dnsa, buffer, T_TLSA, &fullname))
+ {
+ case DNS_AGAIN:
+ return DEFER; /* just defer this TLS'd conn */
+
+ default:
+ case DNS_FAIL:
+ if (dane_required)
+ {
+ log_write(0, LOG_MAIN, "DANE error: TLSA lookup failed");
+ return FAIL;
+ }
+ break;
+
+ case DNS_SUCCEED:
+ if (!dns_is_secure(dnsa))
+ {
+ log_write(0, LOG_MAIN, "DANE error: TLSA lookup not DNSSEC");
+ return DEFER;
+ }
+ *dane = TRUE;
+ break;
+ }
+return OK;
+}
+
+
+static int
+dane_tlsa_load(SSL * ssl, host_item * host, dns_answer * dnsa)
+{
+dns_record * rr;
+dns_scan dnss;
+const char * hostnames[2] = { CS host->name, NULL };
+int found = 0;
+
+if (DANESSL_init(ssl, NULL, hostnames) != 1)
+ return tls_error(US"hostnames load", host, NULL);
+
+for (rr = dns_next_rr(dnsa, &dnss, RESET_ANSWERS);
+ rr;
+ rr = dns_next_rr(dnsa, &dnss, RESET_NEXT)
+ ) if (rr->type == T_TLSA)
+ {
+ uschar * p = rr->data;
+ uint8_t usage, selector, mtype;
+ const char * mdname;
+
+ found++;
+ usage = *p++;
+ selector = *p++;
+ mtype = *p++;
+
+ switch (mtype)
+ {
+ default:
+ log_write(0, LOG_MAIN,
+ "DANE error: TLSA record w/bad mtype 0x%x", mtype);
+ return FAIL;
+ case 0: mdname = NULL; break;
+ case 1: mdname = "sha256"; break;
+ case 2: mdname = "sha512"; break;
+ }
+
+ switch (DANESSL_add_tlsa(ssl, usage, selector, mdname, p, rr->size - 3))
+ {
+ default:
+ case 0: /* action not taken */
+ return tls_error(US"tlsa load", host, NULL);
+ case 1: break;
+ }
+
+ tls_out.tlsa_usage |= 1<<usage;
+ }
+
+if (found)
+ return OK;
+
+log_write(0, LOG_MAIN, "DANE error: No TLSA records");
+return FAIL;
+}
+#endif /*EXPERIMENTAL_DANE*/
+
+
/*************************************************
* Start a TLS session in a client *
smtp_transport_options_block * ob =
(smtp_transport_options_block *)tb->options_block;
static uschar txt[256];
-uschar *expciphers;
-X509* server_cert;
+uschar * expciphers;
+X509 * server_cert;
int rc;
static uschar cipherbuf[256];
+
#ifndef DISABLE_OCSP
-BOOL require_ocsp = verify_check_this_host(&ob->hosts_require_ocsp,
- NULL, host->name, host->address, NULL) == OK;
-BOOL request_ocsp = require_ocsp ? TRUE
- : verify_check_this_host(&ob->hosts_request_ocsp,
- NULL, host->name, host->address, NULL) == OK;
+BOOL request_ocsp = FALSE;
+BOOL require_ocsp = FALSE;
+#endif
+#ifdef EXPERIMENTAL_DANE
+dns_answer tlsa_dnsa;
+BOOL dane = FALSE;
+BOOL dane_required;
+#endif
+
+#ifdef EXPERIMENTAL_DANE
+tls_out.dane_verified = FALSE;
+tls_out.tlsa_usage = 0;
+dane_required = verify_check_this_host(&ob->hosts_require_dane, NULL,
+ host->name, host->address, NULL) == OK;
+
+if (host->dnssec == DS_YES)
+ {
+ if( dane_required
+ || verify_check_this_host(&ob->hosts_try_dane, NULL,
+ host->name, host->address, NULL) == OK
+ )
+ if ((rc = tlsa_lookup(host, &tlsa_dnsa, dane_required, &dane)) != OK)
+ return rc;
+ }
+else if (dane_required)
+ {
+ /*XXX a shame we only find this after making tcp & smtp connection */
+ /* move the test earlier? */
+ log_write(0, LOG_MAIN, "DANE error: previous lookup not DNSSEC");
+ return FAIL;
+ }
+#endif
+
+#ifndef DISABLE_OCSP
+ {
+ if ((require_ocsp = verify_check_this_host(&ob->hosts_require_ocsp,
+ NULL, host->name, host->address, NULL) == OK))
+ request_ocsp = TRUE;
+ else
+ {
+# ifdef EXPERIMENTAL_DANE
+ if ( dane
+ && ob->hosts_request_ocsp[0] == '*'
+ && ob->hosts_request_ocsp[1] == '\0'
+ )
+ {
+ /* Unchanged from default. Use a safer one under DANE */
+ request_ocsp = TRUE;
+ ob->hosts_request_ocsp = US"${if or { {= {0}{$tls_out_tlsa_usage}} "
+ " {= {4}{$tls_out_tlsa_usage}} } "
+ " {*}{}}";
+ }
+ else
+# endif
+ request_ocsp = verify_check_this_host(&ob->hosts_request_ocsp,
+ NULL, host->name, host->address, NULL) == OK;
+ }
+ }
#endif
rc = tls_init(&client_ctx, host, NULL,
return tls_error(US"SSL_CTX_set_cipher_list", host, NULL);
}
-/* stick to the old behaviour for compatibility if tls_verify_certificates is
- set but both tls_verify_hosts and tls_try_verify_hosts is not set. Check only
- the specified host patterns if one of them is defined */
-
-if ((!ob->tls_verify_hosts && !ob->tls_try_verify_hosts) ||
- (verify_check_host(&ob->tls_verify_hosts) == OK))
+#ifdef EXPERIMENTAL_DANE
+if (dane)
{
- if ((rc = setup_certs(client_ctx, ob->tls_verify_certificates,
- ob->tls_crl, host, FALSE, verify_callback_client)) != OK)
- return rc;
- client_verify_optional = FALSE;
+ SSL_CTX_set_verify(client_ctx, SSL_VERIFY_PEER, verify_callback_client_dane);
+
+ if (!DANESSL_library_init())
+ return tls_error(US"library init", host, NULL);
+ if (DANESSL_CTX_init(client_ctx) <= 0)
+ return tls_error(US"context init", host, NULL);
+ }
+else
+
+#endif
+ if ((rc = tls_client_basic_ctx_init(client_ctx, host, ob
#ifdef EXPERIMENTAL_CERTNAMES
- if (ob->tls_verify_cert_hostnames)
- {
- if (!expand_check(ob->tls_verify_cert_hostnames,
- US"tls_verify_cert_hostnames",
- &client_static_cbinfo->verify_cert_hostnames))
- return FAIL;
- if (client_static_cbinfo->verify_cert_hostnames)
- DEBUG(D_tls) debug_printf("Cert hostname to check: \"%s\"\n",
- client_static_cbinfo->verify_cert_hostnames);
- }
+ , client_static_cbinfo
#endif
- }
-else if (verify_check_host(&ob->tls_try_verify_hosts) == OK)
- {
- if ((rc = setup_certs(client_ctx, ob->tls_verify_certificates,
- ob->tls_crl, host, TRUE, verify_callback_client)) != OK)
+ )) != OK)
return rc;
- client_verify_optional = TRUE;
- }
if ((client_ssl = SSL_new(client_ctx)) == NULL)
return tls_error(US"SSL_new", host, NULL);
}
}
+#ifdef EXPERIMENTAL_DANE
+if (dane)
+ if ((rc = dane_tlsa_load(client_ssl, host, &tlsa_dnsa)) != OK)
+ return rc;
+#endif
+
#ifndef DISABLE_OCSP
/* Request certificate status at connection-time. If the server
does OCSP stapling we will get the callback (set in tls_init()) */
+# ifdef EXPERIMENTAL_DANE
+if (request_ocsp)
+ {
+ const uschar * s;
+ if ( (s = ob->hosts_require_ocsp) && Ustrstr(s, US"tls_out_tlsa_usage")
+ || (s = ob->hosts_request_ocsp) && Ustrstr(s, US"tls_out_tlsa_usage")
+ )
+ { /* Re-eval now $tls_out_tlsa_usage is populated. If
+ this means we avoid the OCSP request, we wasted the setup
+ cost in tls_init(). */
+ require_ocsp = verify_check_this_host(&ob->hosts_require_ocsp,
+ NULL, host->name, host->address, NULL) == OK;
+ request_ocsp = require_ocsp ? TRUE
+ : verify_check_this_host(&ob->hosts_request_ocsp,
+ NULL, host->name, host->address, NULL) == OK;
+ }
+ }
+# endif
+
if (request_ocsp)
{
SSL_set_tlsext_status_type(client_ssl, TLSEXT_STATUSTYPE_ocsp);
client_static_cbinfo->event_action = tb->tpda_event_action;
#endif
+#ifdef EXPERIMENTAL_TPDA
+client_static_cbinfo->event_action = tb->tpda_event_action;
+#endif
+
/* There doesn't seem to be a built-in timeout on connection. */
DEBUG(D_tls) debug_printf("Calling SSL_connect\n");
rc = SSL_connect(client_ssl);
alarm(0);
+#ifdef EXPERIMENTAL_DANE
+if (dane)
+ DANESSL_cleanup(client_ssl);
+#endif
+
if (rc <= 0)
return tls_error(US"SSL_connect", host, sigalrm_seen ? US"timed out" : NULL);
{ "hosts_require_auth", opt_stringptr,
(void *)offsetof(smtp_transport_options_block, hosts_require_auth) },
#ifdef SUPPORT_TLS
+# ifdef EXPERIMENTAL_DANE
+ { "hosts_require_dane", opt_stringptr,
+ (void *)offsetof(smtp_transport_options_block, hosts_require_dane) },
+# endif
# ifndef DISABLE_OCSP
{ "hosts_require_ocsp", opt_stringptr,
(void *)offsetof(smtp_transport_options_block, hosts_require_ocsp) },
#endif
{ "hosts_try_auth", opt_stringptr,
(void *)offsetof(smtp_transport_options_block, hosts_try_auth) },
+#if defined(SUPPORT_TLS) && defined(EXPERIMENTAL_DANE)
+ { "hosts_try_dane", opt_stringptr,
+ (void *)offsetof(smtp_transport_options_block, hosts_try_dane) },
+#endif
#ifndef DISABLE_PRDR
{ "hosts_try_prdr", opt_stringptr,
(void *)offsetof(smtp_transport_options_block, hosts_try_prdr) },
NULL, /* serialize_hosts */
NULL, /* hosts_try_auth */
NULL, /* hosts_require_auth */
+#ifdef EXPERIMENTAL_DANE
+ NULL, /* hosts_try_dane */
+ NULL, /* hosts_require_dane */
+#endif
#ifndef DISABLE_PRDR
NULL, /* hosts_try_prdr */
#endif
#ifndef DISABLE_OCSP
- US"*", /* hosts_request_ocsp */
+ US"*", /* hosts_request_ocsp (except under DANE) */
NULL, /* hosts_require_ocsp */
#endif
NULL, /* hosts_require_tls */
/* If the host is required to use a secure channel, ensure that we
have one. */
-else if (verify_check_this_host(&(ob->hosts_require_tls), NULL, host->name,
- host->address, NULL) == OK)
+else if ( verify_check_this_host(&(ob->hosts_require_tls), NULL, host->name,
+ host->address, NULL) == OK
+#ifdef EXPERIMENTAL_DANE
+ || verify_check_this_host(&(ob->hosts_require_dane), NULL, host->name,
+ host->address, NULL) == OK
+#endif
+ )
{
save_errno = ERRNO_TLSREQUIRED;
message = string_sprintf("a TLS session is required for %s [%s], but %s",
happens inside smtp_deliver().] */
#ifdef SUPPORT_TLS
- if (rc == DEFER && first_addr->basic_errno == ERRNO_TLSFAILURE &&
- ob->tls_tempfail_tryclear &&
- verify_check_this_host(&(ob->hosts_require_tls), NULL, host->name,
- host->address, NULL) != OK)
+ if ( rc == DEFER
+ && first_addr->basic_errno == ERRNO_TLSFAILURE
+ && ob->tls_tempfail_tryclear
+ && verify_check_this_host(&(ob->hosts_require_tls), NULL, host->name,
+ host->address, NULL) != OK
+# ifdef EXPERIMENTAL_DANE
+ && verify_check_this_host(&(ob->hosts_require_dane), NULL, host->name,
+ host->address, NULL) != OK
+# endif
+ )
{
log_write(0, LOG_MAIN, "TLS session failure: delivering unencrypted "
"to %s [%s] (not in hosts_require_tls)", host->name, host->address);
tpda_deferred(first_addr, host);
# endif
}
-#endif
+#endif /*SUPPORT_TLS*/
}
/* Delivery attempt finished */
uschar *serialize_hosts;
uschar *hosts_try_auth;
uschar *hosts_require_auth;
+#ifdef EXPERIMENTAL_DANE
+ uschar *hosts_try_dane;
+ uschar *hosts_require_dane;
+#endif
#ifndef DISABLE_PRDR
uschar *hosts_try_prdr;
#endif
if the options permit it for this host. */
if (rc != OK)
{
- if (rc == DEFER && ob->tls_tempfail_tryclear && !smtps &&
- verify_check_this_host(&(ob->hosts_require_tls), NULL, host->name,
- host->address, NULL) != OK)
+ if ( rc == DEFER
+ && ob->tls_tempfail_tryclear
+ && !smtps
+ && verify_check_this_host(&(ob->hosts_require_tls), NULL,
+ host->name, host->address, NULL) != OK
+#ifdef EXPERIMENTAL_DANE
+ && verify_check_this_host(&(ob->hosts_require_dane), NULL,
+ host->name, host->address, NULL) != OK
+#endif
+ )
{
(void)close(inblock.sock);
#ifdef EXPERIMENTAL_TPDA
/* If the host is required to use a secure channel, ensure that we have one. */
if (tls_out.active < 0)
- if (verify_check_this_host(&(ob->hosts_require_tls), NULL, host->name,
- host->address, NULL) == OK)
+ if ( verify_check_this_host(&(ob->hosts_require_tls), NULL, host->name,
+ host->address, NULL) == OK
+#ifdef EXPERIMENTAL_DANE
+ || verify_check_this_host(&(ob->hosts_require_dane), NULL, host->name,
+ host->address, NULL) == OK
+#endif
+ )
{
/*save_errno = ERRNO_TLSREQUIRED;*/
log_write(0, LOG_MAIN, "a TLS session is required for %s [%s], but %s",
--- /dev/null
+Bag Attributes
+ friendlyName: server1.example.com
+ localKeyID: 39 11 FB 30 22 36 42 DA FC D7 A2 8A 0C 60 83 2F 66 A7 B8 4E
+subject=/CN=server1.example.com
+issuer=/O=example.com/CN=clica Signing Cert
+-----BEGIN CERTIFICATE-----
+MIIC0DCCAjmgAwIBAgIBZTANBgkqhkiG9w0BAQUFADAzMRQwEgYDVQQKEwtleGFt
+cGxlLmNvbTEbMBkGA1UEAxMSY2xpY2EgU2lnbmluZyBDZXJ0MB4XDTEyMTEwMTEy
+MzQwNVoXDTM4MDEwMTEyMzQwNVowHjEcMBoGA1UEAxMTc2VydmVyMS5leGFtcGxl
+LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAyAGT263/ZlxGjPEi2BQj
+DMa/86TF+zVzMfozEZNOLiX6Sov54fW5I0nXCm0CjACOelLa2Eos/vqffxu0w5hM
+A8slRHrt0Gak7dJjwgKK/5NAQDrA+WnyJx/62u25299oCKk+egulCC0D3XczA89N
+cLuz8iKvYnWT+rdnbFdAPdcCAwEAAaOCAQcwggEDMA4GA1UdDwEB/wQEAwIE8DAg
+BgNVHSUBAf8EFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwMgYDVR0fBCswKTAnoCWg
+I4YhaHR0cDovL2NybC5leGFtcGxlLmNvbS9sYXRlc3QuY3JsMDQGCCsGAQUFBwEB
+BCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29zY3AvZXhhbXBsZS5jb20vMGUGA1Ud
+EQReMFyCIWFsdGVybmF0ZW5hbWUuc2VydmVyMS5leGFtcGxlLmNvbYIiYWx0ZXJu
+YXRlbmFtZTIuc2VydmVyMS5leGFtcGxlLmNvbYITc2VydmVyMS5leGFtcGxlLmNv
+bTANBgkqhkiG9w0BAQUFAAOBgQBWOqQ8y+u4J8KQCHQTiNxIxrUs5Sa+W5HUZ+c8
+SRLXRzDfmNtY7RiofUvbl0j1XH9wuTdjM/EkYnKSYPVu2ra8c8jC3NaVmr0WFqLv
+CvHXQWj2rZha0P/ZG1GfWc4vPYTQ7ugr65syGg4CPswwiUQJKnWBRqe27X1B61pj
++pxY7w==
+-----END CERTIFICATE-----
+Bag Attributes
+ friendlyName: Signing Cert
+subject=/O=example.com/CN=clica Signing Cert
+issuer=/O=example.com/CN=clica CA
+-----BEGIN CERTIFICATE-----
+MIICLDCCAZWgAwIBAgIBAjANBgkqhkiG9w0BAQUFADApMRQwEgYDVQQKEwtleGFt
+cGxlLmNvbTERMA8GA1UEAxMIY2xpY2EgQ0EwHhcNMTIxMTAxMTIzNDA1WhcNMzgw
+MTAxMTIzNDA1WjAzMRQwEgYDVQQKEwtleGFtcGxlLmNvbTEbMBkGA1UEAxMSY2xp
+Y2EgU2lnbmluZyBDZXJ0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCzwXsp
+P4RsZUoDfQfm5O5bi5unhwl+BTrKIaOtl5TBxMau+qEdKa02DD7Bx6PCzLKhWiZ3
+/MrO7V/cXIBun97dF5Zr5kk+HJk+y3es+xoPd3doknvGQEC/0cSGLcEC7aQ/bEqi
+fw2CgEY5ffkEAnDrdvGGeqBfJJGft/tqmlZbeQIDAQABo1owWDAOBgNVHQ8BAf8E
+BAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzApMCegJaAjhiFodHRw
+Oi8vY3JsLmV4YW1wbGUuY29tL2xhdGVzdC5jcmwwDQYJKoZIhvcNAQEFBQADgYEA
+Lq4cCtWMjqLHqf6lJUOBMsm+tgFcYDdxwkTquSZyUrbP1jrODkg5lQWNCdvB76B2
+tZQfMJ3F/kct2EAfsKbHqN3f+DARqPAR2qtOqzl3Ou5+TJjExKgojjzIAPFQzswH
+7v4aglpReaPBaVSNOZ7bMn/E8yRy3o466bhzdEIDcII=
+-----END CERTIFICATE-----
+Bag Attributes
+ friendlyName: Certificate Authority
+subject=/O=example.com/CN=clica CA
+issuer=/O=example.com/CN=clica CA
+-----BEGIN CERTIFICATE-----
+MIIB7jCCAVegAwIBAgIBATANBgkqhkiG9w0BAQUFADApMRQwEgYDVQQKEwtleGFt
+cGxlLmNvbTERMA8GA1UEAxMIY2xpY2EgQ0EwHhcNMTIxMTAxMTIzNDA0WhcNMzgw
+MTAxMTIzNDA0WjApMRQwEgYDVQQKEwtleGFtcGxlLmNvbTERMA8GA1UEAxMIY2xp
+Y2EgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAL0wro64rve876glpdRh
+tD6qFY6iH2kCarFFq3WaKmfCvOjYmn4CJr7pL7J5DuvCFh7A0H8lD/on5NK3yqkX
+Yi6EUlaYWxeRo2/PuZYUGbCpejST41sibw9V2dT4MHLidjDShE0W9SfgiMmxfF02
+H5hLYswAGCL1kezsVeEJeH31AgMBAAGjJjAkMBIGA1UdEwEB/wQIMAYBAf8CAQEw
+DgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4GBAIn9+8uyQtaq8sBEohTl
+qyJQQeZk5xxaILYP/rCIxc+z5fgOh+usB9adaiD23RPuuD/P2c3UqHJQWqIUTu46
+eOKn9K7X7ndIH3WnaC/u4nysL+SIAug72/k1BAVGNQvyNQMhth6CfZTgY0tgcS0Z
+RSHyhbTD0HeiJDI281BoOJjm
+-----END CERTIFICATE-----
clica -D example.$tld -p password -s 201 -S server2.example.$tld
clica -D example.$tld -p password -s 202 -S revoked2.example.$tld
clica -D example.$tld -p password -s 203 -S expired2.example.$tld -m 1
+
+
+ # openssl seems to generate a file (ca_chain.pam) in an order it
+ # cannot then use (the key applies to the first cert in the file?).
+ # Generate a shuffled one.
+ cd example.$tld/server1.example.$tld
+ openssl pkcs12 -in server1.example.com.p12 -passin file:pwdfile -cacerts -out cacerts.pem -nokeys
+ cat server1.example.com.pem cacerts.pem > fullchain.pem
+ rm cacerts.pem
+ cd ../..
done
# and loop again
--- /dev/null
+# Exim test configuration 5890
+# DANE common
+
+exim_path = EXIM_PATH
+host_lookup_order = bydns
+primary_hostname = myhost.test.ex
+spool_directory = DIR/spool
+
+# ----- Main settings -----
+
--- /dev/null
+# Exim test configuration 5800
+# DANE
+
+SERVER=
+
+exim_path = EXIM_PATH
+host_lookup_order = bydns
+primary_hostname = myhost.test.ex
+rfc1413_query_timeout = 0s
+spool_directory = DIR/spool
+log_file_path = DIR/spool/log/SERVER%slog
+gecos_pattern = ""
+gecos_name = CALLER_NAME
+
+# ----- Main settings -----
+
+acl_smtp_rcpt = accept
+
+log_selector = +tls_peerdn
+
+queue_only
+queue_run_in_order
+
+tls_advertise_hosts = *
+# needed to force generation
+tls_dhparam = historic
+
+# Set certificate only if server
+
+tls_certificate = ${if eq {SERVER}{server}{DIR/aux-fixed/cert1}fail}
+tls_privatekey = ${if eq {SERVER}{server}{DIR/aux-fixed/cert1}fail}
+
+#tls_verify_hosts = *
+#tls_verify_certificates = ${if eq {SERVER}{server}{DIR/aux-fixed/cert2}fail}
+
+
+# ----- Routers -----
+
+begin routers
+
+client:
+ driver = accept
+ condition = ${if eq {SERVER}{server}{no}{yes}}
+ retry_use_local_part
+ transport = send_to_server
+
+server:
+ driver = redirect
+ data = :blackhole:
+
+
+# ----- Transports -----
+
+begin transports
+
+send_to_server:
+ driver = smtp
+ allow_localhost
+ hosts = 127.0.0.1
+ port = PORT_D
+# tls_certificate = DIR/aux-fixed/cert2
+# tls_privatekey = DIR/aux-fixed/cert2
+# tls_verify_certificates = DIR/aux-fixed/cert2
+
+
+# ----- Retry -----
+
+
+begin retry
+
+* * F,5d,10s
+
+
+# End
--- /dev/null
+# Exim test configuration 5850
+# DANE
+
+SERVER=
+
+exim_path = EXIM_PATH
+host_lookup_order = bydns
+primary_hostname = myhost.test.ex
+rfc1413_query_timeout = 0s
+spool_directory = DIR/spool
+log_file_path = DIR/spool/log/SERVER%slog
+gecos_pattern = ""
+gecos_name = CALLER_NAME
+
+# ----- Main settings -----
+
+acl_smtp_rcpt = accept
+
+log_selector = +received_recipients +tls_peerdn +tls_certificate_verified
+
+queue_only
+queue_run_in_order
+
+tls_advertise_hosts = *
+
+# Set certificate only if server
+CDIR1 = DIR/aux-fixed
+CDIR2 = DIR/aux-fixed/exim-ca/example.com/server1.example.com
+
+tls_certificate = ${if eq {SERVER}{server} \
+ {${if eq {DETAILS}{ta} \
+ {CDIR2/fullchain.pem}\
+ {CDIR1/cert1}}}\
+ fail}
+
+tls_privatekey = ${if eq {SERVER}{server} \
+ {${if eq {DETAILS}{ta} \
+ {CDIR2/server1.example.com.unlocked.key}\
+ {CDIR1/cert1}}}\
+ fail}
+
+
+# ----- Routers -----
+
+begin routers
+
+client:
+ driver = dnslookup
+ condition = ${if eq {SERVER}{}}
+ dnssec_request_domains = *
+ self = send
+ transport = send_to_server
+
+server:
+ driver = redirect
+ data = :blackhole:
+
+
+# ----- Transports -----
+
+begin transports
+
+send_to_server:
+ driver = smtp
+ allow_localhost
+ port = PORT_D
+
+# hosts_try_dane = *
+ hosts_require_dane = *
+ hosts_request_ocsp = ${if or { {= {4}{$tls_out_tlsa_usage}} \
+ {= {0}{$tls_out_tlsa_usage}} } \
+ {*}{}}
+
+
+# ----- Retry -----
+
+
+begin retry
+
+* * F,5d,10s
+
+
+# End
--- /dev/null
+# Exim test configuration 5850
+# DANE
+
+SERVER=
+
+exim_path = EXIM_PATH
+host_lookup_order = bydns
+primary_hostname = myhost.test.ex
+rfc1413_query_timeout = 0s
+spool_directory = DIR/spool
+log_file_path = DIR/spool/log/SERVER%slog
+gecos_pattern = ""
+gecos_name = CALLER_NAME
+
+# ----- Main settings -----
+
+acl_smtp_rcpt = accept
+
+log_selector = +received_recipients +tls_peerdn +tls_certificate_verified
+
+queue_only
+queue_run_in_order
+
+tls_advertise_hosts = *
+
+# Set certificate only if server
+CDIR1 = DIR/aux-fixed
+CDIR2 = DIR/aux-fixed/exim-ca/example.com/server1.example.com
+
+tls_certificate = ${if eq {SERVER}{server} \
+ {${if eq {DETAILS}{ta} \
+ {CDIR2/fullchain.pem}\
+ {CDIR1/cert1}}}\
+ fail}
+
+tls_privatekey = ${if eq {SERVER}{server} \
+ {${if eq {DETAILS}{ta} \
+ {CDIR2/server1.example.com.unlocked.key}\
+ {CDIR1/cert1}}}\
+ fail}
+
+
+begin acl
+
+logger:
+ accept condition = ${if eq {tls} {${listextract{1}{$tpda_event}}}}
+ logwrite = $tpda_event depth = $tpda_data \
+ <${certextract {subject} {$tls_out_peercert}}>
+# message = noooo
+
+ accept condition = ${if eq {msg} {${listextract{1}{$tpda_event}}}}
+ logwrite = $tpda_event dane=$tls_out_dane
+ accept
+
+# ----- Routers -----
+
+begin routers
+
+client:
+ driver = dnslookup
+ condition = ${if eq {SERVER}{}}
+ dnssec_request_domains = *
+ self = send
+ transport = send_to_server
+
+server:
+ driver = redirect
+ data = :blackhole:
+
+
+# ----- Transports -----
+
+begin transports
+
+send_to_server:
+ driver = smtp
+ allow_localhost
+ port = PORT_D
+
+# hosts_try_dane = *
+ hosts_require_dane = *
+ hosts_request_ocsp = ${if or { {= {4}{$tls_out_tlsa_usage}} \
+ {= {0}{$tls_out_tlsa_usage}} } \
+ {*}{}}
+
+ tpda_event_action = ${acl {logger}}
+
+# End
v6 AAAA V6NET:ffff:836f:0a00:000a:0800:200a:c032
; Alias A and CNAME records for the local host, under the name "eximtesthost"
+; Make the A covered by DNSSEC and add a TLSA for it.
eximtesthost A HOSTIPV4
alias-eximtesthost CNAME eximtesthost.test.ex.
csa1 A V4NET.9.8.7
csa2 A V4NET.9.8.8
+; ------- Testing DANE ------------
+
+; full suite dns chain, sha512
+DNSSEC mxdane512ee MX 1 dane512ee.
+DNSSEC dane512ee A HOSTIPV4
+DNSSEC _1225._tcp.dane512ee TLSA 3 1 2 3d5eb81b1dfc3f93c1fa8819e3fb3fdb41bb590441d5f3811db17772f4bc6de29bdd7c4f4b723750dda871b99379192b3f979f03db1252c4f08b03ef7176528d
+
+; A-only, sha256
+DNSSEC dane256ee A HOSTIPV4
+DNSSEC _1225._tcp.dane256ee TLSA 3 1 1 2bb55f418bb03411a5007cecbfcd3ec1c94404312c0d53a44bb2166b32654db3
+
+; full MX, sha256, TA-mode
+DNSSEC mxdane256ta MX 1 dane256ta.
+DNSSEC dane256ta A HOSTIPV4
+DNSSEC _1225._tcp.dane256ta TLSA 2 0 1 b2c6f27f2d16390b4f71cacc69742bf610d750534fab240516c0f2deb4042ad4
+
; End
--- /dev/null
+1999-03-02 09:44:33 10HmaX-0005vi-00 <= CALLER@myhost.test.ex U=CALLER P=local S=sss for CALLER@dane256ee.test.ex
+1999-03-02 09:44:33 10HmaY-0005vi-00 <= CALLER@myhost.test.ex U=CALLER P=local S=sss for CALLER@mxdane512ee.test.ex
+1999-03-02 09:44:33 Start queue run: pid=pppp -qf
+1999-03-02 09:44:33 10HmaX-0005vi-00 => CALLER@dane256ee.test.ex R=client T=send_to_server H=dane256ee.test.ex [ip4.ip4.ip4.ip4] X=TLSv1:AES256-SHA:256 CV=dane DN="/C=UK/O=The Exim Maintainers/OU=Test Suite/CN=Phil Pennock" C="250 OK id=10HmaZ-0005vi-00"
+1999-03-02 09:44:33 10HmaX-0005vi-00 Completed
+1999-03-02 09:44:33 10HmaY-0005vi-00 => CALLER@mxdane512ee.test.ex R=client T=send_to_server H=dane512ee.test.ex [ip4.ip4.ip4.ip4] X=TLSv1:AES256-SHA:256 CV=dane DN="/C=UK/O=The Exim Maintainers/OU=Test Suite/CN=Phil Pennock" C="250 OK id=10HmbA-0005vi-00"
+1999-03-02 09:44:33 10HmaY-0005vi-00 Completed
+1999-03-02 09:44:33 End queue run: pid=pppp -qf
+1999-03-02 09:44:33 10HmbB-0005vi-00 <= CALLER@myhost.test.ex U=CALLER P=local S=sss for CALLER@mxdane256ta.test.ex
+1999-03-02 09:44:33 Start queue run: pid=pppp -qf
+1999-03-02 09:44:33 10HmbB-0005vi-00 => CALLER@mxdane256ta.test.ex R=client T=send_to_server H=dane256ta.test.ex [ip4.ip4.ip4.ip4] X=TLSv1:AES256-SHA:256 CV=dane DN="/CN=server1.example.com" C="250 OK id=10HmbC-0005vi-00"
+1999-03-02 09:44:33 10HmbB-0005vi-00 Completed
+1999-03-02 09:44:33 End queue run: pid=pppp -qf
+
+******** SERVER ********
+1999-03-02 09:44:33 exim x.yz daemon started: pid=pppp, no queue runs, listening for SMTP on port 1225
+1999-03-02 09:44:33 10HmaZ-0005vi-00 <= CALLER@myhost.test.ex H=the.local.host.name (myhost.test.ex) [ip4.ip4.ip4.ip4] P=esmtps X=TLSv1:AES256-SHA:256 CV=no S=sss id=E10HmaX-0005vi-00@myhost.test.ex for CALLER@dane256ee.test.ex
+1999-03-02 09:44:33 10HmbA-0005vi-00 <= CALLER@myhost.test.ex H=the.local.host.name (myhost.test.ex) [ip4.ip4.ip4.ip4] P=esmtps X=TLSv1:AES256-SHA:256 CV=no S=sss id=E10HmaY-0005vi-00@myhost.test.ex for CALLER@mxdane512ee.test.ex
+1999-03-02 09:44:33 Start queue run: pid=pppp -qf
+1999-03-02 09:44:33 10HmaZ-0005vi-00 => :blackhole: <CALLER@dane256ee.test.ex> R=server
+1999-03-02 09:44:33 10HmaZ-0005vi-00 Completed
+1999-03-02 09:44:33 10HmbA-0005vi-00 => :blackhole: <CALLER@mxdane512ee.test.ex> R=server
+1999-03-02 09:44:33 10HmbA-0005vi-00 Completed
+1999-03-02 09:44:33 End queue run: pid=pppp -qf
+1999-03-02 09:44:33 exim x.yz daemon started: pid=pppp, no queue runs, listening for SMTP on port 1225
+1999-03-02 09:44:33 10HmbC-0005vi-00 <= CALLER@myhost.test.ex H=the.local.host.name (myhost.test.ex) [ip4.ip4.ip4.ip4] P=esmtps X=TLSv1:AES256-SHA:256 CV=no S=sss id=E10HmbB-0005vi-00@myhost.test.ex for CALLER@mxdane256ta.test.ex
+1999-03-02 09:44:33 Start queue run: pid=pppp -qf
+1999-03-02 09:44:33 10HmbC-0005vi-00 => :blackhole: <CALLER@mxdane256ta.test.ex> R=server
+1999-03-02 09:44:33 10HmbC-0005vi-00 Completed
+1999-03-02 09:44:33 End queue run: pid=pppp -qf
--- /dev/null
+1999-03-02 09:44:33 10HmaX-0005vi-00 <= CALLER@myhost.test.ex U=CALLER P=local S=sss for CALLER@dane256ee.test.ex
+1999-03-02 09:44:33 10HmaY-0005vi-00 <= CALLER@myhost.test.ex U=CALLER P=local S=sss for CALLER@mxdane512ee.test.ex
+1999-03-02 09:44:33 Start queue run: pid=pppp -qf
+1999-03-02 09:44:33 10HmaX-0005vi-00 tls:cert depth = 0 <CN=Phil Pennock,OU=Test Suite,O=The Exim Maintainers,C=UK>
+1999-03-02 09:44:33 10HmaX-0005vi-00 => CALLER@dane256ee.test.ex R=client T=send_to_server H=dane256ee.test.ex [ip4.ip4.ip4.ip4] X=TLSv1:AES256-SHA:256 CV=dane DN="/C=UK/O=The Exim Maintainers/OU=Test Suite/CN=Phil Pennock" C="250 OK id=10HmaZ-0005vi-00"
+1999-03-02 09:44:33 10HmaX-0005vi-00 msg:delivery dane=yes
+1999-03-02 09:44:33 10HmaX-0005vi-00 Completed
+1999-03-02 09:44:33 10HmaY-0005vi-00 tls:cert depth = 0 <CN=Phil Pennock,OU=Test Suite,O=The Exim Maintainers,C=UK>
+1999-03-02 09:44:33 10HmaY-0005vi-00 => CALLER@mxdane512ee.test.ex R=client T=send_to_server H=dane512ee.test.ex [ip4.ip4.ip4.ip4] X=TLSv1:AES256-SHA:256 CV=dane DN="/C=UK/O=The Exim Maintainers/OU=Test Suite/CN=Phil Pennock" C="250 OK id=10HmbA-0005vi-00"
+1999-03-02 09:44:33 10HmaY-0005vi-00 msg:delivery dane=yes
+1999-03-02 09:44:33 10HmaY-0005vi-00 Completed
+1999-03-02 09:44:33 End queue run: pid=pppp -qf
+1999-03-02 09:44:33 10HmbB-0005vi-00 <= CALLER@myhost.test.ex U=CALLER P=local S=sss for CALLER@mxdane256ta.test.ex
+1999-03-02 09:44:33 Start queue run: pid=pppp -qf
+1999-03-02 09:44:33 10HmbB-0005vi-00 tls:cert depth = 2 <CN=clica CA,O=example.com>
+1999-03-02 09:44:33 10HmbB-0005vi-00 tls:cert depth = 0 <CN=server1.example.com>
+1999-03-02 09:44:33 10HmbB-0005vi-00 tls:cert depth = 2 <CN=clica CA,O=example.com>
+1999-03-02 09:44:33 10HmbB-0005vi-00 tls:cert depth = 1 <CN=clica Signing Cert,O=example.com>
+1999-03-02 09:44:33 10HmbB-0005vi-00 tls:cert depth = 0 <CN=server1.example.com>
+1999-03-02 09:44:33 10HmbB-0005vi-00 => CALLER@mxdane256ta.test.ex R=client T=send_to_server H=dane256ta.test.ex [ip4.ip4.ip4.ip4] X=TLSv1:AES256-SHA:256 CV=dane DN="/CN=server1.example.com" C="250 OK id=10HmbC-0005vi-00"
+1999-03-02 09:44:33 10HmbB-0005vi-00 msg:delivery dane=yes
+1999-03-02 09:44:33 10HmbB-0005vi-00 Completed
+1999-03-02 09:44:33 End queue run: pid=pppp -qf
+
+******** SERVER ********
+1999-03-02 09:44:33 exim x.yz daemon started: pid=pppp, no queue runs, listening for SMTP on port 1225
+1999-03-02 09:44:33 10HmaZ-0005vi-00 <= CALLER@myhost.test.ex H=the.local.host.name (myhost.test.ex) [ip4.ip4.ip4.ip4] P=esmtps X=TLSv1:AES256-SHA:256 CV=no S=sss id=E10HmaX-0005vi-00@myhost.test.ex for CALLER@dane256ee.test.ex
+1999-03-02 09:44:33 10HmbA-0005vi-00 <= CALLER@myhost.test.ex H=the.local.host.name (myhost.test.ex) [ip4.ip4.ip4.ip4] P=esmtps X=TLSv1:AES256-SHA:256 CV=no S=sss id=E10HmaY-0005vi-00@myhost.test.ex for CALLER@mxdane512ee.test.ex
+1999-03-02 09:44:33 Start queue run: pid=pppp -qf
+1999-03-02 09:44:33 10HmaZ-0005vi-00 => :blackhole: <CALLER@dane256ee.test.ex> R=server
+1999-03-02 09:44:33 10HmaZ-0005vi-00 Completed
+1999-03-02 09:44:33 10HmbA-0005vi-00 => :blackhole: <CALLER@mxdane512ee.test.ex> R=server
+1999-03-02 09:44:33 10HmbA-0005vi-00 Completed
+1999-03-02 09:44:33 End queue run: pid=pppp -qf
+1999-03-02 09:44:33 exim x.yz daemon started: pid=pppp, no queue runs, listening for SMTP on port 1225
+1999-03-02 09:44:33 10HmbC-0005vi-00 <= CALLER@myhost.test.ex H=the.local.host.name (myhost.test.ex) [ip4.ip4.ip4.ip4] P=esmtps X=TLSv1:AES256-SHA:256 CV=no S=sss id=E10HmbB-0005vi-00@myhost.test.ex for CALLER@mxdane256ta.test.ex
+1999-03-02 09:44:33 Start queue run: pid=pppp -qf
+1999-03-02 09:44:33 10HmbC-0005vi-00 => :blackhole: <CALLER@mxdane256ta.test.ex> R=server
+1999-03-02 09:44:33 10HmbC-0005vi-00 Completed
+1999-03-02 09:44:33 End queue run: pid=pppp -qf
@saved = ();
}
+ # Skip hosts_require_dane checks when the options
+ # are unset, because dane ain't always there.
+
+ next if /in\shosts_require_dane\?\sno\s\(option\sunset\)/x;
+
# Skip some lines that Exim puts out at the start of debugging output
# because they will be different in different binaries.
--- /dev/null
+# Expansion test for DANE.
+#
+# Some systems seem to use 1-byte fields for the leading
+# 3 fields in a TLSA record, others 2-bytes.
+# We need the result to match the string in dnszones-src/db.test.ex
+
+exim -be
+
+dnslookup tlsa: ${lookup dnsdb {tlsa=_1225._tcp.dane512ee.test.ex} \
+ {$value}{none}}
+
+****
--- /dev/null
+support Experimental_DANE
+running IPv4
--- /dev/null
+# DANE client: general
+#
+gnutls
+#
+exim -DSERVER=server -bd -oX PORT_D
+****
+exim CALLER@test.ex
+Testing
+****
+exim -qf
+****
+killdaemon
+exim -DSERVER=server -DNOTDAEMON -qf
+****
--- /dev/null
+support Experimental_DANE
+support GnuTLS
+running IPv4
--- /dev/null
+# DANE client: general
+#
+exim -DSERVER=server -DDETAILS=ee -bd -oX PORT_D
+****
+# TLSA (3 1 1)
+exim CALLER@dane256ee.test.ex
+Testing
+****
+# TLSA (3 1 2)
+exim CALLER@mxdane512ee.test.ex
+Testing
+****
+exim -qf
+****
+killdaemon
+exim -DSERVER=server -DDETAILS=ee -DNOTDAEMON -qf
+****
+#
+#
+exim -DSERVER=server -DDETAILS=ta -bd -oX PORT_D
+****
+# TLSA (2 0 1)
+exim CALLER@mxdane256ta.test.ex
+Testing
+****
+exim -qf
+****
+killdaemon
+exim -DSERVER=server -DDETAILS=ta -DNOTDAEMON -qf
+****
--- /dev/null
+support Experimental_DANE
+support OpenSSL
+running IPv4
--- /dev/null
+# DANE client: TPDA
+#
+exim -DSERVER=server -DDETAILS=ee -bd -oX PORT_D
+****
+# TLSA (3 1 1)
+exim CALLER@dane256ee.test.ex
+Testing
+****
+# TLSA (3 1 2)
+exim CALLER@mxdane512ee.test.ex
+Testing
+****
+exim -qf
+****
+killdaemon
+exim -DSERVER=server -DDETAILS=ee -DNOTDAEMON -qf
+****
+#
+#
+exim -DSERVER=server -DDETAILS=ta -bd -oX PORT_D
+****
+# TLSA (2 0 1)
+exim CALLER@mxdane256ta.test.ex
+Testing
+****
+exim -qf
+****
+killdaemon
+exim -DSERVER=server -DDETAILS=ta -DNOTDAEMON -qf
+****
--- /dev/null
+support Experimental_DANE
+support Experimental_TPDA
+support OpenSSL
+running IPv4
PASS ON NOT FOUND
and the domain is not found. It converts the the result to PASS_ON instead of
-HOST_NOT_FOUND. */
+HOST_NOT_FOUND.
+
+Any DNS record line in a zone file can be prefixed with "DNSSEC" and
+at least one space; if all the records found by a lookup are marked
+as such then the response will have the "AD" bit set. */
#include <ctype.h>
#include <stdarg.h>
know about AAAA and SRV at all. */
#ifndef ns_t_a
-#define ns_t_a T_A
-#define ns_t_ns T_NS
-#define ns_t_cname T_CNAME
-#define ns_t_soa T_SOA
-#define ns_t_ptr T_PTR
-#define ns_t_mx T_MX
-#define ns_t_txt T_TXT
-#define ns_t_aaaa T_AAAA
-#define ns_t_srv T_SRV
-#ifndef T_AAAA
-#define T_AAAA 28
-#endif
-#ifndef T_SRV
-#define T_SRV 33
-#endif
+# define ns_t_a T_A
+# define ns_t_ns T_NS
+# define ns_t_cname T_CNAME
+# define ns_t_soa T_SOA
+# define ns_t_ptr T_PTR
+# define ns_t_mx T_MX
+# define ns_t_txt T_TXT
+# define ns_t_aaaa T_AAAA
+# define ns_t_srv T_SRV
+# define ns_t_tlsa T_TLSA
+# ifndef T_AAAA
+# define T_AAAA 28
+# endif
+# ifndef T_SRV
+# define T_SRV 33
+# endif
+# ifndef T_TLSA
+# define T_TLSA 52
+# endif
#endif
static tlist type_list[] = {
{ US"TXT", ns_t_txt },
{ US"AAAA", ns_t_aaaa },
{ US"SRV", ns_t_srv },
+ { US"TLSA", ns_t_tlsa },
{ NULL, 0 }
};
return pk;
}
+uschar *
+bytefield(uschar ** pp, uschar * pk)
+{
+unsigned value = 0;
+uschar * p = *pp;
+
+while (isdigit(*p)) value = value*10 + *p++ - '0';
+while (isspace(*p)) p++;
+*pp = p;
+*pk++ = value & 255;
+return pk;
+}
+
+uschar *
+shortfield(uschar ** pp, uschar * pk)
+{
+unsigned value = 0;
+uschar * p = *pp;
+
+while (isdigit(*p)) value = value*10 + *p++ - '0';
+while (isspace(*p)) p++;
+*pp = p;
+*pk++ = (value >> 8) & 255;
+*pk++ = value & 255;
+return pk;
+}
+
/*************************************************
static int
find_records(FILE *f, uschar *zone, uschar *domain, uschar *qtype,
- int qtypelen, uschar **pkptr, int *countptr)
+ int qtypelen, uschar **pkptr, int *countptr, BOOL * dnssec)
{
int yield = HOST_NOT_FOUND;
int domainlen = Ustrlen(domain);
rrdomain[0] = 0; /* No previous domain */
(void)fseek(f, 0, SEEK_SET); /* Start again at the beginning */
+*dnssec = TRUE; /* cancelled by first nonsecure rec found */
+
/* Scan for RRs */
while (fgets(CS buffer, sizeof(buffer), f) != NULL)
int i, plen, value;
int tvalue = typeptr->value;
int qtlen = qtypelen;
+ BOOL rr_sec = FALSE;
p = buffer;
while (isspace(*p)) p++;
if (*p == 0 || *p == ';') continue;
- if (Ustrncmp(p, "PASS ON NOT FOUND", 17) == 0)
+ if (Ustrncmp(p, US"PASS ON NOT FOUND", 17) == 0)
{
pass_on_not_found = TRUE;
continue;
*ep = 0;
p = buffer;
+ if (Ustrncmp(p, US"DNSSEC ", 7) == 0) /* tagged as secure */
+ {
+ rr_sec = TRUE;
+ p += 7;
+ }
+
if (!isspace(*p))
{
uschar *pp = rrdomain;
/* Found a relevant record */
+ if (!rr_sec)
+ *dnssec = FALSE; /* cancel AD return */
+
yield = 0;
*countptr = *countptr + 1;
break;
case ns_t_mx:
- value = 0;
- while (isdigit(*p)) value = value*10 + *p++ - '0';
- while (isspace(*p)) p++;
- *pk++ = (value >> 8) & 255;
- *pk++ = value & 255;
+ pk = shortfield(&p, pk);
if (ep[-1] != '.') sprintf(ep, "%s.", zone);
pk = packname(p, pk);
plen = Ustrlen(p);
*pp = pk - pp - 1;
break;
+ case ns_t_tlsa:
+ pk = bytefield(&p, pk); /* usage */
+ pk = bytefield(&p, pk); /* selector */
+ pk = bytefield(&p, pk); /* match type */
+ while (isxdigit(*p))
+ {
+ value = toupper(*p) - (isdigit(*p) ? '0' : '7') << 4;
+ if (isxdigit(*++p))
+ {
+ value |= toupper(*p) - (isdigit(*p) ? '0' : '7');
+ p++;
+ }
+ *pk++ = value & 255;
+ }
+
+ break;
+
case ns_t_srv:
for (i = 0; i < 3; i++)
{
uschar qtype[12];
uschar packet[512];
uschar *pk = packet;
+BOOL dnssec;
if (argc != 4)
{
/* Find the records we want, and add them to the result. */
count = 0;
-yield = find_records(f, zone, domain, qtype, qtypelen, &pk, &count);
+yield = find_records(f, zone, domain, qtype, qtypelen, &pk, &count, &dnssec);
if (yield == NO_RECOVERY) goto END_OFF;
packet[6] = (count >> 8) & 255;
packet[10] = 0;
packet[11] = 0;
+if (dnssec)
+ ((HEADER *)packet)->ad = 1;
+
/* Close the zone file, write the result, and return. */
END_OFF:
return yield;
}
+/* vi: aw ai sw=2
+*/
/* End of fakens.c */
--- /dev/null
+>
+> dnslookup tlsa: 3 1 2 3d5eb81b1dfc3f93c1fa8819e3fb3fdb41bb590441d5f3811db17772f4bc6de29bdd7c4f4b723750dda871b99379192b3f979f03db1252c4f08b03ef7176528d
+>
+>
git://git.exim.org / users / heiko / exim.git / commitdiff