diff options
| author | Jeremy Harris <jgh146exb@wizmail.org> | 2014-09-02 13:14:01 +0100 |
|---|---|---|
| committer | Jeremy Harris <jgh146exb@wizmail.org> | 2014-09-02 13:14:01 +0100 |
| commit | 0f06b4f296802e4e13188c740ea09419931a3020 (patch) | |
| tree | 958905a4af8487e55132b88e42ed237509c42f4e | |
| parent | 2ce45f59d7f070fa3d96f88523a6e19a0e68aae2 (diff) | |
| parent | d567a64d80184840c08ca4a016a979233f09ec23 (diff) | |
Introduce EXPERIMENTAL_DANE feature
51 files changed, 14040 insertions, 97 deletions
diff --git a/DANE-draft-notes b/DANE-draft-notes new file mode 100644 index 000000000..21b3992cc --- /dev/null +++ b/DANE-draft-notes @@ -0,0 +1,11 @@ + +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 diff --git a/doc/doc-txt/ChangeLog b/doc/doc-txt/ChangeLog index 2caf9ed52..f3f432459 100644 --- a/doc/doc-txt/ChangeLog +++ b/doc/doc-txt/ChangeLog @@ -25,6 +25,9 @@ TL/03 Bugzilla 1518: Clarify "condition" processing in routers; that 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 ----------------- diff --git a/doc/doc-txt/OptionLists.txt b/doc/doc-txt/OptionLists.txt index ef6195600..375850d6b 100644 --- a/doc/doc-txt/OptionLists.txt +++ b/doc/doc-txt/OptionLists.txt @@ -181,6 +181,7 @@ dns_check_names_pattern string + main 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 diff --git a/doc/doc-txt/draft-ietf-dane-ops-06 b/doc/doc-txt/draft-ietf-dane-ops-06 new file mode 100644 index 000000000..6fc89689b --- /dev/null +++ b/doc/doc-txt/draft-ietf-dane-ops-06 @@ -0,0 +1,1568 @@ + + + + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] diff --git a/doc/doc-txt/draft-ietf-dane-smtp-with-dane-10.txt b/doc/doc-txt/draft-ietf-dane-smtp-with-dane-10.txt new file mode 100644 index 000000000..99d17e88e --- /dev/null +++ b/doc/doc-txt/draft-ietf-dane-smtp-with-dane-10.txt @@ -0,0 +1,1904 @@ + + + + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] diff --git a/doc/doc-txt/draft-ietf-dane-smtp-with-dane-11.txt b/doc/doc-txt/draft-ietf-dane-smtp-with-dane-11.txt new file mode 100644 index 000000000..26bed33a5 --- /dev/null +++ b/doc/doc-txt/draft-ietf-dane-smtp-with-dane-11.txt @@ -0,0 +1,1960 @@ + + + + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] diff --git a/doc/doc-txt/draft-ietf-dane-smtp-with-dane-12.txt b/doc/doc-txt/draft-ietf-dane-smtp-with-dane-12.txt new file mode 100644 index 000000000..70ae5d66d --- /dev/null +++ b/doc/doc-txt/draft-ietf-dane-smtp-with-dane-12.txt @@ -0,0 +1,1848 @@ + + + + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] diff --git a/doc/doc-txt/draft-ietf-dane-smtp-with-dane.txt b/doc/doc-txt/draft-ietf-dane-smtp-with-dane.txt new file mode 100644 index 000000000..70ae5d66d --- /dev/null +++ b/doc/doc-txt/draft-ietf-dane-smtp-with-dane.txt @@ -0,0 +1,1848 @@ + + + + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] diff --git a/doc/doc-txt/experimental-spec.txt b/doc/doc-txt/experimental-spec.txt index d8bd0bf46..2f44fce26 100644 --- a/doc/doc-txt/experimental-spec.txt +++ b/doc/doc-txt/experimental-spec.txt @@ -1137,6 +1137,7 @@ in a router. Exim will then send the success DSN himself if requested as if 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 @@ -1155,6 +1156,141 @@ a single wildcard being the initial component of a 3-or-more 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 diff --git a/doc/doc-txt/rfc6698-dane.txt b/doc/doc-txt/rfc6698-dane.txt new file mode 100644 index 000000000..95e7cf4f5 --- /dev/null +++ b/doc/doc-txt/rfc6698-dane.txt @@ -0,0 +1,2075 @@ + + + + + + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + diff --git a/src/OS/Makefile-Base b/src/OS/Makefile-Base index 87a803704..f82549ded 100644 --- a/src/OS/Makefile-Base +++ b/src/OS/Makefile-Base @@ -298,7 +298,7 @@ convert4r4: Makefile ../src/convert4r4.src 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. @@ -602,10 +602,11 @@ demime.o: $(HDRS) demime.c # 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 diff --git a/src/scripts/MakeLinks b/src/scripts/MakeLinks index 01cd21f1c..a50f75b36 100755 --- a/src/scripts/MakeLinks +++ b/src/scripts/MakeLinks @@ -271,6 +271,10 @@ ln -s ../src/srs.c srs.c 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 diff --git a/src/src/EDITME b/src/src/EDITME index d576fd7a3..01c4ebc9d 100644 --- a/src/src/EDITME +++ b/src/src/EDITME @@ -494,6 +494,9 @@ EXIM_MONITOR=eximon.bin # 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 # ############################################################################### diff --git a/src/src/config.h.defaults b/src/src/config.h.defaults index ba4615c11..49ab276ff 100644 --- a/src/src/config.h.defaults +++ b/src/src/config.h.defaults @@ -168,6 +168,7 @@ it's a default value. */ /* EXPERIMENTAL features */ #define EXPERIMENTAL_BRIGHTMAIL #define EXPERIMENTAL_CERTNAMES +#define EXPERIMENTAL_DANE #define EXPERIMENTAL_DCC #define EXPERIMENTAL_DMARC #define EXPERIMENTAL_DSN diff --git a/src/src/dane-gnu.c b/src/src/dane-gnu.c new file mode 100644 index 000000000..b98bffad6 --- /dev/null +++ b/src/src/dane-gnu.c @@ -0,0 +1,21 @@ +/************************************************* +* 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 */ diff --git a/src/src/dane-openssl.c b/src/src/dane-openssl.c new file mode 100644 index 000000000..6345b39ca --- /dev/null +++ b/src/src/dane-openssl.c @@ -0,0 +1,1520 @@ +#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 +*/ diff --git a/src/src/dane.c b/src/src/dane.c new file mode 100644 index 000000000..20dfe5b18 --- /dev/null +++ b/src/src/dane.c @@ -0,0 +1,45 @@ +/************************************************* +* 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 */ diff --git a/src/src/danessl.h b/src/src/danessl.h new file mode 100644 index 000000000..5b1584da2 --- /dev/null +++ b/src/src/danessl.h @@ -0,0 +1,31 @@ +#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 diff --git a/src/src/deliver.c b/src/src/deliver.c index b3a5a49b2..78b669ad2 100644 --- a/src/src/deliver.c +++ b/src/src/deliver.c @@ -699,7 +699,15 @@ d_tlslog(uschar * s, int * sizep, int * ptrp, address_item * addr) 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"\""); @@ -1139,6 +1147,9 @@ if (result == OK) 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); @@ -1157,6 +1168,9 @@ if (result == OK) tls_out.cipher = NULL; tls_out.peerdn = NULL; tls_out.ocsp = OCSP_NOT_REQ; +# ifdef EXPERIMENTAL_DANE + tls_out.dane_verified = FALSE; +# endif #endif } @@ -4171,6 +4185,9 @@ for (delivery_count = 0; addr_remote != NULL; delivery_count++) /* 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 @@ -7056,12 +7073,14 @@ wording. */ { 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); diff --git a/src/src/dns.c b/src/src/dns.c index 6efb88d58..3d047abba 100644 --- a/src/src/dns.c +++ b/src/src/dns.c @@ -607,7 +607,7 @@ if (check_dns_names_pattern[0] != 0 && type != T_PTR && type != T_TXT) /* 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++ != '.'); diff --git a/src/src/exim.c b/src/src/exim.c index 51daa5576..85a7c812c 100644 --- a/src/src/exim.c +++ b/src/src/exim.c @@ -827,6 +827,9 @@ fprintf(f, "Support for:"); #ifdef EXPERIMENTAL_BRIGHTMAIL fprintf(f, " Experimental_Brightmail"); #endif +#ifdef EXPERIMENTAL_DANE + fprintf(f, " Experimental_DANE"); +#endif #ifdef EXPERIMENTAL_DCC fprintf(f, " Experimental_DCC"); #endif diff --git a/src/src/expand.c b/src/src/expand.c index f6b70cb47..8111c4212 100644 --- a/src/src/expand.c +++ b/src/src/expand.c @@ -685,6 +685,9 @@ static var_entry var_table[] = { { "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 }, @@ -692,6 +695,9 @@ static var_entry var_table[] = { #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) diff --git a/src/src/globals.c b/src/src/globals.c index ef1c1fd02..22bd69e01 100644 --- a/src/src/globals.c +++ b/src/src/globals.c @@ -103,6 +103,10 @@ tls_support tls_in = { -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 */ @@ -116,6 +120,10 @@ tls_support tls_out = { -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 */ @@ -634,6 +642,9 @@ BOOL dmarc_enable_forensic = FALSE; 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; @@ -1385,7 +1396,7 @@ transport_instance transport_defaults = { 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 }; diff --git a/src/src/globals.h b/src/src/globals.h index 73793aa2e..800ec9c31 100644 --- a/src/src/globals.h +++ b/src/src/globals.h @@ -82,6 +82,10 @@ typedef struct { 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 */ @@ -386,6 +390,9 @@ extern uschar *dns_again_means_nonexist; /* Domains that are badly set up */ 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 */ diff --git a/src/src/host.c b/src/src/host.c index 00524f416..2eef0ba70 100644 --- a/src/src/host.c +++ b/src/src/host.c @@ -2207,7 +2207,7 @@ Returns: HOST_FIND_FAILED couldn't find A record 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 */ @@ -2268,7 +2268,7 @@ for (; i >= 0; i--) 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 @@ -2292,11 +2292,31 @@ for (; i >= 0; i--) 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 @@ -2562,9 +2582,14 @@ if (rc != DNS_SUCCEED && (whichrrs & HOST_FIND_BY_MX) != 0) 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) @@ -2578,7 +2603,7 @@ if (rc != DNS_SUCCEED && (whichrrs & HOST_FIND_BY_MX) != 0) 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: @@ -2609,19 +2634,11 @@ if (rc != DNS_SUCCEED) 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 diff --git a/src/src/spool_in.c b/src/src/spool_in.c index 6dcb512e4..bbb4da6aa 100644 --- a/src/src/spool_in.c +++ b/src/src/spool_in.c @@ -284,6 +284,9 @@ dkim_collect_input = FALSE; #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; @@ -492,7 +495,7 @@ for (;;) 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; diff --git a/src/src/structs.h b/src/src/structs.h index 80c23fb0a..4f7862dc5 100644 --- a/src/src/structs.h +++ b/src/src/structs.h @@ -495,6 +495,9 @@ typedef struct address_item_propagated { # 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 */ diff --git a/src/src/tls-openssl.c b/src/src/tls-openssl.c index c031b8e4d..2e95a467a 100644 --- a/src/src/tls-openssl.c +++ b/src/src/tls-openssl.c @@ -25,6 +25,10 @@ functions from the OpenSSL library. */ #ifndef DISABLE_OCSP # include <openssl/ocsp.h> #endif +#ifdef EXPERIMENTAL_DANE +# include <danessl.h> +#endif + #ifndef DISABLE_OCSP # define EXIM_OCSP_SKEW_SECONDS (300L) @@ -423,6 +427,53 @@ return verify_callback(state, x509ctx, &tls_in, &server_verify_callback_called, } +#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 * @@ -1039,7 +1090,6 @@ return i; #endif /*!DISABLE_OCSP*/ - /************************************************* * Initialize for TLS * *************************************************/ @@ -1048,13 +1098,14 @@ return i; 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 */ @@ -1463,6 +1514,9 @@ if (expciphers != NULL) 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) @@ -1576,6 +1630,147 @@ return 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 * @@ -1601,16 +1796,70 @@ tls_client_start(int fd, host_item *host, address_item *addr, 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, @@ -1641,38 +1890,26 @@ if (expciphers != 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); @@ -1703,9 +1940,34 @@ if (ob->tls_sni) } } +#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); @@ -1718,6 +1980,10 @@ if (request_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"); @@ -1726,6 +1992,11 @@ alarm(ob->command_timeout); 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); diff --git a/src/src/transports/smtp.c b/src/src/transports/smtp.c index 0dfa01958..7b2a7d559 100644 --- a/src/src/transports/smtp.c +++ b/src/src/transports/smtp.c @@ -109,6 +109,10 @@ optionlist smtp_transport_options[] = { { "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) }, @@ -118,6 +122,10 @@ optionlist smtp_transport_options[] = { #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) }, @@ -196,11 +204,15 @@ smtp_transport_options_block smtp_transport_option_defaults = { 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 */ @@ -1576,8 +1588,13 @@ if (tls_out.active >= 0) /* 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", @@ -3277,10 +3294,16 @@ for (cutoff_retry = 0; expired && 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); @@ -3294,7 +3317,7 @@ for (cutoff_retry = 0; expired && tpda_deferred(first_addr, host); # endif } -#endif +#endif /*SUPPORT_TLS*/ } /* Delivery attempt finished */ diff --git a/src/src/transports/smtp.h b/src/src/transports/smtp.h index 3030f3a91..4494adfb2 100644 --- a/src/src/transports/smtp.h +++ b/src/src/transports/smtp.h @@ -21,6 +21,10 @@ typedef struct { 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 diff --git a/src/src/verify.c b/src/src/verify.c index 8564aacc2..d2ecb9cde 100644 --- a/src/src/verify.c +++ b/src/src/verify.c @@ -661,9 +661,16 @@ else 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 @@ -697,8 +704,13 @@ else /* 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", diff --git a/test/aux-fixed/exim-ca/example.com/server1.example.com/fullchain.pem b/test/aux-fixed/exim-ca/example.com/server1.example.com/fullchain.pem new file mode 100644 index 000000000..27ee5ef4f --- /dev/null +++ b/test/aux-fixed/exim-ca/example.com/server1.example.com/fullchain.pem @@ -0,0 +1,58 @@ +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----- diff --git a/test/aux-fixed/exim-ca/genall b/test/aux-fixed/exim-ca/genall index d1901fe7e..0e3feb25e 100755 --- a/test/aux-fixed/exim-ca/genall +++ b/test/aux-fixed/exim-ca/genall @@ -17,6 +17,16 @@ do 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 diff --git a/test/confs/5800 b/test/confs/5800 new file mode 100644 index 000000000..bd0b77df2 --- /dev/null +++ b/test/confs/5800 @@ -0,0 +1,10 @@ +# 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 ----- + diff --git a/test/confs/5820 b/test/confs/5820 new file mode 100644 index 000000000..f1bd09d1c --- /dev/null +++ b/test/confs/5820 @@ -0,0 +1,74 @@ +# 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 diff --git a/test/confs/5840 b/test/confs/5840 new file mode 100644 index 000000000..4359b9a59 --- /dev/null +++ b/test/confs/5840 @@ -0,0 +1,83 @@ +# 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 diff --git a/test/confs/5860 b/test/confs/5860 new file mode 100644 index 000000000..7dc4b0952 --- /dev/null +++ b/test/confs/5860 @@ -0,0 +1,88 @@ +# 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 diff --git a/test/dnszones-src/db.test.ex b/test/dnszones-src/db.test.ex index 843a35b09..4ec367cc9 100644 --- a/test/dnszones-src/db.test.ex +++ b/test/dnszones-src/db.test.ex @@ -77,6 +77,7 @@ badloop A V4NET.0.0.1 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. @@ -382,4 +383,20 @@ _client._smtp.csa2 SRV 1 1 0 csa2.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 diff --git a/test/log/5840 b/test/log/5840 new file mode 100644 index 000000000..62dc13f02 --- /dev/null +++ b/test/log/5840 @@ -0,0 +1,30 @@ +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 diff --git a/test/log/5860 b/test/log/5860 new file mode 100644 index 000000000..7c1bf6657 --- /dev/null +++ b/test/log/5860 @@ -0,0 +1,40 @@ +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 diff --git a/test/runtest b/test/runtest index 57caa2c1f..a647b229a 100755 --- a/test/runtest +++ b/test/runtest @@ -999,6 +999,11 @@ RESET_AFTER_EXTRA_LINE_READ: @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. diff --git a/test/scripts/5800-DANE/5800 b/test/scripts/5800-DANE/5800 new file mode 100644 index 000000000..98a70c115 --- /dev/null +++ b/test/scripts/5800-DANE/5800 @@ -0,0 +1,12 @@ +# 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}} + +**** diff --git a/test/scripts/5800-DANE/REQUIRES b/test/scripts/5800-DANE/REQUIRES new file mode 100644 index 000000000..2314a3236 --- /dev/null +++ b/test/scripts/5800-DANE/REQUIRES @@ -0,0 +1,2 @@ +support Experimental_DANE +running IPv4 diff --git a/test/scripts/5820-DANE-GnuTLS/5820 b/test/scripts/5820-DANE-GnuTLS/5820 new file mode 100644 index 000000000..07ad7406d --- /dev/null +++ b/test/scripts/5820-DANE-GnuTLS/5820 @@ -0,0 +1,14 @@ +# DANE client: general +# +gnutls +# +exim -DSERVER=server -bd -oX PORT_D +**** +exim CALLER@test.ex +Testing +**** +exim -qf +**** +killdaemon +exim -DSERVER=server -DNOTDAEMON -qf +**** diff --git a/test/scripts/5820-DANE-GnuTLS/REQUIRES b/test/scripts/5820-DANE-GnuTLS/REQUIRES new file mode 100644 index 000000000..4234c92f8 --- /dev/null +++ b/test/scripts/5820-DANE-GnuTLS/REQUIRES @@ -0,0 +1,3 @@ +support Experimental_DANE +support GnuTLS +running IPv4 diff --git a/test/scripts/5840-DANE-OpenSSL/5840 b/test/scripts/5840-DANE-OpenSSL/5840 new file mode 100644 index 000000000..814b4b0e8 --- /dev/null +++ b/test/scripts/5840-DANE-OpenSSL/5840 @@ -0,0 +1,30 @@ +# 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 +**** diff --git a/test/scripts/5840-DANE-OpenSSL/REQUIRES b/test/scripts/5840-DANE-OpenSSL/REQUIRES new file mode 100644 index 000000000..59cb7dc91 --- /dev/null +++ b/test/scripts/5840-DANE-OpenSSL/REQUIRES @@ -0,0 +1,3 @@ +support Experimental_DANE +support OpenSSL +running IPv4 diff --git a/test/scripts/5860-DANE-OpenSSL-TPDA/5860 b/test/scripts/5860-DANE-OpenSSL-TPDA/5860 new file mode 100644 index 000000000..94bc4d2b8 --- /dev/null +++ b/test/scripts/5860-DANE-OpenSSL-TPDA/5860 @@ -0,0 +1,30 @@ +# 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 +**** diff --git a/test/scripts/5860-DANE-OpenSSL-TPDA/REQUIRES b/test/scripts/5860-DANE-OpenSSL-TPDA/REQUIRES new file mode 100644 index 000000000..7e51b4fa7 --- /dev/null +++ b/test/scripts/5860-DANE-OpenSSL-TPDA/REQUIRES @@ -0,0 +1,4 @@ +support Experimental_DANE +support Experimental_TPDA +support OpenSSL +running IPv4 diff --git a/test/src/fakens.c b/test/src/fakens.c index fa4431810..fd3604a3c 100644 --- a/test/src/fakens.c +++ b/test/src/fakens.c @@ -48,7 +48,11 @@ line in the zone file contains exactly this: 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> @@ -95,21 +99,25 @@ not defined, assume we are in this state. A really old system might not even 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[] = { @@ -122,6 +130,7 @@ 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 } }; @@ -185,6 +194,33 @@ while (*name != 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; +} + /************************************************* @@ -209,7 +245,7 @@ Returns: 0 on success, else HOST_NOT_FOUND or NO_DATA or NO_RECOVERY or 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); @@ -233,6 +269,8 @@ if (typeptr->name == NULL) 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) @@ -243,12 +281,13 @@ 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; @@ -259,6 +298,12 @@ while (fgets(CS buffer, sizeof(buffer), f) != NULL) *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; @@ -311,6 +356,9 @@ while (fgets(CS buffer, sizeof(buffer), f) != NULL) /* Found a relevant record */ + if (!rr_sec) + *dnssec = FALSE; /* cancel AD return */ + yield = 0; *countptr = *countptr + 1; @@ -371,11 +419,7 @@ while (fgets(CS buffer, sizeof(buffer), f) != NULL) 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); @@ -388,6 +432,23 @@ while (fgets(CS buffer, sizeof(buffer), f) != NULL) *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++) { @@ -444,6 +505,7 @@ uschar buffer[256]; uschar qtype[12]; uschar packet[512]; uschar *pk = packet; +BOOL dnssec; if (argc != 4) { @@ -545,7 +607,7 @@ if (f == NULL) /* 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; @@ -557,6 +619,9 @@ packet[7] = count & 255; packet[10] = 0; packet[11] = 0; +if (dnssec) + ((HEADER *)packet)->ad = 1; + /* Close the zone file, write the result, and return. */ END_OFF: @@ -565,4 +630,6 @@ END_OFF: return yield; } +/* vi: aw ai sw=2 +*/ /* End of fakens.c */ diff --git a/test/stdout/5800 b/test/stdout/5800 new file mode 100644 index 000000000..b9c64fea0 --- /dev/null +++ b/test/stdout/5800 @@ -0,0 +1,4 @@ +> +> dnslookup tlsa: 3 1 2 3d5eb81b1dfc3f93c1fa8819e3fb3fdb41bb590441d5f3811db17772f4bc6de29bdd7c4f4b723750dda871b99379192b3f979f03db1252c4f08b03ef7176528d +> +> |