]> University of Cambridge Computing Service

New Museums Site Pembroke Street Cambridge CB2 3QH ENGLAND +44 797 040 1426 dot@dotat.at http://dotat.at/

Security DNS-Based Authentication of Named Entities (DANE) This specification describes the effect that DNSSEC has on SRV-based autoconfiguration and TLS certificate verification in the mail user agent protocols IMAP, POP3, and message submission. It also describes how to use TLSA DNS records to provide stronger authentication of server TLS certificates.

The mail user agent protocols IMAP , POP3 , and message submission support upgrade from cleartext to TLS . The STARTTLS command is part of the core IMAP specification . Message submission is a profile of SMTP for which there is a STARTTLS extension . In POP3 the equivalent command is STLS . IMAP and POP3 are also often deployed using TLS-on-connect on alternate TCP ports. specifies how an MUA can use SRV records to automatically locate mail server host names given the user's mail domain. of this specification updates to clarify how MUAs handle mail server SRV records and TLS negotiation in the presence and absence of DNSSEC. of this specification describes how to use TLSA DNS records to provide stronger authentication of server TLS certificates. We also use the existance of a TLSA record to signal to the MUA that it can expect the server to offer TLS. In the rest of this memo, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in .

When negotiating TLS, the MUA MUST use the Server Name Indication extension (TLS SNI) with its preferred name as defined below. This is a stricter requirement than . When a security-aware MUA looks up SRV records, it SHALL take note of the DNSSEC status of each record. It constructs the list of reference identifiers for verifying each server's TLS certificate and chooses the preferred name for TLS SNI as follows: The MUA MUST abort. (If this occurs during auto-configuration, it might fall back to a manual setup procedure.) The reference identifiers SHALL include the source domain (i.e. the user's mail domain) and MUST NOT include the derived domain (i.e. the SRV target host name). The source domain is the preferred name for TLS SNI. The reference identifiers SHALL include both the source domain (i.e. the user's mail domain) and the derived domain (i.e. the SRV target host name). The derived domain is the preferred name for TLS SNI.

MUAs SHALL look up the TLSA record(s) for a mail server using its host name and port number, as described in section 3 of . The MUA MUST only do this if the host name and port number have been obtained securely, from the "target" and "port" fields of a SRV record that is secure as described in the previous section, or from user configuration. If a TLSA record is usable as described in section 4.1 of , then the server MUST support TLS. It MUST present a certificate that matches the TLSA record and that authenticates the server host name. When an MUA is configuring itself as described in section 4 of , it SHOULD use the presence of a TLSA record to indicate that use of TLS is obligatory when connecting to the corresponding server.

A mail server that is the target of an SRV record MUST have a TLS certificate that authenticates the SRV owner domain (i.e. the user's mail domain). This is necessary for clients that cannot perform DNSSEC validation. This certificate MUST be the default that is presented if the client does not use the TLS Server Name Indication extension (TLS SNI) . In order to support this specification, the mail server MUST also have a certificate that authenticates the SRV target domain (the mail server hostname). This can be done using a multi-name certificate or by using the client's TLS SNI to select the appropriate certificate. The mail server's TLSA record MUST correspond to this certificate. Note: old pre- clients expect a mail server's TLS certificate to authenticate its host name; they are also unlikely to support SNI. This means that servers for old clients need a different default certificate from servers. If the server does not have a certificate that authenticates all relevant names, it is necessary to segregate old and new clients. This can be done by using different target hosts or non-standard ports in the SRV targets. (The latter avoids the need for yet more certificates.)

In order to support this specification, mail server software MUST implement the TLS Server Name Indication extension for selecting the appropriate certificate.

The MUA autoconfiguration specification does not have a complete mechanism for signalling whether a server supports TLS. IMAP and POP3 have alternate TLS-on-connect ports, but not message submission. This gap is filled by using the presence of TLSA records to indicate that a client can expect a server to support TLS. This prevents a downgrade attack. The guidance in is mostly a straightforward consequence of the requirements set out in and .

If any of the DNS queries are for an internationalized domain name, then they need to use the A-label form .

No IANA action is needed.

&rfc1939; &rfc2119; &rfc2595; &rfc3207; &rfc3501; &rfc4033; &rfc4409; &rfc5321; &rfc5246; &rfc5890; &rfc6066; &rfc6125; &rfc6186;

The long-term goal of this specification is to settle on TLS certificates that verify the server host name rather than the mail domain, since this is more convenient for servers hosting multiple domains and scales up more easily to larger numbers of domains. There are a number of other reasons for doing it this way: The certificate is part of the server configuration, so it makes sense to associate it with the server name rather than the mail domain. When the server certificate is replaced it is much easier if there is one part of the DNS that needs updating to match, instead of an unbounded number of hosted mail domains. The same TLSA records work with and without SRV records. Consistency with and . There is no option to put TLSA records under the mail domain in order to keep the specification simple and to make it easier to deploy correctly. The disadvantage is that the expected certificate differs between pure clients and clients that are implemented to this spec. This means that Server Name Indication support is necessary for backwards compatibility.