Update ChangeLog
[exim.git] / doc / doc-txt / draft-ietf-dane-smtp-with-dane-12.txt
1
2
3
4
5 DANE                                                         V. Dukhovni
6 Internet-Draft                                                 Two Sigma
7 Intended status: Standards Track                             W. Hardaker
8 Expires: February 18, 2015                                       Parsons
9                                                          August 17, 2014
10
11
12                 SMTP security via opportunistic DANE TLS
13                    draft-ietf-dane-smtp-with-dane-12
14
15 Abstract
16
17    This memo describes a downgrade-resistant protocol for SMTP transport
18    security between Mail Transfer Agents (MTAs) based on the DNS-Based
19    Authentication of Named Entities (DANE) TLSA DNS record.  Adoption of
20    this protocol enables an incremental transition of the Internet email
21    backbone to one using encrypted and authenticated Transport Layer
22    Security (TLS).
23
24 Status of This Memo
25
26    This Internet-Draft is submitted in full conformance with the
27    provisions of BCP 78 and BCP 79.
28
29    Internet-Drafts are working documents of the Internet Engineering
30    Task Force (IETF).  Note that other groups may also distribute
31    working documents as Internet-Drafts.  The list of current Internet-
32    Drafts is at http://datatracker.ietf.org/drafts/current/.
33
34    Internet-Drafts are draft documents valid for a maximum of six months
35    and may be updated, replaced, or obsoleted by other documents at any
36    time.  It is inappropriate to use Internet-Drafts as reference
37    material or to cite them other than as "work in progress."
38
39    This Internet-Draft will expire on February 18, 2015.
40
41 Copyright Notice
42
43    Copyright (c) 2014 IETF Trust and the persons identified as the
44    document authors.  All rights reserved.
45
46    This document is subject to BCP 78 and the IETF Trust's Legal
47    Provisions Relating to IETF Documents
48    (http://trustee.ietf.org/license-info) in effect on the date of
49    publication of this document.  Please review these documents
50    carefully, as they describe your rights and restrictions with respect
51    to this document.  Code Components extracted from this document must
52    include Simplified BSD License text as described in Section 4.e of
53
54
55
56 Dukhovni & Hardaker     Expires February 18, 2015               [Page 1]
57 \f
58 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
59
60
61    the Trust Legal Provisions and are provided without warranty as
62    described in the Simplified BSD License.
63
64 Table of Contents
65
66    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
67      1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
68      1.2.  Background  . . . . . . . . . . . . . . . . . . . . . . .   5
69      1.3.  SMTP channel security . . . . . . . . . . . . . . . . . .   6
70        1.3.1.  STARTTLS downgrade attack . . . . . . . . . . . . . .   6
71        1.3.2.  Insecure server name without DNSSEC . . . . . . . . .   7
72        1.3.3.  Sender policy does not scale  . . . . . . . . . . . .   8
73        1.3.4.  Too many certification authorities  . . . . . . . . .   8
74    2.  Identifying applicable TLSA records . . . . . . . . . . . . .   9
75      2.1.  DNS considerations  . . . . . . . . . . . . . . . . . . .   9
76        2.1.1.  DNS errors, bogus and indeterminate responses . . . .   9
77        2.1.2.  DNS error handling  . . . . . . . . . . . . . . . . .  11
78        2.1.3.  Stub resolver considerations  . . . . . . . . . . . .  12
79      2.2.  TLS discovery . . . . . . . . . . . . . . . . . . . . . .  13
80        2.2.1.  MX resolution . . . . . . . . . . . . . . . . . . . .  14
81        2.2.2.  Non-MX destinations . . . . . . . . . . . . . . . . .  15
82        2.2.3.  TLSA record lookup  . . . . . . . . . . . . . . . . .  17
83    3.  DANE authentication . . . . . . . . . . . . . . . . . . . . .  19
84      3.1.  TLSA certificate usages . . . . . . . . . . . . . . . . .  19
85        3.1.1.  Certificate usage DANE-EE(3)  . . . . . . . . . . . .  21
86        3.1.2.  Certificate usage DANE-TA(2)  . . . . . . . . . . . .  22
87        3.1.3.  Certificate usages PKIX-TA(0) and PKIX-EE(1)  . . . .  23
88      3.2.  Certificate matching  . . . . . . . . . . . . . . . . . .  24
89        3.2.1.  DANE-EE(3) name checks  . . . . . . . . . . . . . . .  24
90        3.2.2.  DANE-TA(2) name checks  . . . . . . . . . . . . . . .  24
91        3.2.3.  Reference identifier matching . . . . . . . . . . . .  25
92    4.  Server key management . . . . . . . . . . . . . . . . . . . .  26
93    5.  Digest algorithm agility  . . . . . . . . . . . . . . . . . .  26
94    6.  Mandatory TLS Security  . . . . . . . . . . . . . . . . . . .  27
95    7.  Note on DANE for Message User Agents  . . . . . . . . . . . .  27
96    8.  Interoperability considerations . . . . . . . . . . . . . . .  28
97      8.1.  SNI support . . . . . . . . . . . . . . . . . . . . . . .  28
98      8.2.  Anonymous TLS cipher suites . . . . . . . . . . . . . . .  28
99    9.  Operational Considerations  . . . . . . . . . . . . . . . . .  29
100      9.1.  Client Operational Considerations . . . . . . . . . . . .  29
101      9.2.  Publisher Operational Considerations  . . . . . . . . . .  30
102    10. Security Considerations . . . . . . . . . . . . . . . . . . .  30
103    11. IANA considerations . . . . . . . . . . . . . . . . . . . . .  31
104    12. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  31
105    13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  31
106      13.1.  Normative References . . . . . . . . . . . . . . . . . .  31
107      13.2.  Informative References . . . . . . . . . . . . . . . . .  32
108    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  33
109
110
111
112 Dukhovni & Hardaker     Expires February 18, 2015               [Page 2]
113 \f
114 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
115
116
117 1.  Introduction
118
119    This memo specifies a new connection security model for Message
120    Transfer Agents (MTAs).  This model is motivated by key features of
121    inter-domain SMTP delivery, in particular the fact that the
122    destination server is selected indirectly via DNS Mail Exchange (MX)
123    records and that neither email addresses nor MX hostnames signal a
124    requirement for either secure or cleartext transport.  Therefore,
125    aside from a few manually configured exceptions, SMTP transport
126    security is of necessity opportunistic.
127
128    This specification uses the presence of DANE TLSA records to securely
129    signal TLS support and to publish the means by which SMTP clients can
130    successfully authenticate legitimate SMTP servers.  This becomes
131    "opportunistic DANE TLS" and is resistant to downgrade and man-in-
132    the-middle (MITM) attacks.  It enables an incremental transition of
133    the email backbone to authenticated TLS delivery, with increased
134    global protection as adoption increases.
135
136    With opportunistic DANE TLS, traffic from SMTP clients to domains
137    that publish "usable" DANE TLSA records in accordance with this memo
138    is authenticated and encrypted.  Traffic from legacy clients or to
139    domains that do not publish TLSA records will continue to be sent in
140    the same manner as before, via manually configured security, (pre-
141    DANE) opportunistic TLS or just cleartext SMTP.
142
143    Problems with existing use of TLS in MTA to MTA SMTP that motivate
144    this specification are described in Section 1.3.  The specification
145    itself follows in Section 2 and Section 3 which describe respectively
146    how to locate and use DANE TLSA records with SMTP.  In Section 6, we
147    discuss application of DANE TLS to destinations for which channel
148    integrity and confidentiality are mandatory.  In Section 7 we briefly
149    comment on potential applicability of this specification to Message
150    User Agents.
151
152 1.1.  Terminology
153
154    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
155    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
156    "OPTIONAL" in this document are to be interpreted as described in
157    [RFC2119].
158
159    The following terms or concepts are used through the document:
160
161    Man-in-the-middle or MITM attack:  Active modification of network
162       traffic by an adversary able to thereby compromise the
163       confidentiality or integrity of the data.
164
165
166
167
168 Dukhovni & Hardaker     Expires February 18, 2015               [Page 3]
169 \f
170 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
171
172
173    secure, bogus, insecure, indeterminate:  DNSSEC validation results,
174       as defined in Section 4.3 of [RFC4035].
175
176    Validating Security-Aware Stub Resolver and     Non-Validating
177    Security-Aware Stub Resolver:
178       Capabilities of the stub resolver in use as defined in [RFC4033];
179       note that this specification requires the use of a Security-Aware
180       Stub Resolver.
181
182    (pre-DANE) opportunistic TLS:  Best-effort use of TLS that is
183       generally vulnerable to DNS forgery and STARTTLS downgrade
184       attacks.  When a TLS-encrypted communication channel is not
185       available, message transmission takes place in the clear.  MX
186       record indirection generally precludes authentication even when
187       TLS is available.
188
189    opportunistic DANE TLS:  Best-effort use of TLS, resistant to
190       downgrade attacks for destinations with DNSSEC-validated TLSA
191       records.  When opportunistic DANE TLS is determined to be
192       unavailable, clients should fall back to opportunistic TLS.
193       Opportunistic DANE TLS requires support for DNSSEC, DANE and
194       STARTTLS on the client side and STARTTLS plus a DNSSEC published
195       TLSA record on the server side.
196
197    reference identifier:  (Special case of [RFC6125] definition).  One
198       of the domain names associated by the SMTP client with the
199       destination SMTP server for performing name checks on the server
200       certificate.  When name checks are applicable, at least one of the
201       reference identifiers MUST match an [RFC6125] DNS-ID (or if none
202       are present the [RFC6125] CN-ID) of the server certificate (see
203       Section 3.2.3).
204
205    MX hostname:  The RRDATA of an MX record consists of a 16 bit
206       preference followed by a Mail Exchange domain name (see [RFC1035],
207       Section 3.3.9).  We will use the term "MX hostname" to refer to
208       the latter, that is, the DNS domain name found after the
209       preference value in an MX record.  Thus an "MX hostname" is
210       specifically a reference to a DNS domain name, rather than any
211       host that bears that name.
212
213    delayed delivery:  Email delivery is a multi-hop store & forward
214       process.  When an MTA is unable forward a message that may become
215       deliverable later the message is queued and delivery is retried
216       periodically.  Some MTAs may be configured with a fallback next-
217       hop destination that handles messages that the MTA would otherwise
218       queue and retry.  When a fallback next-hop is configured, messages
219       that would otherwise have to be delayed may be sent to the
220       fallback next-hop destination instead.  The fallback destination
221
222
223
224 Dukhovni & Hardaker     Expires February 18, 2015               [Page 4]
225 \f
226 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
227
228
229       may itself be subject to opportunistic or mandatory DANE TLS as
230       though it were the original message destination.
231
232    original next hop destination:   The logical destination for mail
233       delivery.  By default this is the domain portion of the recipient
234       address, but MTAs may be configured to forward mail for some or
235       all recipients via designated relays.  The original next hop
236       destination is, respectively, either the recipient domain or the
237       associated configured relay.
238
239    MTA:   Message Transfer Agent ([RFC5598], Section 4.3.2).
240
241    MSA:   Message Submission Agent ([RFC5598], Section 4.3.1).
242
243    MUA:   Message User Agent ([RFC5598], Section 4.2.1).
244
245    RR:   A DNS Resource Record
246
247    RRset:   A set of DNS Resource Records for a particular class, domain
248       and record type.
249
250 1.2.  Background
251
252    The Domain Name System Security Extensions (DNSSEC) add data origin
253    authentication, data integrity and data non-existence proofs to the
254    Domain Name System (DNS).  DNSSEC is defined in [RFC4033], [RFC4034]
255    and [RFC4035].
256
257    As described in the introduction of [RFC6698], TLS authentication via
258    the existing public Certification Authority (CA) PKI suffers from an
259    over-abundance of trusted parties capable of issuing certificates for
260    any domain of their choice.  DANE leverages the DNSSEC infrastructure
261    to publish trusted public keys and certificates for use with the
262    Transport Layer Security (TLS) [RFC5246] protocol via a new "TLSA"
263    DNS record type.  With DNSSEC each domain can only vouch for the keys
264    of its directly delegated sub-domains.
265
266    The TLS protocol enables secure TCP communication.  In the context of
267    this memo, channel security is assumed to be provided by TLS.  Used
268    without authentication, TLS provides only privacy protection against
269    eavesdropping attacks.  With authentication, TLS also provides data
270    integrity protection to guard against MITM attacks.
271
272
273
274
275
276
277
278
279
280 Dukhovni & Hardaker     Expires February 18, 2015               [Page 5]
281 \f
282 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
283
284
285 1.3.  SMTP channel security
286
287    With HTTPS, Transport Layer Security (TLS) employs X.509 certificates
288    [RFC5280] issued by one of the many Certificate Authorities (CAs)
289    bundled with popular web browsers to allow users to authenticate
290    their "secure" websites.  Before we specify a new DANE TLS security
291    model for SMTP, we will explain why a new security model is needed.
292    In the process, we will explain why the familiar HTTPS security model
293    is inadequate to protect inter-domain SMTP traffic.
294
295    The subsections below outline four key problems with applying
296    traditional PKI to SMTP that are addressed by this specification.
297    Since SMTP channel security policy is not explicitly specified in
298    either the recipient address or the MX record, a new signaling
299    mechanism is required to indicate when channel security is possible
300    and should be used.  The publication of TLSA records allows server
301    operators to securely signal to SMTP clients that TLS is available
302    and should be used.  DANE TLSA makes it possible to simultaneously
303    discover which destination domains support secure delivery via TLS
304    and how to verify the authenticity of the associated SMTP services,
305    providing a path forward to ubiquitous SMTP channel security.
306
307 1.3.1.  STARTTLS downgrade attack
308
309    The Simple Mail Transfer Protocol (SMTP) [RFC5321] is a single-hop
310    protocol in a multi-hop store & forward email delivery process.  An
311    SMTP envelope recipient address does not correspond to a specific
312    transport-layer endpoint address, rather at each relay hop the
313    transport-layer endpoint is the next-hop relay, while the envelope
314    recipient address typically remains the same.  Unlike the Hypertext
315    Transfer Protocol (HTTP) and its corresponding secured version,
316    HTTPS, where the use of TLS is signaled via the URI scheme, email
317    recipient addresses do not directly signal transport security policy.
318    Indeed, no such signaling could work well with SMTP since TLS
319    encryption of SMTP protects email traffic on a hop-by-hop basis while
320    email addresses could only express end-to-end policy.
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336 Dukhovni & Hardaker     Expires February 18, 2015               [Page 6]
337 \f
338 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
339
340
341    With no mechanism available to signal transport security policy, SMTP
342    relays employ a best-effort "opportunistic" security model for TLS.
343    A single SMTP server TCP listening endpoint can serve both TLS and
344    non-TLS clients; the use of TLS is negotiated via the SMTP STARTTLS
345    command ([RFC3207]).  The server signals TLS support to the client
346    over a cleartext SMTP connection, and, if the client also supports
347    TLS, it may negotiate a TLS encrypted channel to use for email
348    transmission.  The server's indication of TLS support can be easily
349    suppressed by an MITM attacker.  Thus pre-DANE SMTP TLS security can
350    be subverted by simply downgrading a connection to cleartext.  No TLS
351    security feature, such as the use of PKIX, can prevent this.  The
352    attacker can simply disable TLS.
353
354 1.3.2.  Insecure server name without DNSSEC
355
356    With SMTP, DNS Mail Exchange (MX) records abstract the next-hop
357    transport endpoint and allow administrators to specify a set of
358    target servers to which SMTP traffic should be directed for a given
359    domain.
360
361    A PKIX TLS client is vulnerable to MITM attacks unless it verifies
362    that the server's certificate binds the public key to a name that
363    matches one of the client's reference identifiers.  A natural choice
364    of reference identifier is the server's domain name.  However, with
365    SMTP, server names are not directly encoded in the recipient address,
366    instead they are obtained indirectly via MX records.  Without DNSSEC,
367    the MX lookup is vulnerable to MITM and DNS cache poisoning attacks.
368    Active attackers can forge DNS replies with fake MX records and can
369    redirect email to servers with names of their choice.  Therefore,
370    secure verification of SMTP TLS certificates matching the server name
371    is not possible without DNSSEC.
372
373    One might try to harden TLS for SMTP against DNS attacks by using the
374    envelope recipient domain as a reference identifier and requiring
375    each SMTP server to possess a trusted certificate for the envelope
376    recipient domain rather than the MX hostname.  Unfortunately, this is
377    impractical as email for many domains is handled by third parties
378    that are not in a position to obtain certificates for all the domains
379    they serve.  Deployment of the Server Name Indication (SNI) extension
380    to TLS (see [RFC6066] Section 3) is no panacea, since SNI key
381    management is operationally challenging except when the email service
382    provider is also the domain's registrar and its certificate issuer;
383    this is rarely the case for email.
384
385    Since the recipient domain name cannot be used as the SMTP server
386    reference identifier, and neither can the MX hostname without DNSSEC,
387    large-scale deployment of authenticated TLS for SMTP requires that
388    the DNS be secure.
389
390
391
392 Dukhovni & Hardaker     Expires February 18, 2015               [Page 7]
393 \f
394 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
395
396
397    Since SMTP security depends critically on DNSSEC, it is important to
398    point out that consequently SMTP with DANE is the most conservative
399    possible trust model.  It trusts only what must be trusted and no
400    more.  Adding any other trusted actors to the mix can only reduce
401    SMTP security.  A sender may choose to further harden DNSSEC for
402    selected high-value receiving domains by configuring explicit trust
403    anchors for those domains instead of relying on the chain of trust
404    from the root domain.  However, detailed discussion of DNSSEC
405    security practices is out of scope for this document.
406
407 1.3.3.  Sender policy does not scale
408
409    Sending systems are in some cases explicitly configured to use TLS
410    for mail sent to selected peer domains.  This requires sending MTAs
411    to be configured with appropriate subject names or certificate
412    content digests to expect in the presented server certificates.
413    Because of the heavy administrative burden, such statically
414    configured SMTP secure channels are used rarely (generally only
415    between domains that make bilateral arrangements with their business
416    partners).  Internet email, on the other hand, requires regularly
417    contacting new domains for which security configurations cannot be
418    established in advance.
419
420    The abstraction of the SMTP transport endpoint via DNS MX records,
421    often across organization boundaries, limits the use of public CA PKI
422    with SMTP to a small set of sender-configured peer domains.  With
423    little opportunity to use TLS authentication, sending MTAs are rarely
424    configured with a comprehensive list of trusted CAs.  SMTP services
425    that support STARTTLS often deploy X.509 certificates that are self-
426    signed or issued by a private CA.
427
428 1.3.4.  Too many certification authorities
429
430    Even if it were generally possible to determine a secure server name,
431    the SMTP client would still need to verify that the server's
432    certificate chain is issued by a trusted Certification Authority (a
433    trust anchor).  MTAs are not interactive applications where a human
434    operator can make a decision (wisely or otherwise) to selectively
435    disable TLS security policy when certificate chain verification
436    fails.  With no user to "click OK", the MTA's list of public CA trust
437    anchors would need to be comprehensive in order to avoid bouncing
438    mail addressed to sites that employ unknown Certification
439    Authorities.
440
441
442
443
444
445
446
447
448 Dukhovni & Hardaker     Expires February 18, 2015               [Page 8]
449 \f
450 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
451
452
453    On the other hand, each trusted CA can issue certificates for any
454    domain.  If even one of the configured CAs is compromised or operated
455    by an adversary, it can subvert TLS security for all destinations.
456    Any set of CAs is simultaneously both overly inclusive and not
457    inclusive enough.
458
459 2.  Identifying applicable TLSA records
460
461 2.1.  DNS considerations
462
463 2.1.1.  DNS errors, bogus and indeterminate responses
464
465    An SMTP client that implements opportunistic DANE TLS per this
466    specification depends critically on the integrity of DNSSEC lookups,
467    as discussed in Section 1.3.2.  This section lists the DNS resolver
468    requirements needed to avoid downgrade attacks when using
469    opportunistic DANE TLS.
470
471    A DNS lookup may signal an error or return a definitive answer.  A
472    security-aware resolver must be used for this specification.
473    Security-aware resolvers will indicate the security status of a DNS
474    RRset with one of four possible values defined in Section 4.3 of
475    [RFC4035]: "secure", "insecure", "bogus" and "indeterminate".  In
476    [RFC4035] the meaning of the "indeterminate" security status is:
477
478      An RRset for which the resolver is not able to determine whether
479      the RRset should be signed, as the resolver is not able to obtain
480      the necessary DNSSEC RRs.  This can occur when the security-aware
481      resolver is not able to contact security-aware name servers for
482      the relevant zones.
483
484    Note, the "indeterminate" security status has a conflicting
485    definition in section 5 of [RFC4033].
486
487      There is no trust anchor that would indicate that a specific
488      portion of the tree is secure.
489
490    To avoid further confusion, the adjective "anchorless" will be used
491    below to refer to domains or RRsets that are "indeterminate" in the
492    [RFC4033] sense, and the term "indeterminate" will be used
493    exclusively in the sense of [RFC4035].
494
495    SMTP clients following this specification SHOULD NOT distinguish
496    between "insecure" and "anchorless" DNS responses.  Both "insecure"
497    and "anchorless" RRsets MUST be handled identically: in either case
498    unvalidated data for the query domain is all that is and can be
499    available, and authentication using the data is impossible.  In what
500    follows, the term "insecure" will also include the case of
501
502
503
504 Dukhovni & Hardaker     Expires February 18, 2015               [Page 9]
505 \f
506 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
507
508
509    "anchorless" domains that lie in a portion of the DNS tree for which
510    there is no applicable trust anchor.  With the DNS root zone signed,
511    we expect that validating resolvers used by Internet-facing MTAs will
512    be configured with trust anchor data for the root zone, and that
513    therefore "anchorless" domains should be rare in practice.
514
515    As noted in section 4.3 of [RFC4035], a security-aware DNS resolver
516    MUST be able to determine whether a given non-error DNS response is
517    "secure", "insecure", "bogus" or "indeterminate".  It is expected
518    that most security-aware stub resolvers will not signal an
519    "indeterminate" security status (in the sense of RFC4035) to the
520    application, and will signal a "bogus" or error result instead.  If a
521    resolver does signal an RFC4035 "indeterminate" security status, this
522    MUST be treated by the SMTP client as though a "bogus" or error
523    result had been returned.
524
525    An MTA making use of a non-validating security-aware stub resolver
526    MAY use the stub resolver's ability, if available, to signal DNSSEC
527    validation status based on information the stub resolver has learned
528    from an upstream validating recursive resolver.  Security-Oblivious
529    stub-resolvers MUST NOT be used.  In accordance with section 4.9.3 of
530    [RFC4035]:
531
532      ... a security-aware stub resolver MUST NOT place any reliance on
533      signature validation allegedly performed on its behalf, except
534      when the security-aware stub resolver obtained the data in question
535      from a trusted security-aware recursive name server via a secure
536      channel.
537
538    To avoid much repetition in the text below, we will pause to explain
539    the handling of "bogus" or "indeterminate" DNSSEC query responses.
540    These are not necessarily the result of a malicious actor; they can,
541    for example, occur when network packets are corrupted or lost in
542    transit.  Therefore, "bogus" or "indeterminate" replies are equated
543    in this memo with lookup failure.
544
545    There is an important non-failure condition we need to highlight in
546    addition to the obvious case of the DNS client obtaining a non-empty
547    "secure" or "insecure" RRset of the requested type.  Namely, it is
548    not an error when either "secure" or "insecure" non-existence is
549    determined for the requested data.  When a DNSSEC response with a
550    validation status that is either "secure" or "insecure" reports
551    either no records of the requested type or non-existence of the query
552    domain, the response is not a DNS error condition.  The DNS client
553    has not been left without an answer; it has learned that records of
554    the requested type do not exist.
555
556
557
558
559
560 Dukhovni & Hardaker     Expires February 18, 2015              [Page 10]
561 \f
562 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
563
564
565    Security-aware stub resolvers will, of course, also signal DNS lookup
566    errors in other cases, for example when processing a "ServFail"
567    RCODE, which will not have an associated DNSSEC status.  All lookup
568    errors are treated the same way by this specification, regardless of
569    whether they are from a "bogus" or "indeterminate" DNSSEC status or
570    from a more generic DNS error: the information that was requested
571    cannot be obtained by the security-aware resolver at this time.  A
572    lookup error is thus a failure to obtain the relevant RRset if it
573    exists, or to determine that no such RRset exists when it does not.
574
575    In contrast to a "bogus" or an "indeterminate" response, an
576    "insecure" DNSSEC response is not an error, rather it indicates that
577    the target DNS zone is either securely opted out of DNSSEC validation
578    or is not connected with the DNSSEC trust anchors being used.
579    Insecure results will leave the SMTP client with degraded channel
580    security, but do not stand in the way of message delivery.  See
581    section Section 2.2 for further details.
582
583 2.1.2.  DNS error handling
584
585    When a DNS lookup failure (error or "bogus" or "indeterminate" as
586    defined above) prevents an SMTP client from determining which SMTP
587    server or servers it should connect to, message delivery MUST be
588    delayed.  This naturally includes, for example, the case when a
589    "bogus" or "indeterminate" response is encountered during MX
590    resolution.  When multiple MX hostnames are obtained from a
591    successful MX lookup, but a later DNS lookup failure prevents network
592    address resolution for a given MX hostname, delivery may proceed via
593    any remaining MX hosts.
594
595    When a particular SMTP server is securely identified as the delivery
596    destination, a set of DNS lookups (Section 2.2) MUST be performed to
597    locate any related TLSA records.  If any DNS queries used to locate
598    TLSA records fail (be it due to "bogus" or "indeterminate" records,
599    timeouts, malformed replies, ServFails, etc.), then the SMTP client
600    MUST treat that server as unreachable and MUST NOT deliver the
601    message via that server.  If no servers are reachable, delivery is
602    delayed.
603
604    In what follows, we will only describe what happens when all relevant
605    DNS queries succeed.  If any DNS failure occurs, the SMTP client MUST
606    behave as described in this section, by skipping the problem SMTP
607    server, or the problem destination.  Queries for candidate TLSA
608    records are explicitly part of "all relevant DNS queries" and SMTP
609    clients MUST NOT continue to connect to an SMTP server or destination
610    whose TLSA record lookup fails.
611
612
613
614
615
616 Dukhovni & Hardaker     Expires February 18, 2015              [Page 11]
617 \f
618 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
619
620
621 2.1.3.  Stub resolver considerations
622
623    SMTP clients that employ opportunistic DANE TLS to secure connections
624    to SMTP servers MUST NOT use Security-Oblivious stub-resolvers.
625
626    A note about DNAME aliases: a query for a domain name whose ancestor
627    domain is a DNAME alias returns the DNAME RR for the ancestor domain
628    along with a CNAME that maps the query domain to the corresponding
629    sub-domain of the target domain of the DNAME alias [RFC6672].
630    Therefore, whenever we speak of CNAME aliases, we implicitly allow
631    for the possibility that the alias in question is the result of an
632    ancestor domain DNAME record.  Consequently, no explicit support for
633    DNAME records is needed in SMTP software; it is sufficient to process
634    the resulting CNAME aliases.  DNAME records only require special
635    processing in the validating stub-resolver library that checks the
636    integrity of the combined DNAME + CNAME reply.  When DNSSEC
637    validation is handled by a local caching resolver, rather than the
638    MTA itself, even that part of the DNAME support logic is outside the
639    MTA.
640
641    When a stub resolver returns a response containing a CNAME alias that
642    does not also contain the corresponding query results for the target
643    of the alias, the SMTP client will need to repeat the query at the
644    target of the alias, and should do so recursively up to some
645    configured or implementation-dependent recursion limit.  If at any
646    stage of CNAME expansion an error is detected, the lookup of the
647    original requested records MUST be considered to have failed.
648
649    Whether a chain of CNAME records was returned in a single stub
650    resolver response or via explicit recursion by the SMTP client, if at
651    any stage of recursive expansion an "insecure" CNAME record is
652    encountered, then it and all subsequent results (in particular, the
653    final result) MUST be considered "insecure" regardless of whether any
654    earlier CNAME records leading to the "insecure" record were "secure".
655
656    Note that a security-aware non-validating stub resolver may return to
657    the SMTP client an "insecure" reply received from a validating
658    recursive resolver that contains a CNAME record along with additional
659    answers recursively obtained starting at the target of the CNAME.  In
660    this case, the only possible conclusion is that some record in the
661    set of records returned is "insecure", and it is in fact possible
662    that the initial CNAME record and a subset of the subsequent records
663    are "secure".
664
665    If the SMTP client needs to determine the security status of the DNS
666    zone containing the initial CNAME record, it may need to issue a
667    separate query of type "CNAME" that returns only the initial CNAME
668    record.  In particular in Section 2.2.2 when insecure A or AAAA
669
670
671
672 Dukhovni & Hardaker     Expires February 18, 2015              [Page 12]
673 \f
674 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
675
676
677    records are found for an SMTP server via a CNAME alias, it may be
678    necessary to perform an additional CNAME query to determine whether
679    the DNS zone in which the alias is published is signed.
680
681 2.2.  TLS discovery
682
683    As noted previously (in Section 1.3.1), opportunistic TLS with SMTP
684    servers that advertise TLS support via STARTTLS is subject to an MITM
685    downgrade attack.  Also some SMTP servers that are not, in fact, TLS
686    capable erroneously advertise STARTTLS by default and clients need to
687    be prepared to retry cleartext delivery after STARTTLS fails.  In
688    contrast, DNSSEC validated TLSA records MUST NOT be published for
689    servers that do not support TLS.  Clients can safely interpret their
690    presence as a commitment by the server operator to implement TLS and
691    STARTTLS.
692
693    This memo defines four actions to be taken after the search for a
694    TLSA record returns secure usable results, secure unusable results,
695    insecure or no results or an error signal.  The term "usable" in this
696    context is in the sense of Section 4.1 of [RFC6698].  Specifically,
697    if the DNS lookup for a TLSA record returns:
698
699    A secure TLSA RRset with at least one usable record:  A connection to
700       the MTA MUST be made using authenticated and encrypted TLS, using
701       the techniques discussed in the rest of this document.  Failure to
702       establish an authenticated TLS connection MUST result in falling
703       back to the next SMTP server or delayed delivery.
704
705    A secure non-empty TLSA RRset where all the records are unusable:  A
706       connection to the MTA MUST be made via TLS, but authentication is
707       not required.  Failure to establish an encrypted TLS connection
708       MUST result in falling back to the next SMTP server or delayed
709       delivery.
710
711    An insecure TLSA RRset or DNSSEC validated proof-of-non-existent TLSA
712     records:
713       A connection to the MTA SHOULD be made using (pre-DANE)
714       opportunistic TLS, this includes using cleartext delivery when the
715       remote SMTP server does not appear to support TLS.  The MTA MAY
716       retry in cleartext when delivery via TLS fails either during the
717       handshake or even during data transfer.
718
719    Any lookup error:  Lookup errors, including "bogus" and
720       "indeterminate", as explained in Section 2.1.1 MUST result in
721       falling back to the next SMTP server or delayed delivery.
722
723    An SMTP client MAY be configured to require DANE verified delivery
724    for some destinations.  We will call such a configuration "mandatory
725
726
727
728 Dukhovni & Hardaker     Expires February 18, 2015              [Page 13]
729 \f
730 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
731
732
733    DANE TLS".  With mandatory DANE TLS, delivery proceeds only when
734    "secure" TLSA records are used to establish an encrypted and
735    authenticated TLS channel with the SMTP server.
736
737    When the original next-hop destination is an address literal, rather
738    than a DNS domain, DANE TLS does not apply.  Delivery proceeds using
739    any relevant security policy configured by the MTA administrator.
740    Similarly, when an MX RRset incorrectly lists a network address in
741    lieu of an MX hostname, if an MTA chooses to connect to the network
742    address in the non-conformant MX record, DANE TLSA does not apply for
743    such a connection.
744
745    In the subsections that follow we explain how to locate the SMTP
746    servers and the associated TLSA records for a given next-hop
747    destination domain.  We also explain which name or names are to be
748    used in identity checks of the SMTP server certificate.
749
750 2.2.1.  MX resolution
751
752    In this section we consider next-hop domains that are subject to MX
753    resolution and have MX records.  The TLSA records and the associated
754    base domain are derived separately for each MX hostname that is used
755    to attempt message delivery.  DANE TLS can authenticate message
756    delivery to the intended next-hop domain only when the MX records are
757    obtained securely via a DNSSEC validated lookup.
758
759    MX records MUST be sorted by preference; an MX hostname with a worse
760    (numerically higher) MX preference that has TLSA records MUST NOT
761    preempt an MX hostname with a better (numerically lower) preference
762    that has no TLSA records.  In other words, prevention of delivery
763    loops by obeying MX preferences MUST take precedence over channel
764    security considerations.  Even with two equal-preference MX records,
765    an MTA is not obligated to choose the MX hostname that offers more
766    security.  Domains that want secure inbound mail delivery need to
767    ensure that all their SMTP servers and MX records are configured
768    accordingly.
769
770    In the language of [RFC5321] Section 5.1, the original next-hop
771    domain is the "initial name".  If the MX lookup of the initial name
772    results in a CNAME alias, the MTA replaces the initial name with the
773    resulting name and performs a new lookup with the new name.  MTAs
774    typically support recursion in CNAME expansion, so this replacement
775    is performed repeatedly (up to the MTA's recursion limit) until the
776    ultimate non-CNAME domain is found.
777
778    If the MX RRset (or any CNAME leading to it) is "insecure" (see
779    Section 2.1.1), DANE TLS need not apply, and delivery MAY proceed via
780    pre-DANE opportunistic TLS.  That said, the protocol in this memo is
781
782
783
784 Dukhovni & Hardaker     Expires February 18, 2015              [Page 14]
785 \f
786 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
787
788
789    an "opportunistic security" protocol, meaning that it strives to
790    communicate with each peer as securely as possible, while maintaining
791    broad interoperability.  Therefore, the SMTP client MAY proceed to
792    use DANE TLS (as described in Section 2.2.2 below) even with MX hosts
793    obtained via an "insecure" MX RRset.  For example, when a hosting
794    provider has a signed DNS zone and publishes TLSA records for its
795    SMTP servers, hosted domains that are not signed may still benefit
796    from the provider's TLSA records.  Deliveries via the provider's SMTP
797    servers will not be subject to active attacks when sending SMTP
798    clients elect to make use of the provider's TLSA records.
799
800    When the MX records are not (DNSSEC) signed, an active attacker can
801    redirect SMTP clients to MX hosts of his choice.  Such redirection is
802    tamper-evident when SMTP servers found via "insecure" MX records are
803    recorded as the next-hop relay in the MTA delivery logs in their
804    original (rather than CNAME expanded) form.  Sending MTAs SHOULD log
805    unexpanded MX hostnames when these result from insecure MX lookups.
806    Any successful authentication via an insecurely determined MX host
807    MUST NOT be misrepresented in the mail logs as secure delivery to the
808    intended next-hop domain.  When DANE TLS is mandatory (Section 6) for
809    a given destination, delivery MUST be delayed when the MX RRset is
810    not "secure".
811
812    Otherwise, assuming no DNS errors (Section 2.1.1), the MX RRset is
813    "secure", and the SMTP client MUST treat each MX hostname as a
814    separate non-MX destination for opportunistic DANE TLS as described
815    in Section 2.2.2.  When, for a given MX hostname, no TLSA records are
816    found, or only "insecure" TLSA records are found, DANE TLSA is not
817    applicable with the SMTP server in question and delivery proceeds to
818    that host as with pre-DANE opportunistic TLS.  To avoid downgrade
819    attacks, any errors during TLSA lookups MUST, as explained in
820    Section 2.1.1, cause the SMTP server in question to be treated as
821    unreachable.
822
823 2.2.2.  Non-MX destinations
824
825    This section describes the algorithm used to locate the TLSA records
826    and associated TLSA base domain for an input domain not subject to MX
827    resolution.  Such domains include:
828
829    o  Each MX hostname used in a message delivery attempt for an
830       original next-hop destination domain subject to MX resolution.
831       Note, MTAs are not obligated to support CNAME expansion of MX
832       hostnames.
833
834    o  Any administrator configured relay hostname, not subject to MX
835       resolution.  This frequently involves configuration set by the MTA
836       administrator to handle some or all mail.
837
838
839
840 Dukhovni & Hardaker     Expires February 18, 2015              [Page 15]
841 \f
842 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
843
844
845    o  A next-hop destination domain subject to MX resolution that has no
846       MX records.  In this case the domain's name is implicitly also its
847       sole SMTP server name.
848
849    Note that DNS queries with type TLSA are mishandled by load balancing
850    nameservers that serve the MX hostnames of some large email
851    providers.  The DNS zones served by these nameservers are not signed
852    and contain no TLSA records, but queries for TLSA records fail,
853    rather than returning the non-existence of the requested TLSA
854    records.
855
856    To avoid problems delivering mail to domains whose SMTP servers are
857    served by the problem nameservers the SMTP client MUST perform any A
858    and/or AAAA queries for the destination before attempting to locate
859    the associated TLSA records.  This lookup is needed in any case to
860    determine whether the destination domain is reachable and the DNSSEC
861    validation status of the chain of CNAME queries required to reach the
862    ultimate address records.
863
864    If no address records are found, the destination is unreachable.  If
865    address records are found, but the DNSSEC validation status of the
866    first query response is "insecure" (see Section 2.1.3), the SMTP
867    client SHOULD NOT proceed to search for any associated TLSA records.
868    With the problem domains, TLSA queries will lead to DNS lookup errors
869    and cause messages to be consistently delayed and ultimately returned
870    to the sender.  We don't expect to find any "secure" TLSA records
871    associated with a TLSA base domain that lies in an unsigned DNS zone.
872    Therefore, skipping TLSA lookups in this case will also reduce
873    latency with no detrimental impact on security.
874
875    If the A and/or AAAA lookup of the "initial name" yields a CNAME, we
876    replace it with the resulting name as if it were the initial name and
877    perform a lookup again using the new name.  This replacement is
878    performed recursively (up to the MTA's recursion limit).
879
880    We consider the following cases for handling a DNS response for an A
881    or AAAA DNS lookup:
882
883    Not found:   When the DNS queries for A and/or AAAA records yield
884       neither a list of addresses nor a CNAME (or CNAME expansion is not
885       supported) the destination is unreachable.
886
887
888
889
890
891
892
893
894
895
896 Dukhovni & Hardaker     Expires February 18, 2015              [Page 16]
897 \f
898 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
899
900
901    Non-CNAME:   The answer is not a CNAME alias.  If the address RRset
902       is "secure", TLSA lookups are performed as described in
903       Section 2.2.3 with the initial name as the candidate TLSA base
904       domain.  If no "secure" TLSA records are found, DANE TLS is not
905       applicable and mail delivery proceeds with pre-DANE opportunistic
906       TLS (which, being best-effort, degrades to cleartext delivery when
907       STARTTLS is not available or the TLS handshake fails).
908
909    Insecure CNAME:   The input domain is a CNAME alias, but the ultimate
910       network address RRset is "insecure" (see Section 2.1.1).  If the
911       initial CNAME response is also "insecure", DANE TLS does not
912       apply.  Otherwise, this case is treated just like the non-CNAME
913       case above, where a search is performed for a TLSA record with the
914       original input domain as the candidate TLSA base domain.
915
916    Secure CNAME:   The input domain is a CNAME alias, and the ultimate
917       network address RRset is "secure" (see Section 2.1.1).  Two
918       candidate TLSA base domains are tried: the fully CNAME-expanded
919       initial name and, failing that, then the initial name itself.
920
921    In summary, if it is possible to securely obtain the full, CNAME-
922    expanded, DNSSEC-validated address records for the input domain, then
923    that name is the preferred TLSA base domain.  Otherwise, the
924    unexpanded input-MX domain is the candidate TLSA base domain.  When
925    no "secure" TLSA records are found at either the CNAME-expanded or
926    unexpanded domain, then DANE TLS does not apply for mail delivery via
927    the input domain in question.  And, as always, errors, bogus or
928    indeterminate results for any query in the process MUST result in
929    delaying or abandoning delivery.
930
931 2.2.3.  TLSA record lookup
932
933    Each candidate TLSA base domain (the original or fully CNAME-expanded
934    name of a non-MX destination or a particular MX hostname of an MX
935    destination) is in turn prefixed with service labels of the form
936    "_<port>._tcp".  The resulting domain name is used to issue a DNSSEC
937    query with the query type set to TLSA ([RFC6698] Section 7.1).
938
939    For SMTP, the destination TCP port is typically 25, but this may be
940    different with custom routes specified by the MTA administrator in
941    which case the SMTP client MUST use the appropriate number in the
942    "_<port>" prefix in place of "_25".  If, for example, the candidate
943    base domain is "mx.example.com", and the SMTP connection is to port
944    25, the TLSA RRset is obtained via a DNSSEC query of the form:
945
946    _25._tcp.mx.example.com. IN TLSA ?
947
948
949
950
951
952 Dukhovni & Hardaker     Expires February 18, 2015              [Page 17]
953 \f
954 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
955
956
957    The query response may be a CNAME, or the actual TLSA RRset.  If the
958    response is a CNAME, the SMTP client (through the use of its
959    security-aware stub resolver) restarts the TLSA query at the target
960    domain, following CNAMEs as appropriate and keeping track of whether
961    the entire chain is "secure".  If any "insecure" records are
962    encountered, or the TLSA records don't exist, the next candidate TLSA
963    base domain is tried instead.
964
965    If the ultimate response is a "secure" TLSA RRset, then the candidate
966    TLSA base domain will be the actual TLSA base domain and the TLSA
967    RRset will constitute the TLSA records for the destination.  If none
968    of the candidate TLSA base domains yield "secure" TLSA records then
969    delivery MAY proceed via pre-DANE opportunistic TLS.  SMTP clients
970    MAY elect to use "insecure" TLSA records to avoid STARTTLS downgrades
971    or even to skip SMTP servers that fail authentication, but MUST NOT
972    misrepresent authentication success as either a secure connection to
973    the SMTP server or as a secure delivery to the intended next-hop
974    domain.
975
976    TLSA record publishers may leverage CNAMEs to reference a single
977    authoritative TLSA RRset specifying a common Certification Authority
978    or a common end entity certificate to be used with multiple TLS
979    services.  Such CNAME expansion does not change the SMTP client's
980    notion of the TLSA base domain; thus, when _25._tcp.mx.example.com is
981    a CNAME, the base domain remains mx.example.com and this is still the
982    reference identifier used together with the next-hop domain in peer
983    certificate name checks.
984
985    Note that shared end entity certificate associations expose the
986    publishing domain to substitution attacks, where an MITM attacker can
987    reroute traffic to a different server that shares the same end entity
988    certificate.  Such shared end entity TLSA records SHOULD be avoided
989    unless the servers in question are functionally equivalent or employ
990    mutually incompatible protocols (an active attacker gains nothing by
991    diverting client traffic from one such server to another).
992
993    A better example, employing a shared trust anchor rather than shared
994    end-entity certificates, is illustrated by the DNSSEC validated
995    records below:
996
997      example.com.                IN MX 0 mx1.example.com.
998      example.com.                IN MX 0 mx2.example.com.
999      _25._tcp.mx1.example.com.   IN CNAME tlsa201._dane.example.com.
1000      _25._tcp.mx2.example.com.   IN CNAME tlsa201._dane.example.com.
1001      tlsa201._dane.example.com.  IN TLSA 2 0 1 e3b0c44298fc1c149a...
1002
1003    The SMTP servers mx1.example.com and mx2.example.com will be expected
1004    to have certificates issued under a common trust anchor, but each MX
1005
1006
1007
1008 Dukhovni & Hardaker     Expires February 18, 2015              [Page 18]
1009 \f
1010 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
1011
1012
1013    hostname's TLSA base domain remains unchanged despite the above CNAME
1014    records.  Correspondingly, each SMTP server will be associated with a
1015    pair of reference identifiers consisting of its hostname plus the
1016    next-hop domain "example.com".
1017
1018    If, during TLSA resolution (including possible CNAME indirection), at
1019    least one "secure" TLSA record is found (even if not usable because
1020    it is unsupported by the implementation or support is
1021    administratively disabled), then the corresponding host has signaled
1022    its commitment to implement TLS.  The SMTP client MUST NOT deliver
1023    mail via the corresponding host unless a TLS session is negotiated
1024    via STARTTLS.  This is required to avoid MITM STARTTLS downgrade
1025    attacks.
1026
1027    As noted previously (in Section Section 2.2.2), when no "secure" TLSA
1028    records are found at the fully CNAME-expanded name, the original
1029    unexpanded name MUST be tried instead.  This supports customers of
1030    hosting providers where the provider's zone cannot be validated with
1031    DNSSEC, but the customer has shared appropriate key material with the
1032    hosting provider to enable TLS via SNI.  Intermediate names that
1033    arise during CNAME expansion that are neither the original, nor the
1034    final name, are never candidate TLSA base domains, even if "secure".
1035
1036 3.  DANE authentication
1037
1038    This section describes which TLSA records are applicable to SMTP
1039    opportunistic DANE TLS and how to apply such records to authenticate
1040    the SMTP server.  With opportunistic DANE TLS, both the TLS support
1041    implied by the presence of DANE TLSA records and the verification
1042    parameters necessary to authenticate the TLS peer are obtained
1043    together.  In contrast to protocols where channel security policy is
1044    set exclusively by the client, authentication via this protocol is
1045    expected to be less prone to connection failure caused by
1046    incompatible configuration of the client and server.
1047
1048 3.1.  TLSA certificate usages
1049
1050    The DANE TLSA specification [RFC6698] defines multiple TLSA RR types
1051    via combinations of 3 numeric parameters.  The numeric values of
1052    these parameters were later given symbolic names in [RFC7218].  The
1053    rest of the TLSA record is the "certificate association data field",
1054    which specifies the full or digest value of a certificate or public
1055    key.  The parameters are:
1056
1057
1058
1059
1060
1061
1062
1063
1064 Dukhovni & Hardaker     Expires February 18, 2015              [Page 19]
1065 \f
1066 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
1067
1068
1069    The TLSA Certificate Usage field:  Section 2.1.1 of [RFC6698]
1070       specifies four values: PKIX-TA(0), PKIX-EE(1), DANE-TA(2), and
1071       DANE-EE(3).  There is an additional private-use value:
1072       PrivCert(255).  All other values are reserved for use by future
1073       specifications.
1074
1075    The selector field:  Section 2.1.2 of [RFC6698] specifies two values:
1076       Cert(0) and SPKI(1).  There is an additional private-use value:
1077       PrivSel(255).  All other values are reserved for use by future
1078       specifications.
1079
1080    The matching type field:  Section 2.1.3 of [RFC6698] specifies three
1081       values: Full(0), SHA2-256(1) and SHA2-512(2).  There is an
1082       additional private-use value: PrivMatch(255).  All other values
1083       are reserved for use by future specifications.
1084
1085    We may think of TLSA Certificate Usage values 0 through 3 as a
1086    combination of two one-bit flags.  The low bit chooses between trust
1087    anchor (TA) and end entity (EE) certificates.  The high bit chooses
1088    between public PKI issued and domain-issued certificates.
1089
1090    The selector field specifies whether the TLSA RR matches the whole
1091    certificate: Cert(0), or just its subjectPublicKeyInfo: SPKI(1).  The
1092    subjectPublicKeyInfo is an ASN.1 DER ([X.690]) encoding of the
1093    certificate's algorithm id, any parameters and the public key data.
1094
1095    The matching type field specifies how the TLSA RR Certificate
1096    Association Data field is to be compared with the certificate or
1097    public key.  A value of Full(0) means an exact match: the full DER
1098    encoding of the certificate or public key is given in the TLSA RR.  A
1099    value of SHA2-256(1) means that the association data matches the
1100    SHA2-256 digest of the certificate or public key, and likewise
1101    SHA2-512(2) means a SHA2-512 digest is used.
1102
1103    Since opportunistic DANE TLS will be used by non-interactive MTAs,
1104    with no user to "press OK" when authentication fails, reliability of
1105    peer authentication is paramount.  Server operators are advised to
1106    publish TLSA records that are least likely to fail authentication due
1107    to interoperability or operational problems.  Because DANE TLS relies
1108    on coordinated changes to DNS and SMTP server settings, the best
1109    choice of records to publish will depend on site-specific practices.
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120 Dukhovni & Hardaker     Expires February 18, 2015              [Page 20]
1121 \f
1122 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
1123
1124
1125    The certificate usage element of a TLSA record plays a critical role
1126    in determining how the corresponding certificate association data
1127    field is used to authenticate server's certificate chain.  The next
1128    two subsections explain the process for certificate usages DANE-EE(3)
1129    and DANE-TA(2).  The third subsection briefly explains why
1130    certificate usages PKIX-TA(0) and PKIX-EE(1) are not applicable with
1131    opportunistic DANE TLS.
1132
1133    In summary, we recommend the use of either "DANE-EE(3) SPKI(1)
1134    SHA2-256(1)" or "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA records
1135    depending on site needs.  Other combinations of TLSA parameters are
1136    either explicitly unsupported, or offer little to recommend them over
1137    these two.
1138
1139    The mandatory to support digest algorithm in [RFC6698] is
1140    SHA2-256(1).  When the server's TLSA RRset includes records with a
1141    matching type indicating a digest record (i.e., a value other than
1142    Full(0)), a TLSA record with a SHA2-256(1) matching type SHOULD be
1143    provided along with any other digest published, since some SMTP
1144    clients may support only SHA2-256(1).  If at some point the SHA2-256
1145    digest algorithm is tarnished by new cryptanalytic attacks,
1146    publishers will need to include an appropriate stronger digest in
1147    their TLSA records, initially along with, and ultimately in place of,
1148    SHA2-256.
1149
1150 3.1.1.  Certificate usage DANE-EE(3)
1151
1152    Authentication via certificate usage DANE-EE(3) TLSA records involves
1153    simply checking that the server's leaf certificate matches the TLSA
1154    record.  In particular the binding of the server public key to its
1155    name is based entirely on the TLSA record association.  The server
1156    MUST be considered authenticated even if none of the names in the
1157    certificate match the client's reference identity for the server.
1158
1159    Similarly, the expiration date of the server certificate MUST be
1160    ignored, the validity period of the TLSA record key binding is
1161    determined by the validity interval of the TLSA record DNSSEC
1162    signature.
1163
1164    With DANE-EE(3) servers need not employ SNI (may ignore the client's
1165    SNI message) even when the server is known under independent names
1166    that would otherwise require separate certificates.  It is instead
1167    sufficient for the TLSA RRsets for all the domains in question to
1168    match the server's default certificate.  Of course with SMTP servers
1169    it is simpler still to publish the same MX hostname for all the
1170    hosted domains.
1171
1172
1173
1174
1175
1176 Dukhovni & Hardaker     Expires February 18, 2015              [Page 21]
1177 \f
1178 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
1179
1180
1181    For domains where it is practical to make coordinated changes in DNS
1182    TLSA records during SMTP server key rotation, it is often best to
1183    publish end-entity DANE-EE(3) certificate associations.  DANE-EE(3)
1184    certificates don't suddenly stop working when leaf or intermediate
1185    certificates expire, and don't fail when the server operator neglects
1186    to configure all the required issuer certificates in the server
1187    certificate chain.
1188
1189    TLSA records published for SMTP servers SHOULD, in most cases, be
1190    "DANE-EE(3) SPKI(1) SHA2-256(1)" records.  Since all DANE
1191    implementations are required to support SHA2-256, this record type
1192    works for all clients and need not change across certificate renewals
1193    with the same key.
1194
1195 3.1.2.  Certificate usage DANE-TA(2)
1196
1197    Some domains may prefer to avoid the operational complexity of
1198    publishing unique TLSA RRs for each TLS service.  If the domain
1199    employs a common issuing Certification Authority to create
1200    certificates for multiple TLS services, it may be simpler to publish
1201    the issuing authority as a trust anchor (TA) for the certificate
1202    chains of all relevant services.  The TLSA query domain (TLSA base
1203    domain with port and protocol prefix labels) for each service issued
1204    by the same TA may then be set to a CNAME alias that points to a
1205    common TLSA RRset that matches the TA.  For example:
1206
1207      example.com.                IN MX 0 mx1.example.com.
1208      example.com.                IN MX 0 mx2.example.com.
1209      _25._tcp.mx1.example.com.   IN CNAME tlsa201._dane.example.com.
1210      _25._tcp.mx2.example.com.   IN CNAME tlsa201._dane.example.com.
1211      tlsa201._dane.example.com.  IN TLSA 2 0 1 e3b0c44298fc1c14....
1212
1213    With usage DANE-TA(2) the server certificates will need to have names
1214    that match one of the client's reference identifiers (see [RFC6125]).
1215    The server MAY employ SNI to select the appropriate certificate to
1216    present to the client.
1217
1218    SMTP servers that rely on certificate usage DANE-TA(2) TLSA records
1219    for TLS authentication MUST include the TA certificate as part of the
1220    certificate chain presented in the TLS handshake server certificate
1221    message even when it is a self-signed root certificate.  At this
1222    time, many SMTP servers are not configured with a comprehensive list
1223    of trust anchors, nor are they expected to at any point in the
1224    future.  Some MTAs will ignore all locally trusted certificates when
1225    processing usage DANE-TA(2) TLSA records.  Thus even when the TA
1226    happens to be a public Certification Authority known to the SMTP
1227    client, authentication is likely to fail unless the TA certificate is
1228    included in the TLS server certificate message.
1229
1230
1231
1232 Dukhovni & Hardaker     Expires February 18, 2015              [Page 22]
1233 \f
1234 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
1235
1236
1237    TLSA records with selector Full(0) are discouraged.  While these
1238    potentially obviate the need to transmit the TA certificate in the
1239    TLS server certificate message, client implementations may not be
1240    able to augment the server certificate chain with the data obtained
1241    from DNS, especially when the TLSA record supplies a bare key
1242    (selector SPKI(1)).  Since the server will need to transmit the TA
1243    certificate in any case, server operators SHOULD publish TLSA records
1244    with a selector other than Full(0) and avoid potential
1245    interoperability issues with large TLSA records containing full
1246    certificates or keys.
1247
1248    TLSA Publishers employing DANE-TA(2) records SHOULD publish records
1249    with a selector of Cert(0).  Such TLSA records are associated with
1250    the whole trust anchor certificate, not just with the trust anchor
1251    public key.  In particular, the SMTP client SHOULD then apply any
1252    relevant constraints from the trust anchor certificate, such as, for
1253    example, path length constraints.
1254
1255    While a selector of SPKI(1) may also be employed, the resulting TLSA
1256    record will not specify the full trust anchor certificate content,
1257    and elements of the trust anchor certificate other than the public
1258    key become mutable.  This may, for example, allow a subsidiary CA to
1259    issue a chain that violates the trust anchor's path length or name
1260    constraints.
1261
1262 3.1.3.  Certificate usages PKIX-TA(0) and PKIX-EE(1)
1263
1264    As noted in the introduction, SMTP clients cannot, without relying on
1265    DNSSEC for secure MX records and DANE for STARTTLS support signaling,
1266    perform server identity verification or prevent STARTTLS downgrade
1267    attacks.  The use of PKIX CAs offers no added security since an
1268    attacker capable of compromising DNSSEC is free to replace any PKIX-
1269    TA(0) or PKIX-EE(1) TLSA records with records bearing any convenient
1270    non-PKIX certificate usage.
1271
1272    SMTP servers SHOULD NOT publish TLSA RRs with certificate usage PKIX-
1273    TA(0) or PKIX-EE(1).  SMTP clients cannot be expected to be
1274    configured with a suitably complete set of trusted public CAs.
1275    Lacking a complete set of public CAs, clients would not be able to
1276    verify the certificates of SMTP servers whose issuing root CAs are
1277    not trusted by the client.
1278
1279    Opportunistic DANE TLS needs to interoperate without bilateral
1280    coordination of security settings between client and server systems.
1281    Therefore, parameter choices that are fragile in the absence of
1282    bilateral coordination are unsupported.  Nothing is lost since the
1283    PKIX certificate usages cannot aid SMTP TLS security, they can only
1284    impede SMTP TLS interoperability.
1285
1286
1287
1288 Dukhovni & Hardaker     Expires February 18, 2015              [Page 23]
1289 \f
1290 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
1291
1292
1293    SMTP client treatment of TLSA RRs with certificate usages PKIX-TA(0)
1294    or PKIX-EE(1) is undefined.  SMTP clients should generally treat such
1295    TLSA records as unusable.
1296
1297 3.2.  Certificate matching
1298
1299    When at least one usable "secure" TLSA record is found, the SMTP
1300    client MUST use TLSA records to authenticate the SMTP server.
1301    Messages MUST NOT be delivered via the SMTP server if authentication
1302    fails, otherwise the SMTP client is vulnerable to MITM attacks.
1303
1304 3.2.1.  DANE-EE(3) name checks
1305
1306    The SMTP client MUST NOT perform certificate name checks with
1307    certificate usage DANE-EE(3); see Section 3.1.1 above.
1308
1309 3.2.2.  DANE-TA(2) name checks
1310
1311    To match a server via a TLSA record with certificate usage DANE-
1312    TA(2), the client MUST perform name checks to ensure that it has
1313    reached the correct server.  In all DANE-TA(2) cases the SMTP client
1314    MUST include the TLSA base domain as one of the valid reference
1315    identifiers for matching the server certificate.
1316
1317    TLSA records for MX hostnames:  If the TLSA base domain was obtained
1318       indirectly via a "secure" MX lookup (including any CNAME-expanded
1319       name of an MX hostname), then the original next-hop domain used in
1320       the MX lookup MUST be included as as a second reference
1321       identifier.  The CNAME-expanded original next-hop domain MUST be
1322       included as a third reference identifier if different from the
1323       original next-hop domain.  When the client MTA is employing DANE
1324       TLS security despite "insecure" MX redirection the MX hostname is
1325       the only reference identifier.
1326
1327    TLSA records for Non-MX hostnames:  If MX records were not used
1328       (e.g., if none exist) and the TLSA base domain is the CNAME-
1329       expanded original next-hop domain, then the original next-hop
1330       domain MUST be included as a second reference identifier.
1331
1332    Accepting certificates with the original next-hop domain in addition
1333    to the MX hostname allows a domain with multiple MX hostnames to
1334    field a single certificate bearing a single domain name (i.e., the
1335    email domain) across all the SMTP servers.  This also aids
1336    interoperability with pre-DANE SMTP clients that are configured to
1337    look for the email domain name in server certificates.  For example,
1338    with "secure" DNS records as below:
1339
1340
1341
1342
1343
1344 Dukhovni & Hardaker     Expires February 18, 2015              [Page 24]
1345 \f
1346 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
1347
1348
1349      exchange.example.org.            IN CNAME mail.example.org.
1350      mail.example.org.                IN CNAME example.com.
1351      example.com.                     IN MX    10 mx10.example.com.
1352      example.com.                     IN MX    15 mx15.example.com.
1353      example.com.                     IN MX    20 mx20.example.com.
1354      ;
1355      mx10.example.com.                IN A     192.0.2.10
1356      _25._tcp.mx10.example.com.       IN TLSA  2 0 1 ...
1357      ;
1358      mx15.example.com.                IN CNAME mxbackup.example.com.
1359      mxbackup.example.com.            IN A     192.0.2.15
1360      ; _25._tcp.mxbackup.example.com. IN TLSA ? (NXDOMAIN)
1361      _25._tcp.mx15.example.com.       IN TLSA  2 0 1 ...
1362      ;
1363      mx20.example.com.                IN CNAME mxbackup.example.net.
1364      mxbackup.example.net.            IN A     198.51.100.20
1365      _25._tcp.mxbackup.example.net.   IN TLSA  2 0 1 ...
1366
1367    Certificate name checks for delivery of mail to exchange.example.org
1368    via any of the associated SMTP servers MUST accept at least the names
1369    "exchange.example.org" and "example.com", which are respectively the
1370    original and fully expanded next-hop domain.  When the SMTP server is
1371    mx10.example.com, name checks MUST accept the TLSA base domain
1372    "mx10.example.com".  If, despite the fact that MX hostnames are
1373    required to not be aliases, the MTA supports delivery via
1374    "mx15.example.com" or "mx20.example.com" then name checks MUST accept
1375    the respective TLSA base domains "mx15.example.com" and
1376    "mxbackup.example.net".
1377
1378 3.2.3.  Reference identifier matching
1379
1380    When name checks are applicable (certificate usage DANE-TA(2)), if
1381    the server certificate contains a Subject Alternative Name extension
1382    ([RFC5280]), with at least one DNS-ID ([RFC6125]) then only the DNS-
1383    IDs are matched against the client's reference identifiers.  The CN-
1384    ID ([RFC6125]) is only considered when no DNS-IDs are present.  The
1385    server certificate is considered matched when one of its presented
1386    identifiers ([RFC5280]) matches any of the client's reference
1387    identifiers.
1388
1389    Wildcards are valid in either DNS-IDs or the CN-ID when applicable.
1390    The wildcard character must be entire first label of the DNS-ID or
1391    CN-ID.  Thus, "*.example.com" is valid, while "smtp*.example.com" and
1392    "*smtp.example.com" are not.  SMTP clients MUST support wildcards
1393    that match the first label of the reference identifier, with the
1394    remaining labels matching verbatim.  For example, the DNS-ID
1395    "*.example.com" matches the reference identifier "mx1.example.com".
1396    SMTP clients MAY, subject to local policy allow wildcards to match
1397
1398
1399
1400 Dukhovni & Hardaker     Expires February 18, 2015              [Page 25]
1401 \f
1402 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
1403
1404
1405    multiple reference identifier labels, but servers cannot expect broad
1406    support for such a policy.  Therefore any wildcards in server
1407    certificates SHOULD match exactly one label in either the TLSA base
1408    domain or the next-hop domain.
1409
1410 4.  Server key management
1411
1412    Two TLSA records MUST be published before employing a new EE or TA
1413    public key or certificate, one matching the currently deployed key
1414    and the other matching the new key scheduled to replace it.  Once
1415    sufficient time has elapsed for all DNS caches to expire the previous
1416    TLSA RRset and related signature RRsets, servers may be configured to
1417    use the new EE private key and associated public key certificate or
1418    may employ certificates signed by the new trust anchor.
1419
1420    Once the new public key or certificate is in use, the TLSA RR that
1421    matches the retired key can be removed from DNS, leaving only RRs
1422    that match keys or certificates in active use.
1423
1424    As described in Section 3.1.2, when server certificates are validated
1425    via a DANE-TA(2) trust anchor, and CNAME records are employed to
1426    store the TA association data at a single location, the
1427    responsibility of updating the TLSA RRset shifts to the operator of
1428    the trust anchor.  Before a new trust anchor is used to sign any new
1429    server certificates, its certificate (digest) is added to the
1430    relevant TLSA RRset.  After enough time elapses for the original TLSA
1431    RRset to age out of DNS caches, the new trust anchor can start
1432    issuing new server certificates.  Once all certificates issued under
1433    the previous trust anchor have expired, its associated RRs can be
1434    removed from the TLSA RRset.
1435
1436    In the DANE-TA(2) key management model server operators do not
1437    generally need to update DNS TLSA records after initially creating a
1438    CNAME record that references the centrally operated DANE-TA(2) RRset.
1439    If a particular server's key is compromised, its TLSA CNAME SHOULD be
1440    replaced with a DANE-EE(3) association until the certificate for the
1441    compromised key expires, at which point it can return to using a
1442    CNAME record.  If the central trust anchor is compromised, all
1443    servers need to be issued new keys by a new TA, and an updated DANE-
1444    TA(2) TLSA RRset needs to be published containing just the new TA.
1445
1446    SMTP servers cannot expect broad CRL or OCSP support from SMTP
1447    clients.  As outlined above, with DANE, compromised server or trust
1448    anchor keys can be "revoked" by removing them from the DNS without
1449    the need for client-side support for OCSP or CRLs.
1450
1451 5.  Digest algorithm agility
1452
1453
1454
1455
1456 Dukhovni & Hardaker     Expires February 18, 2015              [Page 26]
1457 \f
1458 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
1459
1460
1461    While [RFC6698] specifies multiple digest algorithms, it does not
1462    specify a protocol by which the SMTP client and TLSA record publisher
1463    can agree on the strongest shared algorithm.  Such a protocol would
1464    allow the client and server to avoid exposure to any deprecated
1465    weaker algorithms that are published for compatibility with less
1466    capable clients, but should be ignored when possible.  Such a
1467    protocol is specified in [I-D.ietf-dane-ops].  SMTP clients and
1468    servers that implement this specification MUST comply with the
1469    requirements outlined under "Digest Algorithm Agility" in
1470    [I-D.ietf-dane-ops].
1471
1472 6.  Mandatory TLS Security
1473
1474    An MTA implementing this protocol may require a stronger security
1475    assurance when sending email to selected destinations.  The sending
1476    organization may need to send sensitive email and/or may have
1477    regulatory obligations to protect its content.  This protocol is not
1478    in conflict with such a requirement, and in fact can often simplify
1479    authenticated delivery to such destinations.
1480
1481    Specifically, with domains that publish DANE TLSA records for their
1482    MX hostnames, a sending MTA can be configured to use the receiving
1483    domains's DANE TLSA records to authenticate the corresponding SMTP
1484    server.  Authentication via DANE TLSA records is easier to manage, as
1485    changes in the receiver's expected certificate properties are made on
1486    the receiver end and don't require manually communicated
1487    configuration changes.  With mandatory DANE TLS, when no usable TLSA
1488    records are found, message delivery is delayed.  Thus, mail is only
1489    sent when an authenticated TLS channel is established to the remote
1490    SMTP server.
1491
1492    Administrators of mail servers that employ mandatory DANE TLS, need
1493    to carefully monitor their mail logs and queues.  If a partner domain
1494    unwittingly misconfigures their TLSA records, disables DNSSEC, or
1495    misconfigures SMTP server certificate chains, mail will be delayed
1496    and may bounce if the issue is not resolved in a timely manner.
1497
1498 7.  Note on DANE for Message User Agents
1499
1500    We note that the SMTP protocol is also used between Message User
1501    Agents (MUAs) and Message Submission Agents (MSAs) [RFC6409].  In
1502    [RFC6186] a protocol is specified that enables an MUA to dynamically
1503    locate the MSA based on the user's email address.  SMTP connection
1504    security considerations for MUAs implementing [RFC6186] are largely
1505    analogous to connection security requirements for MTAs, and this
1506    specification could be applied largely verbatim with DNS MX records
1507    replaced by corresponding DNS Service (SRV) records
1508    [I-D.ietf-dane-srv].
1509
1510
1511
1512 Dukhovni & Hardaker     Expires February 18, 2015              [Page 27]
1513 \f
1514 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
1515
1516
1517    However, until MUAs begin to adopt the dynamic configuration
1518    mechanisms of [RFC6186] they are adequately served by more
1519    traditional static TLS security policies.  Specification of DANE TLS
1520    for Message User Agent (MUA) to Message Submission Agent (MSA) SMTP
1521    is left to future documents that focus specifically on SMTP security
1522    between MUAs and MSAs.
1523
1524 8.  Interoperability considerations
1525
1526 8.1.  SNI support
1527
1528    To ensure that the server sends the right certificate chain, the SMTP
1529    client MUST send the TLS SNI extension containing the TLSA base
1530    domain.  This precludes the use of the backward compatible SSL 2.0
1531    compatible SSL HELLO by the SMTP client.  The minimum SSL/TLS client
1532    HELLO version for SMTP clients performing DANE authentication is SSL
1533    3.0, but a client that offers SSL 3.0 MUST also offer at least TLS
1534    1.0 and MUST include the SNI extension.  Servers that don't make use
1535    of SNI MAY negotiate SSL 3.0 if offered by the client.
1536
1537    Each SMTP server MUST present a certificate chain (see [RFC5246]
1538    Section 7.4.2) that matches at least one of the TLSA records.  The
1539    server MAY rely on SNI to determine which certificate chain to
1540    present to the client.  Clients that don't send SNI information may
1541    not see the expected certificate chain.
1542
1543    If the server's TLSA records match the server's default certificate
1544    chain, the server need not support SNI.  In either case, the server
1545    need not include the SNI extension in its TLS HELLO as simply
1546    returning a matching certificate chain is sufficient.  Servers MUST
1547    NOT enforce the use of SNI by clients, as the client may be using
1548    unauthenticated opportunistic TLS and may not expect any particular
1549    certificate from the server.  If the client sends no SNI extension,
1550    or sends an SNI extension for an unsupported domain, the server MUST
1551    simply send some fallback certificate chain of its choice.  The
1552    reason for not enforcing strict matching of the requested SNI
1553    hostname is that DANE TLS clients are typically willing to accept
1554    multiple server names, but can only send one name in the SNI
1555    extension.  The server's fallback certificate may match a different
1556    name acceptable to the client, e.g., the original next-hop domain.
1557
1558 8.2.  Anonymous TLS cipher suites
1559
1560    Since many SMTP servers either do not support or do not enable any
1561    anonymous TLS cipher suites, SMTP client TLS HELLO messages SHOULD
1562    offer to negotiate a typical set of non-anonymous cipher suites
1563    required for interoperability with such servers.  An SMTP client
1564    employing pre-DANE opportunistic TLS MAY in addition include one or
1565
1566
1567
1568 Dukhovni & Hardaker     Expires February 18, 2015              [Page 28]
1569 \f
1570 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
1571
1572
1573    more anonymous TLS cipher suites in its TLS HELLO.  SMTP servers,
1574    that need to interoperate with opportunistic TLS clients SHOULD be
1575    prepared to interoperate with such clients by either always selecting
1576    a mutually supported non-anonymous cipher suite or by correctly
1577    handling client connections that negotiate anonymous cipher suites.
1578
1579    Note that while SMTP server operators are under no obligation to
1580    enable anonymous cipher suites, no security is gained by sending
1581    certificates to clients that will ignore them.  Indeed support for
1582    anonymous cipher suites in the server makes audit trails more
1583    informative.  Log entries that record connections that employed an
1584    anonymous cipher suite record the fact that the clients did not care
1585    to authenticate the server.
1586
1587 9.  Operational Considerations
1588
1589 9.1.  Client Operational Considerations
1590
1591    An operational error on the sending or receiving side that cannot be
1592    corrected in a timely manner may, at times, lead to consistent
1593    failure to deliver time-sensitive email.  The sending MTA
1594    administrator may have to choose between letting email queue until
1595    the error is resolved and disabling opportunistic or mandatory DANE
1596    TLS for one or more destinations.  The choice to disable DANE TLS
1597    security should not be made lightly.  Every reasonable effort should
1598    be made to determine that problems with mail delivery are the result
1599    of an operational error, and not an attack.  A fallback strategy may
1600    be to configure explicit out-of-band TLS security settings if
1601    supported by the sending MTA.
1602
1603    SMTP clients may deploy opportunistic DANE TLS incrementally by
1604    enabling it only for selected sites, or may occasionally need to
1605    disable opportunistic DANE TLS for peers that fail to interoperate
1606    due to misconfiguration or software defects on either end.  Some
1607    implementations MAY support DANE TLS in an "audit only" mode in which
1608    failure to achieve the requisite security level is logged as a
1609    warning and delivery proceeds at a reduced security level.  Unless
1610    local policy specifies "audit only" or that opportunistic DANE TLS is
1611    not to be used for a particular destination, an SMTP client MUST NOT
1612    deliver mail via a server whose certificate chain fails to match at
1613    least one TLSA record when usable TLSA records are found for that
1614    server.
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624 Dukhovni & Hardaker     Expires February 18, 2015              [Page 29]
1625 \f
1626 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
1627
1628
1629 9.2.  Publisher Operational Considerations
1630
1631    SMTP servers that publish certificate usage DANE-TA(2) associations
1632    MUST include the TA certificate in their TLS server certificate
1633    chain, even when that TA certificate is a self-signed root
1634    certificate.
1635
1636    TLSA Publishers MUST follow the guidelines in the "TLSA Publisher
1637    Requirements" section of [I-D.ietf-dane-ops].
1638
1639    TLSA Publishers SHOULD follow the TLSA publication size guidance
1640    found in [I-D.ietf-dane-ops] under "DANE DNS Record Size Guidelines".
1641
1642 10.  Security Considerations
1643
1644    This protocol leverages DANE TLSA records to implement MITM resistant
1645    opportunistic security ([I-D.dukhovni-opportunistic-security]) for
1646    SMTP.  For destination domains that sign their MX records and publish
1647    signed TLSA records for their MX hostnames, this protocol allows
1648    sending MTAs to securely discover both the availability of TLS and
1649    how to authenticate the destination.
1650
1651    This protocol does not aim to secure all SMTP traffic, as that is not
1652    practical until DNSSEC and DANE adoption are universal.  The
1653    incremental deployment provided by following this specification is a
1654    best possible path for securing SMTP.  This protocol coexists and
1655    interoperates with the existing insecure Internet email backbone.
1656
1657    The protocol does not preclude existing non-opportunistic SMTP TLS
1658    security arrangements, which can continue to be used as before via
1659    manual configuration with negotiated out-of-band key and TLS
1660    configuration exchanges.
1661
1662    Opportunistic SMTP TLS depends critically on DNSSEC for downgrade
1663    resistance and secure resolution of the destination name.  If DNSSEC
1664    is compromised, it is not possible to fall back on the public CA PKI
1665    to prevent MITM attacks.  A successful breach of DNSSEC enables the
1666    attacker to publish TLSA usage 3 certificate associations, and
1667    thereby bypass any security benefit the legitimate domain owner might
1668    hope to gain by publishing usage 0 or 1 TLSA RRs.  Given the lack of
1669    public CA PKI support in existing MTA deployments, avoiding
1670    certificate usages 0 and 1 simplifies implementation and deployment
1671    with no adverse security consequences.
1672
1673    Implementations must strictly follow the portions of this
1674    specification that indicate when it is appropriate to initiate a non-
1675    authenticated connection or cleartext connection to a SMTP server.
1676    Specifically, in order to prevent downgrade attacks on this protocol,
1677
1678
1679
1680 Dukhovni & Hardaker     Expires February 18, 2015              [Page 30]
1681 \f
1682 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
1683
1684
1685    implementation must not initiate a connection when this specification
1686    indicates a particular SMTP server must be considered unreachable.
1687
1688 11.  IANA considerations
1689
1690    This specification requires no support from IANA.
1691
1692 12.  Acknowledgements
1693
1694    The authors would like to extend great thanks to Tony Finch, who
1695    started the original version of a DANE SMTP document.  His work is
1696    greatly appreciated and has been incorporated into this document.
1697    The authors would like to additionally thank Phil Pennock for his
1698    comments and advice on this document.
1699
1700    Acknowledgments from Viktor: Thanks to Paul Hoffman who motivated me
1701    to begin work on this memo and provided feedback on early drafts.
1702    Thanks to Patrick Koetter, Perry Metzger and Nico Williams for
1703    valuable review comments.  Thanks also to Wietse Venema who created
1704    Postfix, and whose advice and feedback were essential to the
1705    development of the Postfix DANE implementation.
1706
1707 13.  References
1708
1709 13.1.  Normative References
1710
1711    [I-D.ietf-dane-ops]
1712               Dukhovni, V. and W. Hardaker, "Updates to and Operational
1713               Guidance for the DANE Protocol", draft-ietf-dane-ops-06
1714               (work in progress), August 2014.
1715
1716    [RFC1035]  Mockapetris, P., "Domain names - implementation and
1717               specification", STD 13, RFC 1035, November 1987.
1718
1719    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
1720               Requirement Levels", BCP 14, RFC 2119, March 1997.
1721
1722    [RFC3207]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
1723               Transport Layer Security", RFC 3207, February 2002.
1724
1725    [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
1726               Rose, "DNS Security Introduction and Requirements", RFC
1727               4033, March 2005.
1728
1729    [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
1730               Rose, "Resource Records for the DNS Security Extensions",
1731               RFC 4034, March 2005.
1732
1733
1734
1735
1736 Dukhovni & Hardaker     Expires February 18, 2015              [Page 31]
1737 \f
1738 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
1739
1740
1741    [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
1742               Rose, "Protocol Modifications for the DNS Security
1743               Extensions", RFC 4035, March 2005.
1744
1745    [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
1746               (TLS) Protocol Version 1.2", RFC 5246, August 2008.
1747
1748    [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
1749               Housley, R., and W. Polk, "Internet X.509 Public Key
1750               Infrastructure Certificate and Certificate Revocation List
1751               (CRL) Profile", RFC 5280, May 2008.
1752
1753    [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
1754               October 2008.
1755
1756    [RFC6066]  Eastlake, D., "Transport Layer Security (TLS) Extensions:
1757               Extension Definitions", RFC 6066, January 2011.
1758
1759    [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
1760               Verification of Domain-Based Application Service Identity
1761               within Internet Public Key Infrastructure Using X.509
1762               (PKIX) Certificates in the Context of Transport Layer
1763               Security (TLS)", RFC 6125, March 2011.
1764
1765    [RFC6186]  Daboo, C., "Use of SRV Records for Locating Email
1766               Submission/Access Services", RFC 6186, March 2011.
1767
1768    [RFC6672]  Rose, S. and W. Wijngaards, "DNAME Redirection in the
1769               DNS", RFC 6672, June 2012.
1770
1771    [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
1772               of Named Entities (DANE) Transport Layer Security (TLS)
1773               Protocol: TLSA", RFC 6698, August 2012.
1774
1775    [RFC7218]  Gudmundsson, O., "Adding Acronyms to Simplify
1776               Conversations about DNS-Based Authentication of Named
1777               Entities (DANE)", RFC 7218, April 2014.
1778
1779    [X.690]    International Telecommunications Union, "Recommendation
1780               ITU-T X.690 (2002) | ISO/IEC 8825-1:2002, Information
1781               technology - ASN.1 encoding rules: Specification of Basic
1782               Encoding Rules (BER), Canonical Encoding Rules (CER) and
1783               Distinguished Encoding Rules (DER)", July 2002.
1784
1785 13.2.  Informative References
1786
1787    [I-D.dukhovni-opportunistic-security]
1788
1789
1790
1791
1792 Dukhovni & Hardaker     Expires February 18, 2015              [Page 32]
1793 \f
1794 Internet-Draft  SMTP security via opportunistic DANE TLS     August 2014
1795
1796
1797               Dukhovni, V., "Opportunistic Security: Some Protection
1798               Most of the Time", draft-dukhovni-opportunistic-
1799               security-03 (work in progress), August 2014.
1800
1801    [I-D.ietf-dane-srv]
1802               Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-
1803               Based Authentication of Named Entities (DANE) TLSA Records
1804               with SRV Records", draft-ietf-dane-srv-07 (work in
1805               progress), July 2014.
1806
1807    [RFC5598]  Crocker, D., "Internet Mail Architecture", RFC 5598, July
1808               2009.
1809
1810    [RFC6409]  Gellens, R. and J. Klensin, "Message Submission for Mail",
1811               STD 72, RFC 6409, November 2011.
1812
1813 Authors' Addresses
1814
1815    Viktor Dukhovni
1816    Two Sigma
1817
1818    Email: ietf-dane@dukhovni.org
1819
1820
1821    Wes Hardaker
1822    Parsons
1823    P.O. Box 382
1824    Davis, CA  95617
1825    US
1826
1827    Email: ietf@hardakers.net
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848 Dukhovni & Hardaker     Expires February 18, 2015              [Page 33]