tidying
[exim.git] / doc / doc-txt / draft-ietf-dane-ops-06
1
2
3
4
5 DANE                                                         V. Dukhovni
6 Internet-Draft                                              Unaffiliated
7 Intended status: Standards Track                             W. Hardaker
8 Expires: February 18, 2015                                       Parsons
9                                                          August 17, 2014
10
11
12        Updates to and Operational Guidance for the DANE Protocol
13                          draft-ietf-dane-ops-06
14
15 Abstract
16
17    This memo clarifies and updates the DANE TLSA protocol based on
18    implementation experience since the publication of the original DANE
19    specification in [RFC6698].  It also contains guidance for DANE
20    implementers and operators.
21
22 Status of This Memo
23
24    This Internet-Draft is submitted in full conformance with the
25    provisions of BCP 78 and BCP 79.
26
27    Internet-Drafts are working documents of the Internet Engineering
28    Task Force (IETF).  Note that other groups may also distribute
29    working documents as Internet-Drafts.  The list of current Internet-
30    Drafts is at http://datatracker.ietf.org/drafts/current/.
31
32    Internet-Drafts are draft documents valid for a maximum of six months
33    and may be updated, replaced, or obsoleted by other documents at any
34    time.  It is inappropriate to use Internet-Drafts as reference
35    material or to cite them other than as "work in progress."
36
37    This Internet-Draft will expire on February 18, 2015.
38
39 Copyright Notice
40
41    Copyright (c) 2014 IETF Trust and the persons identified as the
42    document authors.  All rights reserved.
43
44    This document is subject to BCP 78 and the IETF Trust's Legal
45    Provisions Relating to IETF Documents
46    (http://trustee.ietf.org/license-info) in effect on the date of
47    publication of this document.  Please review these documents
48    carefully, as they describe your rights and restrictions with respect
49    to this document.  Code Components extracted from this document must
50    include Simplified BSD License text as described in Section 4.e of
51    the Trust Legal Provisions and are provided without warranty as
52    described in the Simplified BSD License.
53
54
55
56 Dukhovni & Hardaker     Expires February 18, 2015               [Page 1]
57 \f
58 Internet-Draft               DANE operations                 August 2014
59
60
61 Table of Contents
62
63    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
64      1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
65    2.  DANE TLSA Record Overview . . . . . . . . . . . . . . . . . .   4
66      2.1.  Example TLSA record . . . . . . . . . . . . . . . . . . .   6
67    3.  DANE TLS Requirements . . . . . . . . . . . . . . . . . . . .   6
68    4.  Certificate-Usage-Specific DANE Updates and Guidelines  . . .   7
69      4.1.  Certificate Usage DANE-EE(3)  . . . . . . . . . . . . . .   7
70      4.2.  Certificate Usage DANE-TA(2)  . . . . . . . . . . . . . .   8
71      4.3.  Certificate Usage PKIX-EE(1)  . . . . . . . . . . . . . .  11
72      4.4.  Certificate Usage PKIX-TA(0)  . . . . . . . . . . . . . .  12
73      4.5.  Opportunistic Security and PKIX usages  . . . . . . . . .  12
74    5.  Service Provider and TLSA Publisher Synchronization . . . . .  13
75    6.  TLSA Base Domain and CNAMEs . . . . . . . . . . . . . . . . .  15
76    7.  TLSA Publisher Requirements . . . . . . . . . . . . . . . . .  16
77      7.1.  Key rollover with fixed TLSA Parameters . . . . . . . . .  17
78      7.2.  Switching to DANE-TA from DANE-EE . . . . . . . . . . . .  18
79      7.3.  Switching to New TLSA Parameters  . . . . . . . . . . . .  18
80      7.4.  TLSA Publisher Requirements Summary . . . . . . . . . . .  19
81    8.  Digest Algorithm Agility  . . . . . . . . . . . . . . . . . .  19
82    9.  General DANE Guidelines . . . . . . . . . . . . . . . . . . .  20
83      9.1.  DANE DNS Record Size Guidelines . . . . . . . . . . . . .  21
84      9.2.  Certificate Name Check Conventions  . . . . . . . . . . .  21
85      9.3.  Design Considerations for Protocols Using DANE  . . . . .  23
86    10. Interaction with Certificate Transparency . . . . . . . . . .  23
87    11. Note on DNSSEC Security . . . . . . . . . . . . . . . . . . .  24
88    12. Summary of Updates to RFC6698 . . . . . . . . . . . . . . . .  25
89    13. Security Considerations . . . . . . . . . . . . . . . . . . .  26
90    14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  26
91    15. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  26
92    16. References  . . . . . . . . . . . . . . . . . . . . . . . . .  27
93      16.1.  Normative References . . . . . . . . . . . . . . . . . .  27
94      16.2.  Informative References . . . . . . . . . . . . . . . . .  28
95    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  28
96
97 1.  Introduction
98
99    [RFC6698] specifies a new DNS resource record "TLSA" that associates
100    a public certificate or public key of a trusted leaf or issuing
101    authority with the corresponding TLS transport endpoint.  These DANE
102    TLSA records, when validated by DNSSEC, can be used to augment or
103    replace the trust model of the existing public Certification
104    Authority (CA) Public Key Infrastructure (PKI).
105
106    [RFC6698] defines three TLSA record fields with respectively 4, 2 and
107    3 currently specified values.  These yield 24 distinct combinations
108    of TLSA record types.  This many options have lead to implementation
109
110
111
112 Dukhovni & Hardaker     Expires February 18, 2015               [Page 2]
113 \f
114 Internet-Draft               DANE operations                 August 2014
115
116
117    and operational complexity.  This memo will recommend best-practice
118    choices to help simplify implementation and deployment given these
119    plethora of choices.
120
121    Implementation complexity also arises from the fact that the TLS
122    transport endpoint is often specified indirectly via Service Records
123    (SRV), Mail Exchange (MX) records, CNAME records or other mechanisms
124    that map an abstract service domain to a concrete server domain.
125    With service indirection there are multiple potential places for
126    clients to find the relevant TLSA records.  Service indirection is
127    often used to implement "virtual hosting", where a single Service
128    Provider transport endpoint simultaneously supports multiple hosted
129    domain names.  With services that employ TLS, such hosting
130    arrangements may require the Service Provider to deploy multiple
131    pairs of private keys and certificates with TLS clients signaling the
132    desired domain via the Server Name Indication (SNI) extension
133    ([RFC6066], section 3).  This memo provides operational guidelines
134    intended to maximize interoperability between DANE TLS clients and
135    servers.
136
137    In the context of this memo, channel security is assumed to be
138    provided by TLS or DTLS.  The Transport Layer Security (TLS)
139    [RFC5246] and Datagram Transport Layer Security (DTLS) [RFC6347]
140    protocols provide secured TCP and UDP communication over IP.  By
141    convention, "TLS" will be used throughout this document and, unless
142    otherwise specified, the text applies equally well to the DTLS
143    protocol.  Used without authentication, TLS provides protection only
144    against eavesdropping through its use of encryption.  With
145    authentication, TLS also provides integrity protection and
146    authentication, which protect the transport against man-in-the-middle
147    (MITM) attacks.
148
149    Other related documents that build on [RFC6698] are
150    [I-D.ietf-dane-srv] and [I-D.ietf-dane-smtp-with-dane].  In
151    Section 12 we summarize the updates this document makes to [RFC6698].
152
153 1.1.  Terminology
154
155    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
156    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
157    "OPTIONAL" in this document are to be interpreted as described in
158    [RFC2119].
159
160    The following terms are used throughout this document:
161
162    Service Provider:  A company or organization that offers to host a
163       service on behalf of a Customer Domain.  The original domain name
164       associated with the service often remains under the control of the
165
166
167
168 Dukhovni & Hardaker     Expires February 18, 2015               [Page 3]
169 \f
170 Internet-Draft               DANE operations                 August 2014
171
172
173       customer.  Connecting applications may be directed to the Service
174       Provider via a redirection resource record.  Example redirection
175       records include MX, SRV, and CNAME.  The Service Provider
176       frequently provides services for many customers and must carefully
177       manage any TLS credentials offered to connecting applications to
178       ensure name matching is handled easily by the applications.
179
180    Customer Domain:  As described above, a client may be interacting
181       with a service that is hosted by a third party.  We will refer to
182       the domain name used to locate the service prior to any
183       redirection, as the "Customer Domain".
184
185    TLSA Publisher:  The entity responsible for publishing a TLSA record
186       within a DNS zone.  This zone will be assumed DNSSEC-signed and
187       validatable to a trust anchor, unless otherwise specified.  If the
188       Customer Domain is not outsourcing their DNS service, the TLSA
189       Publisher will be the customer themselves.  Otherwise, the TLSA
190       Publisher is sometimes the operator of the outsourced DNS service.
191
192    public key:  The term "public key" is short-hand for the
193       subjectPublicKeyInfo component of a PKIX [RFC5280] certificate.
194
195    SNI:  The "Server Name Indication" (SNI) TLS protocol extension
196       allows a TLS client to request a connection to a particular
197       service name of a TLS server ([RFC6066], section 3).  Without this
198       TLS extension, a TLS server has no choice but to offer a PKIX
199       certificate with a default list of server names, making it
200       difficult to host multiple Customer Domains at the same IP-
201       addressed based TLS service endpoint (i.e., "secure virtual
202       hosting").
203
204    TLSA parameters:  In [RFC6698] the TLSA record is defined to consist
205       of four fields.  The first three of these are numeric parameters
206       that specify the meaning of the data in fourth and final field.
207       To avoid language contortions when we need to distinguish between
208       the first three fields that together define a TLSA record "type"
209       and the fourth that provides a data value of that type, we will
210       call the first three fields "TLSA parameters", or sometimes just
211       "parameters" when obvious from context.
212
213 2.  DANE TLSA Record Overview
214
215
216
217
218
219
220
221
222
223
224 Dukhovni & Hardaker     Expires February 18, 2015               [Page 4]
225 \f
226 Internet-Draft               DANE operations                 August 2014
227
228
229    DANE TLSA [RFC6698] specifies a protocol for publishing TLS server
230    certificate associations via DNSSEC [RFC4033] [RFC4034] [RFC4035].
231    The DANE TLSA specification defines multiple TLSA RR types via
232    combinations of numeric values of the first three fields of the TLSA
233    record (i.e. the "TLSA parameters").  The numeric values of these
234    parameters were later given symbolic names in [RFC7218].  These
235    parameters are:
236
237    The Certificate Usage field:  Section 2.1.1 of [RFC6698] specifies 4
238       values: PKIX-TA(0), PKIX-EE(1), DANE-TA(2), and DANE-EE(3).  There
239       is an additional private-use value: PrivCert(255).  All other
240       values are reserved for use by future specifications.
241
242    The selector field:  Section 2.1.2 of [RFC6698] specifies 2 values:
243       Cert(0), SPKI(1).  There is an additional private-use value:
244       PrivSel(255).  All other values are reserved for use by future
245       specifications.
246
247    The matching type field:  Section 2.1.3 of [RFC6698] specifies 3
248       values: Full(0), SHA2-256(1), SHA2-512(2).  There is an additional
249       private-use value: PrivMatch(255).  All other values are reserved
250       for use by future specifications.
251
252    We may think of TLSA Certificate Usage values 0 through 3 as a
253    combination of two one-bit flags.  The low-bit chooses between trust
254    anchor (TA) and end entity (EE) certificates.  The high bit chooses
255    between PKIX, or public PKI issued, and DANE, or domain-issued trust
256    anchors:
257
258    o  When the low bit is set (PKIX-EE(1) and DANE-EE(3)) the TLSA
259       record matches an EE certificate (also commonly referred to as a
260       leaf or server certificate.)
261
262    o  When the low bit is not set (PKIX-TA(0) and DANE-TA(2)) the TLSA
263       record matches a trust anchor (a Certification Authority) that
264       issued one of the certificates in the server certificate chain.
265
266    o  When the high bit is set (DANE-TA(2) and DANE-EE(3)), the server
267       certificate chain is domain-issued and may be verified without
268       reference to any pre-existing public certification authority PKI.
269       Trust is entirely placed on the content of the TLSA records
270       obtained via DNSSEC.
271
272
273
274
275
276
277
278
279
280 Dukhovni & Hardaker     Expires February 18, 2015               [Page 5]
281 \f
282 Internet-Draft               DANE operations                 August 2014
283
284
285    o  When the high bit is not set (PKIX-TA(0) and PKIX-EE(1)), the TLSA
286       record publishes a server policy stating that its certificate
287       chain must pass PKIX validation [RFC5280] and the DANE TLSA record
288       is used to signal an additional requirement that the PKIX
289       validated server certificate chain also contains the referenced CA
290       or EE certificate.
291
292    The selector field specifies whether the TLSA RR matches the whole
293    certificate (Cert(0)) or just its subjectPublicKeyInfo (SPKI(1)).
294    The subjectPublicKeyInfo is an ASN.1 DER encoding of the
295    certificate's algorithm id, any parameters and the public key data.
296
297    The matching type field specifies how the TLSA RR Certificate
298    Association Data field is to be compared with the certificate or
299    public key.  A value of Full(0) means an exact match: the full DER
300    encoding of the certificate or public key is given in the TLSA RR.  A
301    value of SHA2-256(1) means that the association data matches the
302    SHA2-256 digest of the certificate or public key, and likewise
303    SHA2-512(2) means a SHA2-512 digest is used.  Of the two digest
304    algorithms, for now only SHA2-256(1) is mandatory to implement.
305    Clients SHOULD implement SHA2-512(2), but servers SHOULD NOT
306    exclusively publish SHA2-512(2) digests.  The digest algorithm
307    agility protocol defined in Section 8 SHOULD be used by clients to
308    decide how to process TLSA RRsets that employ multiple digest
309    algorithms.  Server operators MUST publish TLSA RRsets that are
310    compatible with digest algorithm agility.
311
312 2.1.  Example TLSA record
313
314    In the example TLSA record below:
315
316    _25._tcp.mail.example.com. IN TLSA PKIX-TA Cert SHA2-256 (
317                               E8B54E0B4BAA815B06D3462D65FBC7C0
318                               CF556ECCF9F5303EBFBB77D022F834C0 )
319
320    The TLSA Certificate Usage is DANE-TA(2), the selector is Cert(0) and
321    the matching type is SHA2-256(1).  The last field is the Certificate
322    Association Data Field, which in this case contains the SHA2-256
323    digest of the server certificate.
324
325 3.  DANE TLS Requirements
326
327    [RFC6698] does not discuss what versions of TLS are required when
328    using DANE records.  This document specifies that TLS clients that
329    support DANE/TLSA MUST support at least TLS 1.0 and SHOULD support
330    TLS 1.2.  TLS clients and servers using DANE SHOULD support the
331    "Server Name Indication" (SNI) extension of TLS.
332
333
334
335
336 Dukhovni & Hardaker     Expires February 18, 2015               [Page 6]
337 \f
338 Internet-Draft               DANE operations                 August 2014
339
340
341 4.  Certificate-Usage-Specific DANE Updates and Guidelines
342
343    The four Certificate Usage values from the TLSA record, DANE-EE(3),
344    DANE-TA(2), PKIX-EE(1) and PKIX-TA(0), are discussed below.
345
346 4.1.  Certificate Usage DANE-EE(3)
347
348    In this section the meaning of DANE-EE(3) is updated from [RFC6698]
349    to specify that peer identity matching and that validity interval
350    compliance is based solely on the TLSA RRset properties.  We also
351    extend [RFC6698] to cover the use of DANE authentication of raw
352    public keys [I-D.ietf-tls-oob-pubkey] via TLSA records with
353    Certificate Usage DANE-EE(3) and selector SPKI(1).
354
355    Authentication via certificate usage DANE-EE(3) TLSA records involves
356    simply checking that the server's leaf certificate matches the TLSA
357    record.  In particular, the binding of the server public key to its
358    name is based entirely on the TLSA record association.  The server
359    MUST be considered authenticated even if none of the names in the
360    certificate match the client's reference identity for the server.
361
362    Similarly, with DANE-EE(3), the expiration date of the server
363    certificate MUST be ignored.  The validity period of the TLSA record
364    key binding is determined by the validity interval of the TLSA record
365    DNSSEC signatures.
366
367    With DANE-EE(3) servers that know all the connecting clients are
368    making use of DANE, they need not employ SNI (i.e., the may ignore
369    the client's SNI message) even when the server is known under
370    multiple domain names that would otherwise require separate
371    certificates.  It is instead sufficient for the TLSA RRsets for all
372    the domain names in question to match the server's primary
373    certificate.  For application protocols where the server name is
374    obtained indirectly via SRV, MX or similar records, it is simplest to
375    publish a single hostname as the target server name for all the
376    hosted domains.
377
378    In organizations where it is practical to make coordinated changes in
379    DNS TLSA records before server key rotation, it is generally best to
380    publish end-entity DANE-EE(3) certificate associations in preference
381    to other choices of certificate usage.  DANE-EE(3) TLSA records
382    support multiple server names without SNI, don't suddenly stop
383    working when leaf or intermediate certificates expire, and don't fail
384    when a server operator neglects to include all the required issuer
385    certificates in the server certificate chain.
386
387    TLSA records published for DANE servers SHOULD, as a best practice,
388    be "DANE-EE(3) SPKI(1) SHA2-256(1)" records.  Since all DANE
389
390
391
392 Dukhovni & Hardaker     Expires February 18, 2015               [Page 7]
393 \f
394 Internet-Draft               DANE operations                 August 2014
395
396
397    implementations are required to support SHA2-256, this record type
398    works for all clients and need not change across certificate renewals
399    with the same key.  This TLSA record type easily supports hosting
400    arrangements with a single certificate matching all hosted domains.
401    It is also the easiest to implement correctly in the client.
402
403    Another advantage of "DANE-EE(3) SPKI(1)" (with any suitable matching
404    type) TLSA records is that they are compatible with the raw public
405    key TLS extension specified in [I-D.ietf-tls-oob-pubkey].  DANE
406    clients that support this extension can use the TLSA record to
407    authenticate servers that negotiate the use of raw public keys in
408    place of X.509 certificate chains.  Provided the server adheres to
409    the requirements of Section 7, the fact that raw public keys are not
410    compatible with any other TLSA record types will not get in the way
411    of successful authentication.  Clients that employ DANE to
412    authenticate the peer server SHOULD NOT negotiate the use of raw
413    public keys unless the server's TLSA RRset includes compatible TLSA
414    records.
415
416    While it is, in principle, also possible to authenticate raw public
417    keys via "DANE-EE(3) Cert(0) Full(0)" records by extracting the
418    public key from the certificate in DNS, this is in conflict with the
419    indicated selector and requires extra logic on clients that not all
420    implementations are expected to provide.  Servers SHOULD NOT rely on
421    "DANE-EE(3) Cert(0) Full(0)" TLSA records to publish authentication
422    data for raw public keys.
423
424 4.2.  Certificate Usage DANE-TA(2)
425
426    This section updates [RFC6698] by specifying a new operational
427    requirement for servers publishing TLSA records with a usage of DANE-
428    TA(2): such servers MUST include the trust-anchor certificate in
429    their TLS server certificate message.
430
431    Some domains may prefer to avoid the operational complexity of
432    publishing unique TLSA RRs for each TLS service.  If the domain
433    employs a common issuing Certification Authority to create
434    certificates for multiple TLS services, it may be simpler to publish
435    the issuing authority as a trust anchor (TA) for the certificate
436    chains of all relevant services.  The TLSA query domain (TLSA base
437    domain with port and protocol prefix labels) for each service issued
438    by the same TA may then be set to a CNAME alias that points to a
439    common TLSA RRset that matches the TA.  For example:
440
441
442
443
444
445
446
447
448 Dukhovni & Hardaker     Expires February 18, 2015               [Page 8]
449 \f
450 Internet-Draft               DANE operations                 August 2014
451
452
453    www1.example.com.            IN A 192.0.2.1
454    www2.example.com.            IN A 192.0.2.2
455    _443._tcp.www1.example.com.  IN CNAME tlsa201._dane.example.com.
456    _443._tcp.www2.example.com.  IN CNAME tlsa201._dane.example.com.
457    tlsa201._dane.example.com.   IN TLSA 2 0 1 e3b0c44298fc1c14...
458
459    With usage DANE-TA(2) the server certificates will need to have names
460    that match one of the client's reference identifiers (see [RFC6125]).
461    The server SHOULD employ SNI to select the appropriate certificate to
462    present to the client.
463
464 4.2.1.  Recommended record combinations
465
466    TLSA records with selector Full(0) are NOT RECOMMENDED.  While these
467    potentially obviate the need to transmit the TA certificate in the
468    TLS server certificate message, client implementations may not be
469    able to augment the server certificate chain with the data obtained
470    from DNS, especially when the TLSA record supplies a bare key
471    (selector SPKI(1)).  Since the server will need to transmit the TA
472    certificate in any case, server operators SHOULD publish TLSA records
473    with a selector other than Full(0) and avoid potential DNS
474    interoperability issues with large TLSA records containing full
475    certificates or keys (see Section 9.1.1).
476
477    TLSA Publishers employing DANE-TA(2) records SHOULD publish records
478    with a selector of Cert(0).  Such TLSA records are associated with
479    the whole trust anchor certificate, not just with the trust anchor
480    public key.  In particular, the client SHOULD then apply any relevant
481    constraints from the trust anchor certificate, such as, for example,
482    path length constraints.
483
484    While a selector of SPKI(1) may also be employed, the resulting TLSA
485    record will not specify the full trust anchor certificate content,
486    and elements of the trust anchor certificate other than the public
487    key become mutable.  This may, for example, enable a subsidiary CA to
488    issue a chain that violates the trust anchor's path length or name
489    constraints.
490
491 4.2.2.  Trust anchor digests and server certificate chain
492
493    With DANE-TA(2) (these TLSA records are expected to match the digest
494    of a TA certificate or public key), a complication arises when the TA
495    certificate is omitted from the server's certificate chain, perhaps
496    on the basis of Section 7.4.2 of [RFC5246]:
497
498
499
500
501
502
503
504 Dukhovni & Hardaker     Expires February 18, 2015               [Page 9]
505 \f
506 Internet-Draft               DANE operations                 August 2014
507
508
509    The sender's certificate MUST come first in the list.  Each
510    following certificate MUST directly certify the one preceding
511    it.  Because certificate validation requires that root keys be
512    distributed independently, the self-signed certificate that
513    specifies the root certification authority MAY be omitted from
514    the chain, under the assumption that the remote end must
515    already possess it in order to validate it in any case.
516
517    With TLSA Certificate Usage DANE-TA(2), there is no expectation that
518    the client is pre-configured with the trust anchor certificate.  In
519    fact, client implementations are free to ignore all locally
520    configured trust anchors when processing usage DANE-TA(2) TLSA
521    records and may rely exclusively on the certificates provided in the
522    server's certificate chain.  But, with a digest in the TLSA record,
523    the TLSA record contains neither the full trust anchor certificate
524    nor the full public key.  If the TLS server's certificate chain does
525    not contain the trust anchor certificate, DANE clients will be unable
526    to authenticate the server.
527
528    TLSA Publishers that publish TLSA Certificate Usage DANE-TA(2)
529    associations with a selector of SPKI(1) or using a digest-based
530    matching type (not Full(0)) MUST ensure that the corresponding server
531    is configured to also include the trust anchor certificate in its TLS
532    handshake certificate chain, even if that certificate is a self-
533    signed root CA and would have been optional in the context of the
534    existing public CA PKI.
535
536 4.2.3.  Trust anchor public keys
537
538    TLSA records with TLSA Certificate Usage DANE-TA(2), selector SPKI(1)
539    and a matching type of Full(0) will publish the full public key of a
540    trust anchor via DNS.  In section 6.1.1 of [RFC5280] the definition
541    of a trust anchor consists of the following four parts:
542
543    1.  the trusted issuer name,
544
545    2.  the trusted public key algorithm,
546
547    3.  the trusted public key, and
548
549    4.  optionally, the trusted public key parameters associated with the
550        public key.
551
552    Items 2-4 are precisely the contents of the subjectPublicKeyInfo
553    published in the TLSA record.  The issuer name is not included in the
554    subjectPublicKeyInfo.
555
556
557
558
559
560 Dukhovni & Hardaker     Expires February 18, 2015              [Page 10]
561 \f
562 Internet-Draft               DANE operations                 August 2014
563
564
565    With TLSA Certificate Usage DANE-TA(2), the client may not have the
566    associated trust anchor certificate, and cannot generally verify
567    whether a particular certificate chain is "issued by" the trust
568    anchor described in the TLSA record.
569
570    When the server certificate chain includes a CA certificate whose
571    public key matches the TLSA record, the client can match that CA as
572    the intended issuer.  Otherwise, the client can only check that the
573    topmost certificate in the server's chain is "signed by" the trust
574    anchor's public key in the TLSA record.  Such a check may be
575    difficult to implement, and cannot be expected to be supported by all
576    clients.
577
578    Thus, servers should not rely on "DANE-TA(2) SPKI(1) Full(0)" TLSA
579    records to be sufficient to authenticate chains issued by the
580    associated public key in the absence of a corresponding certificate
581    in the server's TLS certificate message.  Servers SHOULD include the
582    TA certificate in their certificate chain.
583
584    If none of the server's certificate chain elements match a public key
585    specified in a TLSA record, and at least one "DANE-TA(2) SPKI(1)
586    Full(0)" TLSA record is available, clients are encouraged to check
587    whether the topmost certificate in the chain is signed by the
588    provided public key and has not expired, and in that case consider
589    the server authenticated, provided the rest of the chain passes
590    validation including leaf certificate name checks.
591
592 4.3.  Certificate Usage PKIX-EE(1)
593
594    This Certificate Usage is similar to DANE-EE(3), but in addition PKIX
595    verification is required.  Therefore, name checks, certificate
596    expiration, etc., apply as they would without DANE.  When, for a
597    given application protocol, DANE clients support both DANE-EE(3) and
598    PKIX-EE(1) usages, it should be noted that an attacker who can
599    compromise DNSSEC can replace these with usage DANE-EE(3) or DANE-
600    TA(2) TLSA records of their choosing, and thus bypass any PKIX
601    verification requirements.
602
603    Therefore, except when applications support only the PKIX Certificate
604    Usages (0 and 1), this Certificate Usage offers only illusory
605    incremental security over usage DANE-EE(3).  It provides lower
606    operational reliability than DANE-EE(3) since some clients may not be
607    configured with the required root CA, the server's chain may be
608    incomplete or name checks may fail.  PKIX-EE(1) also requires more
609    complex coordination between the Customer Domain and the Service
610    Provider in hosting arrangements.  This certificate usage is NOT
611    RECOMMENDED.
612
613
614
615
616 Dukhovni & Hardaker     Expires February 18, 2015              [Page 11]
617 \f
618 Internet-Draft               DANE operations                 August 2014
619
620
621 4.4.  Certificate Usage PKIX-TA(0)
622
623    This section updates [RFC6698] by specifying new client
624    implementation requirements.  Clients that trust intermediate
625    certificates MUST be prepared to construct longer PKIX chains than
626    would be required for PKIX alone.
627
628    TLSA Certificate Usage PKIX-TA(0) allows a domain to publish
629    constraints on the set of PKIX certification authorities trusted to
630    issue certificates for its TLS servers.  This TLSA record matches
631    PKIX-verified trust chains which contain an issuer certificate (root
632    or intermediate) that matches its association data field (typically a
633    certificate or digest).
634
635    As with PKIX-EE(1) case, an attacker who can compromise DNSSEC can
636    replace these with usage DANE-EE(3) or DANE-TA(2) TLSA records of his
637    choosing and thus bypass the PKIX verification requirements.
638    Therefore, except when applications support only the PKIX Certificate
639    Usages (0 and 1), this Certificate Usage offers only illusory
640    incremental security over usage DANE-TA(2).  It provides lower
641    operational reliability than DANE-TA(2) since some clients may not be
642    configured with the required root CA.  PKIX-TA(0) also requires more
643    complex coordination between the Customer Domain and the Service
644    Provider in hosting arrangements.  This certificate usage is NOT
645    RECOMMENDED.
646
647    TLSA Publishers who publish TLSA records for a particular public root
648    CA, will expect that clients will then only accept chains anchored at
649    that root.  It is possible, however, that the client's trusted
650    certificate store includes some intermediate CAs, either with or
651    without the corresponding root CA.  When a client constructs a trust
652    chain leading from a trusted intermediate CA to the server leaf
653    certificate, such a "truncated" chain might not contain the trusted
654    root published in the server's TLSA record.
655
656    If the omitted root is also trusted, the client may erroneously
657    reject the server chain if it fails to determine that the shorter
658    chain it constructed extends to a longer trusted chain that matches
659    the TLSA record.  Thus, when matching a usage PKIX-TA(0) TLSA record,
660    a client SHOULD NOT always stop extending the chain when the first
661    locally trusted certificate is found.  If no TLSA records have
662    matched any of the elements of the chain, and the trusted certificate
663    found is not self-issued, the client MUST attempt to build a longer
664    chain in the hope that a certificate closer to the root may in fact
665    match the server's TLSA record.
666
667 4.5.  Opportunistic Security and PKIX usages
668
669
670
671
672 Dukhovni & Hardaker     Expires February 18, 2015              [Page 12]
673 \f
674 Internet-Draft               DANE operations                 August 2014
675
676
677    When the client's protocol design is based on Opportunistic Security
678    (OS, [I-D.dukhovni-opportunistic-security]), and authentication is
679    opportunistically employed based on the presence of server TLSA
680    records, it is especially important to avoid the PKIX-EE(1) and PKIX-
681    TA(0) certificate usages.  This is because the client has no way to
682    know in advance that it and the server both trust the requisite root
683    CA.  Use of authentication in OS needs to be employed only when the
684    client can be confident of success, absent an attack, or an
685    operational error on the server side.
686
687 5.  Service Provider and TLSA Publisher Synchronization
688
689    Complications arise when the TLSA Publisher is not the same entity as
690    the Service Provider.  In this situation, the TLSA Publisher and the
691    Service Provider must cooperate to ensure that TLSA records published
692    by the TLSA Publisher don't fall out of sync with the server
693    certificate used by the Service Provider.
694
695    Whenever possible, the TLSA Publisher and the Service Provider should
696    be the same entity.  Otherwise, changes in the service certificate
697    chain must be carefully coordinated between the parties involved.
698    Such coordination is difficult and service outages will result when
699    coordination fails.
700
701    Having the master TLSA record in the Service Provider's zone avoids
702    the complexity of bilateral coordination of server certificate
703    configuration and TLSA record management.  Even when the TLSA RRset
704    must be published in the Customer Domain's DNS zone (perhaps the
705    client application does not "chase" CNAMEs to the TLSA base domain),
706    it is possible to employ CNAME records to delegate the content of the
707    TLSA RRset to a domain operated by the Service Provider.  Certificate
708    name checks generally constrain the applicability of TLSA CNAMEs
709    across organizational boundaries to Certificate Usages DANE-EE(3) and
710    DANE-TA(2):
711
712    Certificate Usage DANE-EE(3):  In this case the Service Provider can
713       publish a single TLSA RRset that matches the server certificate or
714       public key digest.  The same RRset works for all Customer Domains
715       because name checks do not apply with DANE-EE(3) TLSA records (see
716       Section 4.1).  A Customer Domain can create a CNAME record
717       pointing to the TLSA RRset published by the Service Provider.
718
719    Certificate Usage DANE-TA(2):  When the Service Provider operates a
720       private certification authority, the Service Provider is free to
721       issue a certificate bearing any customer's domain name.  Without
722       DANE, such a certificate would not pass trust verification, but
723       with DANE, the customer's TLSA RRset that is aliased to the
724       provider's TLSA RRset can delegate authority to the provider's CA
725
726
727
728 Dukhovni & Hardaker     Expires February 18, 2015              [Page 13]
729 \f
730 Internet-Draft               DANE operations                 August 2014
731
732
733       for the corresponding service.  The Service Provider can generate
734       appropriate certificates for each customer and use the SNI
735       information provided by clients to select the right certificate
736       chain to present to each client.
737
738    Below are example DNS records (assumed "secure" and shown without the
739    associated DNSSEC information, such as record signatures) that
740    illustrate both of of the above models in the case of an HTTPS
741    service whose clients all support DANE TLS.  These examples work even
742    with clients that don't "chase" CNAMEs when constructing the TLSA
743    base domain (see Section 6 below).
744
745    ; The hosted web service is redirected via a CNAME alias.
746    ; The associated TLSA RRset is also redirected via a CNAME alias.
747    ;
748    ; A single certificate at the provider works for all Customer
749    ; Domains due to the use of the DANE-EE(3) Certificate Usage.
750    ;
751    www1.example.com.            IN CNAME w1.example.net.
752    _443._tcp.www1.example.com.  IN CNAME _443._tcp.w1.example.net.
753    _443._tcp.w1.example.net.    IN TLSA DANE-EE SPKI SHA2-256 (
754                                    8A9A70596E869BED72C69D97A8895DFA
755                                    D86F300A343FECEFF19E89C27C896BC9 )
756
757    ;
758    ; A CA at the provider can also issue certificates for each Customer
759    ; Domain, and use the DANE-TA(2) Certificate Usage type to
760    ; indicate a trust anchor.
761    ;
762    www2.example.com.            IN CNAME w2.example.net.
763    _443._tcp.www2.example.com.  IN CNAME _443._tcp.w2.example.net.
764    _443._tcp.w2.example.net.    IN TLSA DANE-TA Cert SHA2-256 (
765                                    C164B2C3F36D068D42A6138E446152F5
766                                    68615F28C69BD96A73E354CAC88ED00C )
767
768    With protocols that support explicit transport redirection via DNS MX
769    records, SRV records, or other similar records, the TLSA base domain
770    is based on the redirected transport end-point, rather than the
771    origin domain.  With SMTP, for example, when an email service is
772    hosted by a Service Provider, the Customer Domain's MX hostnames will
773    point at the Service Provider's SMTP hosts.  When the Customer
774    Domain's DNS zone is signed, the MX hostnames can be securely used as
775    the base domains for TLSA records that are published and managed by
776    the Service Provider.  For example (without the required DNSSEC
777    information, such as record signatures):
778
779
780
781
782
783
784 Dukhovni & Hardaker     Expires February 18, 2015              [Page 14]
785 \f
786 Internet-Draft               DANE operations                 August 2014
787
788
789    ; Hosted SMTP service
790    ;
791    example.com.               IN MX 0 mx1.example.net.
792    example.com.               IN MX 0 mx2.example.net.
793    _25._tcp.mx1.example.net.  IN TLSA DANE-EE SPKI SHA2-256 (
794                                  8A9A70596E869BED72C69D97A8895DFA
795                                  D86F300A343FECEFF19E89C27C896BC9 )
796    _25._tcp.mx2.example.net.  IN TLSA DANE-EE SPKI SHA2-256 (
797                                  C164B2C3F36D068D42A6138E446152F5
798                                  68615F28C69BD96A73E354CAC88ED00C )
799
800    If redirection to the Service Provider's domain (via MX or SRV
801    records or any similar mechanism) is not possible, and aliasing of
802    the TLSA record is not an option, then more complex coordination
803    between the Customer Domain and Service Provider will be required.
804    Either the Customer Domain periodically provides private keys and a
805    corresponding certificate chain to the Provider (after making
806    appropriate changes in its TLSA records), or the Service Provider
807    periodically generates the keys and certificates and must wait for
808    matching TLSA records to be published by its Customer Domains before
809    deploying newly generated keys and certificate chains.  In Section 6
810    below, we describe an approach that employs CNAME "chasing" to avoid
811    the difficulties of coordinating key management across organization
812    boundaries.
813
814    For further information about combining DANE and SRV, please see
815    [I-D.ietf-dane-srv].
816
817 6.  TLSA Base Domain and CNAMEs
818
819    When the application protocol does not support service location
820    indirection via MX, SRV or similar DNS records, the service may be
821    redirected via a CNAME.  A CNAME is a more blunt instrument for this
822    purpose, since unlike an MX or SRV record, it remaps the entire
823    origin domain to the target domain for all protocols.
824
825    The complexity of coordinating key management is largely eliminated
826    when DANE TLSA records are found in the Service Provider's domain, as
827    discussed in Section 5.  Therefore, DANE TLS clients connecting to a
828    server whose domain name is a CNAME alias SHOULD follow the CNAME
829    hop-by-hop to its ultimate target host (noting at each step whether
830    the CNAME is DNSSEC-validated).  If at each stage of CNAME expansion
831    the DNSSEC validation status is "secure", the final target name
832    SHOULD be the preferred base domain for TLSA lookups.
833
834    Implementations failing to find a TLSA record using a base name of
835    the final target of a CNAME expansion SHOULD issue a TLSA query using
836    the original destination name.  That is, the preferred TLSA base
837
838
839
840 Dukhovni & Hardaker     Expires February 18, 2015              [Page 15]
841 \f
842 Internet-Draft               DANE operations                 August 2014
843
844
845    domain should be derived from the fully expanded name, and failing
846    that should be the initial domain name.
847
848    When the TLSA base domain is the result of "secure" CNAME expansion,
849    the resulting domain name MUST be used as the HostName in SNI, and
850    MUST be the primary reference identifier for peer certificate
851    matching with certificate usages other than DANE-EE(3).
852
853    Protocol-specific TLSA specifications may provide additional guidance
854    or restrictions when following CNAME expansions.
855
856    Though CNAMEs are illegal on the right hand side of most indirection
857    records, such as MX and SRV records, they are supported by some
858    implementations.  For example, if the MX or SRV host is a CNAME
859    alias, some implementations may "chase" the CNAME.  If they do, they
860    SHOULD use the target hostname as the preferred TLSA base domain as
861    described above (and if the TLSA records are found there, use the
862    CNAME expanded domain also in SNI and certificate name checks).
863
864 7.  TLSA Publisher Requirements
865
866    This section updates [RFC6698] by specifying a requirement on the
867    TLSA Publisher to ensure that each combination of Certificate Usage,
868    selector and matching type in the server's TLSA RRset MUST include at
869    least one record that matches the server's current certificate chain.
870    TLSA records that match recently retired or yet to be deployed
871    certificate chains will be present during key rollover.  Such past or
872    future records must never be the only records published for any given
873    combination of usage, selector and matching type.  We describe a TLSA
874    record update algorithm that ensures this requirement is met.
875
876    While a server is to be considered authenticated when its certificate
877    chain is matched by any of the published TLSA records, not all
878    clients support all combinations of TLSA record parameters.  Some
879    clients may not support some digest algorithms, others may either not
880    support, or may exclusively support, the PKIX Certificate Usages.
881    Some clients may prefer to negotiate [I-D.ietf-tls-oob-pubkey] raw
882    public keys, which are only compatible with TLSA records whose
883    Certificate Usage is DANE-EE(3) with selector SPKI(1).
884
885
886
887
888
889
890
891
892
893
894
895
896 Dukhovni & Hardaker     Expires February 18, 2015              [Page 16]
897 \f
898 Internet-Draft               DANE operations                 August 2014
899
900
901    A consequence of the above uncertainty as to which TLSA parameters
902    are supported by any given client is that servers need to ensure that
903    each and every parameter combination that appears in the TLSA RRset
904    is, on its own, sufficient to match the server's current certificate
905    chain.  In particular, when deploying new keys or new parameter
906    combinations some care is required to not generate parameter
907    combinations that only match past or future certificate chains (or
908    raw public keys).  The rest of this section explains how to update
909    the TLSA RRset in a manner that ensures the above requirement is met.
910
911 7.1.  Key rollover with fixed TLSA Parameters
912
913    The simplest case is key rollover while retaining the same set of
914    published parameter combinations.  In this case, TLSA records
915    matching the existing server certificate chain (or raw public keys)
916    are first augmented with corresponding records matching the future
917    keys, at least two TTLs or longer before the the new chain is
918    deployed.  This allows the obsolete RRset to age out of client caches
919    before the new chain is used in TLS handshakes.  Once sufficient time
920    has elapsed and all clients performing DNS lookups are retrieving the
921    updated TLSA records, the server administrator may deploy the new
922    certificate chain, verify that it works, and then remove any obsolete
923    records matching the no longer active chain:
924
925    ; The initial TLSA RRset
926    ;
927    _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
928
929    ; The transitional TLSA RRset published at least 2*TTL seconds
930    ; before the actual key change
931    ;
932    _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
933    _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
934
935    ; The final TLSA RRset after the key change
936    ;
937    _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
938
939    The next case to consider is adding or switching to a new combination
940    of TLSA parameters.  In this case publish the new parameter
941    combinations for the server's existing certificate chain first, and
942    only then deploy new keys if desired:
943
944
945
946
947
948
949
950
951
952 Dukhovni & Hardaker     Expires February 18, 2015              [Page 17]
953 \f
954 Internet-Draft               DANE operations                 August 2014
955
956
957    ; Initial TLSA RRset
958    ;
959    _443._tcp.www.example.org. IN TLSA 1 1 1 01d09d19c2139a46...
960
961    ; New TLSA RRset, same key re-published as DANE-EE(3)
962    ;
963    _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
964
965 7.2.  Switching to DANE-TA from DANE-EE
966
967    A more complex involves switching to a trust-anchor or PKIX usage
968    from a chain that is either self-signed, or issued by a private CA
969    and thus not compatible with PKIX.  Here the process is to first add
970    TLSA records matching the future chain that is issued by the desired
971    future CA (private or PKIX), but initially with the same parameters
972    as the legacy chain.  Then, after deploying the new keys, switch to
973    the new TLSA parameter combination.
974
975    ; The initial TLSA RRset
976    ;
977    _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
978
979    ; A transitional TLSA RRset, published at least 2*TTL before the
980    ; actual key change.  The new keys are issued by a DANE-TA(2) CA,
981    ; but for now specified via a DANE-EE(3) association.
982    ;
983    _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
984    _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
985
986    ; The final TLSA RRset after the key change.  Now that the old
987    ; self-signed EE keys are not an impediment, specify the issuing
988    ; TA of the new keys.
989    ;
990    _443._tcp.www.example.org. IN TLSA 2 0 1 c57bce38455d9e3d...
991
992 7.3.  Switching to New TLSA Parameters
993
994    When employing a new digest algorithm in the TLSA RRset, for
995    compatibility with digest agility specified in Section 8 below,
996    administrators should publish the new digest algorithm with each
997    combinations of Certificate Usage and selector for each associated
998    key or chain used with any other digest algorithm.  When removing an
999    algorithm, remove it entirely.  Each digest algorithm employed should
1000    match the same set of chains (or raw public keys).
1001
1002
1003
1004
1005
1006
1007
1008 Dukhovni & Hardaker     Expires February 18, 2015              [Page 18]
1009 \f
1010 Internet-Draft               DANE operations                 August 2014
1011
1012
1013    ; The initial TLSA RRset with EE SHA2-256 associations for two keys.
1014    ;
1015    _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
1016    _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
1017
1018    ; The new TLSA RRset also with SHA2-512 associations for each key
1019    ;
1020    _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
1021    _443._tcp.www.example.org. IN TLSA 3 1 2 d9947c35089310bc...
1022    _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
1023    _443._tcp.www.example.org. IN TLSA 3 1 2 89a7486a4b6ae714...
1024
1025 7.4.  TLSA Publisher Requirements Summary
1026
1027    In summary, server operators updating TLSA records should make one
1028    change at a time.  The individual safe changes are:
1029
1030    o  Pre-publish new certificate associations that employ the same TLSA
1031       parameters (usage, selector and matching type) as existing TLSA
1032       records, but match certificate chains that will be deployed in the
1033       near future.  Wait for stale TLSA RRsets to expire from DNS caches
1034       before configuring servers to use the new certificate chain.
1035
1036    o  Remove TLSA records matching no longer deployed certificate
1037       chains.
1038
1039    o  Extend the TLSA RRset with a new combination of parameters (usage,
1040       selector and matching type) that is used to generate matching
1041       associations for all certificate chains that are published with
1042       some other parameter combination.
1043
1044    The above steps are intended to ensure that at all times and for each
1045    combination of usage, selector and matching type at least one TLSA
1046    record corresponds to the server's current certificate chain.  No
1047    combination of Certificate Usage, selector and matching type in a
1048    server's TLSA RRset should ever match only some combination of future
1049    or past certificate chains.  As a result, no matter what combinations
1050    of usage, selector and matching type may be supported by a given
1051    client, they will be sufficient to authenticate the server.
1052
1053 8.  Digest Algorithm Agility
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064 Dukhovni & Hardaker     Expires February 18, 2015              [Page 19]
1065 \f
1066 Internet-Draft               DANE operations                 August 2014
1067
1068
1069    While [RFC6698] specifies multiple digest algorithms, it does not
1070    specify a protocol by which the TLS client and TLSA record publisher
1071    can agree on the strongest shared algorithm.  Such a protocol would
1072    allow the client and server to avoid exposure to any deprecated
1073    weaker algorithms that are published for compatibility with less
1074    capable clients, but should be ignored when possible.  We specify
1075    such a protocol below.
1076
1077    Suppose that a DANE TLS client authenticating a TLS server considers
1078    digest algorithm "BetterAlg" stronger than digest algorithm
1079    "WorseAlg".  Suppose further that a server's TLSA RRset contains some
1080    records with "BetterAlg" as the digest algorithm.  Suppose also that
1081    the server adheres to the requirements of Section 7 and ensures that
1082    each combination of TLSA parameters contains at least one record that
1083    matches the server's current certificate chain (or raw public keys).
1084    Under the above assumptions the client can safely ignore TLSA records
1085    with the weaker algorithm "WorseAlg", because it suffices to only
1086    check the records with the stronger algorithm "BetterAlg".
1087
1088    To make digest algorithm agility possible, all published TLSA RRsets
1089    for use with DANE TLS MUST conform to the requirements of Section 7.
1090    With servers publishing compliant TLSA RRsets, TLS clients can, for
1091    each combination of usage and selector, ignore all digest records
1092    except those that employ their notion of the strongest digest
1093    algorithm.  (The server should only publish algorithms it deems
1094    acceptable at all.)  The ordering of digest algorithms by strength is
1095    not specified in advance; it is entirely up to the TLS client.  TLS
1096    client implementations SHOULD make the digest algorithm preference
1097    ordering a configurable option.
1098
1099    Note, TLSA records with a matching type of Full(0) that publish an
1100    entire certificate or public key object play no role in digest
1101    algorithm agility.  They neither trump the processing of records that
1102    employ digests, nor are they ignored in the presence of any records
1103    with a digest (i.e. non-zero) matching type.
1104
1105    TLS clients SHOULD use digest algorithm agility when processing the
1106    DANE TLSA records of an TLS server.  Algorithm agility is to be
1107    applied after first discarding any unusable or malformed records
1108    (unsupported digest algorithm, or incorrect digest length).  Thus,
1109    for each usage and selector, the client SHOULD process only any
1110    usable records with a matching type of Full(0) and the usable records
1111    whose digest algorithm is considered by the client to be the
1112    strongest among usable records with the given usage and selector.
1113
1114 9.  General DANE Guidelines
1115
1116
1117
1118
1119
1120 Dukhovni & Hardaker     Expires February 18, 2015              [Page 20]
1121 \f
1122 Internet-Draft               DANE operations                 August 2014
1123
1124
1125    These guidelines provide guidance for using or designing protocols
1126    for DANE.
1127
1128 9.1.  DANE DNS Record Size Guidelines
1129
1130    Selecting a combination of TLSA parameters to use requires careful
1131    thought.  One important consideration to take into account is the
1132    size of the resulting TLSA record after its parameters are selected.
1133
1134 9.1.1.  UDP and TCP Considerations
1135
1136    Deployments SHOULD avoid TLSA record sizes that cause UDP
1137    fragmentation.
1138
1139    Although DNS over TCP would provide the ability to more easily
1140    transfer larger DNS records between clients and servers, it is not
1141    universally deployed and is still prohibited by some firewalls.
1142    Clients that request DNS records via UDP typically only use TCP upon
1143    receipt of a truncated response in the DNS response message sent over
1144    UDP.  Setting the TC bit alone will be insufficient if the response
1145    containing the TC bit is itself fragmented.
1146
1147 9.1.2.  Packet Size Considerations for TLSA Parameters
1148
1149    Server operators SHOULD NOT publish TLSA records using both a TLSA
1150    Selector of Cert(0) and a TLSA Matching Type of Full(0), as even a
1151    single certificate is generally too large to be reliably delivered
1152    via DNS over UDP.  Furthermore, two TLSA records containing full
1153    certificates will need to be published simultaneously during a
1154    certificate rollover, as discussed in Section 7.1.
1155
1156    While TLSA records using a TLSA Selector of SPKI(1) and a TLSA
1157    Matching Type of Full(0) (which publish the bare public keys without
1158    the overhead of a containing X.509 certificate) are generally more
1159    compact, these too should be used with caution as they are still
1160    larger than necessary.  Rather, servers SHOULD publish digest-based
1161    TLSA Matching Types in their TLSA records.  The complete
1162    corresponding certificate should, instead, be transmitted to the
1163    client in-band during the TLS handshake, which can be easily verified
1164    using the digest value.
1165
1166    In summary, the use of a TLSA Matching Type of Full(0) is NOT
1167    RECOMMENDED and the use of a digest-based matching type, such as
1168    SHA2-256(1) SHOULD be used.
1169
1170 9.2.  Certificate Name Check Conventions
1171
1172
1173
1174
1175
1176 Dukhovni & Hardaker     Expires February 18, 2015              [Page 21]
1177 \f
1178 Internet-Draft               DANE operations                 August 2014
1179
1180
1181    Certificates presented by a TLS server will generally contain a
1182    subjectAltName (SAN) extension or a Common Name (CN) element within
1183    the subject distinguished name (DN).  The TLS server's DNS domain
1184    name is normally published within these elements, ideally within the
1185    subjectAltName extension.  (The use of the CN field for this purpose
1186    is deprecated.)
1187
1188    When a server hosts multiple domains at the same transport endpoint,
1189    the server's ability to respond with the right certificate chain is
1190    predicated on correct SNI information from the client.  DANE clients
1191    MUST send the SNI extension with a HostName value of the base domain
1192    of the TLSA RRset.
1193
1194    Except with TLSA Certificate Usage DANE-EE(3), where name checks are
1195    not applicable (see Section 4.1), DANE clients MUST verify that the
1196    client has reached the correct server by checking that the server
1197    name is listed in the server certificate's SAN or CN.  The server
1198    name used for this comparison SHOULD be the base domain of the TLSA
1199    RRset.  Additional acceptable names may be specified by protocol-
1200    specific DANE standards.  For example, with SMTP both the destination
1201    domain name and the MX host name are acceptable names to be found in
1202    the server certificate (see [I-D.ietf-dane-smtp-with-dane]).
1203
1204    It is the responsibility of the service operator, in coordination
1205    with the TLSA Publisher, to ensure that at least one of the TLSA
1206    records published for the service will match the server's certificate
1207    chain (either the default chain or the certificate that was selected
1208    based on the SNI information provided by the client).
1209
1210    Given the DNSSEC validated DNS records below:
1211
1212    example.com.               IN MX 0 mail.example.com.
1213    mail.example.com.          IN A 192.0.2.1
1214    _25._tcp.mail.example.com. IN TLSA DANE-TA Cert SHA2-256  (
1215                                  E8B54E0B4BAA815B06D3462D65FBC7C0
1216                                  CF556ECCF9F5303EBFBB77D022F834C0 )
1217
1218    The TLSA base domain is "mail.example.com" and is required to be the
1219    HostName in the client's SNI extension.  The server certificate chain
1220    is required to be be signed by a trust anchor with the above
1221    certificate SHA2-256 digest.  Finally, one of the DNS names in the
1222    server certificate is required to be be either "mail.example.com" or
1223    "example.com" (this additional name is a concession to compatibility
1224    with prior practice, see [I-D.ietf-dane-smtp-with-dane] for details).
1225
1226    The semantics of wildcards in server certificates are left to
1227    individual application protocol specifications.
1228
1229
1230
1231
1232 Dukhovni & Hardaker     Expires February 18, 2015              [Page 22]
1233 \f
1234 Internet-Draft               DANE operations                 August 2014
1235
1236
1237 9.3.  Design Considerations for Protocols Using DANE
1238
1239    When a TLS client goes to the trouble of authenticating a certificate
1240    chain presented by a TLS server, it will typically not continue to
1241    use that server in the event of authentication failure, or else
1242    authentication serves no purpose.  Some clients may, at times,
1243    operate in an "audit" mode, where authentication failure is reported
1244    to the user or in logs as a potential problem, but the connection
1245    proceeds despite the failure.  Nevertheless servers publishing TLSA
1246    records MUST be configured to allow correctly configured clients to
1247    successfully authenticate their TLS certificate chains.
1248
1249    A service with DNSSEC-validated TLSA records implicitly promises TLS
1250    support.  When all the TLSA records for a service are found
1251    "unusable", due to unsupported parameter combinations or malformed
1252    associated data, DANE clients cannot authenticate the service
1253    certificate chain.  When authenticated TLS is dictated by the
1254    application, the client SHOULD NOT connect to the associated server.
1255    If, on the other hand, the use of TLS is "opportunistic", then the
1256    client SHOULD generally use the server via an unauthenticated TLS
1257    connection, but if TLS encryption cannot be established, the client
1258    MUST NOT use the server.  Standards for DANE specific to the
1259    particular application protocol may modify the above requirements, as
1260    appropriate, to specify whether the connection should be established
1261    anyway without relying on TLS security, with only encryption but not
1262    authentication, or whether to refuse to connect entirely.
1263    Application protocols need to specify when to prioritize security
1264    over the ability to connect under adverse conditions.
1265
1266 9.3.1.  Design Considerations for non-PKIX Protocols
1267
1268    For some application protocols (such as SMTP to MX with opportunistic
1269    TLS), the existing public CA PKI is not a viable alternative to DANE.
1270    For these (non-PKIX) protocols, new DANE standards SHOULD NOT suggest
1271    publishing TLSA records with TLSA Certificate Usage PKIX-TA(0) or
1272    PKIX-EE(1), as TLS clients cannot be expected to perform [RFC5280]
1273    PKIX validation or [RFC6125] identity verification.
1274
1275    Protocols designed for non-PKIX use SHOULD choose to treat any TLSA
1276    records with TLSA Certificate Usage PKIX-TA(0) or PKIX-EE(1) as
1277    unusable.  After verifying that the only available TLSA Certificate
1278    Usage types are PKIX-TA(0) or PKIX-EE(1), protocol specifications MAY
1279    instruct clients to either refuse to initiate a connection or to
1280    connect via unauthenticated TLS if no alternative authentication
1281    mechanisms are available.
1282
1283 10.  Interaction with Certificate Transparency
1284
1285
1286
1287
1288 Dukhovni & Hardaker     Expires February 18, 2015              [Page 23]
1289 \f
1290 Internet-Draft               DANE operations                 August 2014
1291
1292
1293    Certificate Transparency (CT) [RFC6962] defines an experimental
1294    approach to mitigate the risk of rogue or compromised public CAs
1295    issuing unauthorized certificates.  This section clarifies the
1296    interaction of CT and DANE.  CT is an experimental protocol and
1297    auditing system that applies only to public CAs, and only when they
1298    are free to issue unauthorized certificates for a domain.  If the CA
1299    is not a public CA, or a DANE-EE(3) TLSA RR directly specifies the
1300    end entity certificate, there is no role for CT, and clients need not
1301    apply CT checks.
1302
1303    When a server is authenticated via a DANE TLSA RR with TLSA
1304    Certificate Usage DANE-EE(3), the domain owner has directly specified
1305    the certificate associated with the given service without reference
1306    to any PKIX certification authority.  Therefore, when a TLS client
1307    authenticates the TLS server via a TLSA certificate association with
1308    usage DANE-EE(3), CT checks SHOULD NOT be performed.  Publication of
1309    the server certificate or public key (digest) in a TLSA record in a
1310    DNSSEC signed zone by the domain owner assures the TLS client that
1311    the certificate is not an unauthorized certificate issued by a rogue
1312    CA without the domain owner's consent.
1313
1314    When a server is authenticated via a DANE TLSA RR with TLSA usage
1315    DANE-TA(2) and the server certificate does not chain to a known
1316    public root CA, CT cannot apply (CT logs only accept chains that
1317    start with a known, public root).  Since TLSA Certificate Usage DANE-
1318    TA(2) is generally intended to support non-PKIX trust anchors, TLS
1319    clients SHOULD NOT perform CT checks with usage DANE-TA(2) using
1320    unknown root CAs.
1321
1322    A server operator who wants clients to perform CT checks should
1323    publish TLSA RRs with usage PKIX-TA(0) or PKIX-EE(1).
1324
1325 11.  Note on DNSSEC Security
1326
1327    Clearly the security of the DANE TLSA PKI rests on the security of
1328    the underlying DNSSEC infrastructure.  While this memo is not a guide
1329    to DNSSEC security, a few comments may be helpful to TLSA
1330    implementers.
1331
1332    With the existing public CA PKI, name constraints are rarely used,
1333    and a public root CA can issue certificates for any domain of its
1334    choice.  With DNSSEC, under the Registry/Registrar/Registrant model,
1335    the situation is different: only the registrar of record can update a
1336    domain's DS record in the registry parent zone (in some cases,
1337    however, the registry is the sole registrar).  With many gTLDs, for
1338    which multiple registrars compete to provide domains in a single
1339    registry, it is important to make sure that rogue registrars cannot
1340    easily initiate an unauthorized domain transfer, and thus take over
1341
1342
1343
1344 Dukhovni & Hardaker     Expires February 18, 2015              [Page 24]
1345 \f
1346 Internet-Draft               DANE operations                 August 2014
1347
1348
1349    DNSSEC for the domain.  DNS Operators SHOULD use a registrar lock of
1350    their domains to offer some protection against this possibility.
1351
1352    When the registrar is also the DNS operator for the domain, one needs
1353    to consider whether the registrar will allow orderly migration of the
1354    domain to another registrar or DNS operator in a way that will
1355    maintain DNSSEC integrity.  TLSA Publishers SHOULD ensure their
1356    registrar publishes a suitable domain transfer policy.
1357
1358    DNSSEC signed RRsets cannot be securely revoked before they expire.
1359    Operators should plan accordingly and not generate signatures with
1360    excessively long duration periods.  For domains publishing high-value
1361    keys, a signature lifetime of a few days is reasonable, and the zone
1362    should be resigned daily.  For domains with less critical data, a
1363    reasonable signature lifetime is a couple of weeks to a month, and
1364    the zone should be resigned weekly.  Monitoring of the signature
1365    lifetime is important.  If the zone is not resigned in a timely
1366    manner, one risks a major outage and the entire domain will become
1367    bogus.
1368
1369 12.  Summary of Updates to RFC6698
1370
1371    Authors note: is this section needed?  Or is it sufficiently clear
1372    above that we don't need to restate things here?
1373
1374    o  In Section 3 we update [RFC6698] to specify a requirement for
1375       clients to support at least TLS 1.0, and to support SNI.
1376
1377    o  In Section 4.1 we update [RFC6698] to specify peer identity
1378       matching and certificate validity interval based solely on the
1379       basis of the TLSA RRset.  We also specify DANE authentication of
1380       raw public keys [I-D.ietf-tls-oob-pubkey] via TLSA records with
1381       Certificate Usage DANE-EE(3) and selector SPKI(1).
1382
1383    o  In Section 4.2 we update [RFC6698] to require that servers
1384       publishing digest TLSA records with a usage of DANE-TA(2) MUST
1385       include the trust-anchor certificate in their TLS server
1386       certificate message.  This extends to the case of "2 1 0" TLSA
1387       records which publish a full public key.
1388
1389    o  In Section 4.3 and Section 4.4, we explain that PKIX-EE(1) and
1390       PKIX-TA(0) are generally NOT RECOMMENDED.  With usage PKIX-TA(0)
1391       we note that clients may need to processes extended trust chains
1392       beyond the first trusted issuer, when that issuer is not self-
1393       signed.
1394
1395
1396
1397
1398
1399
1400 Dukhovni & Hardaker     Expires February 18, 2015              [Page 25]
1401 \f
1402 Internet-Draft               DANE operations                 August 2014
1403
1404
1405    o  In Section 6, we recommend that DANE application protocols specify
1406       that when possible securely CNAME expanded names be used to derive
1407       the TLSA base domain.
1408
1409    o  In Section 7, we specify a strategy for managing TLSA records that
1410       interoperates with DANE clients regardless of what subset of the
1411       possible TLSA record types (combinations of TLSA parameters) is
1412       supported by the client.
1413
1414    o  In Section 8, we propose a digest algorithm agility protocol.
1415       [Note: This section does not yet represent the rough consensus of
1416       the DANE working group and requires further discussion.  Perhaps
1417       this belongs in a separate document.]
1418
1419    o  In Section 9.1 we recommend against the use of Full(0) TLSA
1420       records, as digest records are generally much more compact.
1421
1422 13.  Security Considerations
1423
1424    Application protocols that cannot make use of the existing public CA
1425    PKI (so called non-PKIX protocols), may choose not to implement
1426    certain PKIX-dependent TLSA record types defined in [RFC6698].  If
1427    such records are published despite not being supported by the
1428    application protocol, they are treated as "unusable".  When TLS is
1429    opportunistic, the client may proceed to use the server with
1430    mandatory unauthenticated TLS.  This is stronger than opportunistic
1431    TLS without DANE, since in that case the client may also proceed with
1432    a plaintext connection.  When TLS is not opportunistic, the client
1433    MUST NOT connect to the server.
1434
1435    Therefore, when TLSA records are used with protocols where PKIX does
1436    not apply, the recommended policy is for servers to not publish PKIX-
1437    dependent TLSA records, and for opportunistic TLS clients to use them
1438    to enforce the use of (albeit unauthenticated) TLS, but otherwise
1439    treat them as unusable.  Of course, when PKIX validation is supported
1440    by the application protocol, clients SHOULD perform PKIX validation
1441    per [RFC6698].
1442
1443 14.  IANA Considerations
1444
1445    This specification requires no support from IANA.
1446
1447 15.  Acknowledgements
1448
1449    The authors would like to thank Phil Pennock for his comments and
1450    advice on this document.
1451
1452
1453
1454
1455
1456 Dukhovni & Hardaker     Expires February 18, 2015              [Page 26]
1457 \f
1458 Internet-Draft               DANE operations                 August 2014
1459
1460
1461    Acknowledgments from Viktor: Thanks to Tony Finch who finally prodded
1462    me into participating in DANE working group discussions.  Thanks to
1463    Paul Hoffman who motivated me to produce this memo and provided
1464    feedback on early drafts.  Thanks also to Samuel Dukhovni for
1465    editorial assistance.
1466
1467 16.  References
1468
1469 16.1.  Normative References
1470
1471    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
1472               Requirement Levels", BCP 14, RFC 2119, March 1997.
1473
1474    [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
1475               Rose, "DNS Security Introduction and Requirements", RFC
1476               4033, March 2005.
1477
1478    [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
1479               Rose, "Resource Records for the DNS Security Extensions",
1480               RFC 4034, March 2005.
1481
1482    [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
1483               Rose, "Protocol Modifications for the DNS Security
1484               Extensions", RFC 4035, March 2005.
1485
1486    [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
1487               (TLS) Protocol Version 1.2", RFC 5246, August 2008.
1488
1489    [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
1490               Housley, R., and W. Polk, "Internet X.509 Public Key
1491               Infrastructure Certificate and Certificate Revocation List
1492               (CRL) Profile", RFC 5280, May 2008.
1493
1494    [RFC6066]  Eastlake, D., "Transport Layer Security (TLS) Extensions:
1495               Extension Definitions", RFC 6066, January 2011.
1496
1497    [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
1498               Verification of Domain-Based Application Service Identity
1499               within Internet Public Key Infrastructure Using X.509
1500               (PKIX) Certificates in the Context of Transport Layer
1501               Security (TLS)", RFC 6125, March 2011.
1502
1503    [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
1504               Security Version 1.2", RFC 6347, January 2012.
1505
1506    [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
1507               of Named Entities (DANE) Transport Layer Security (TLS)
1508               Protocol: TLSA", RFC 6698, August 2012.
1509
1510
1511
1512 Dukhovni & Hardaker     Expires February 18, 2015              [Page 27]
1513 \f
1514 Internet-Draft               DANE operations                 August 2014
1515
1516
1517    [RFC7218]  Gudmundsson, O., "Adding Acronyms to Simplify
1518               Conversations about DNS-Based Authentication of Named
1519               Entities (DANE)", RFC 7218, April 2014.
1520
1521 16.2.  Informative References
1522
1523    [I-D.dukhovni-opportunistic-security]
1524               Dukhovni, V., "Opportunistic Security: Some Protection
1525               Most of the Time", draft-dukhovni-opportunistic-
1526               security-03 (work in progress), August 2014.
1527
1528    [I-D.ietf-dane-smtp-with-dane]
1529               Dukhovni, V. and W. Hardaker, "SMTP security via
1530               opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-11
1531               (work in progress), August 2014.
1532
1533    [I-D.ietf-dane-srv]
1534               Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-
1535               Based Authentication of Named Entities (DANE) TLSA Records
1536               with SRV Records", draft-ietf-dane-srv-07 (work in
1537               progress), July 2014.
1538
1539    [I-D.ietf-tls-oob-pubkey]
1540               Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and
1541               T. Kivinen, "Using Raw Public Keys in Transport Layer
1542               Security (TLS) and Datagram Transport Layer Security
1543               (DTLS)", draft-ietf-tls-oob-pubkey-11 (work in progress),
1544               January 2014.
1545
1546    [RFC6962]  Laurie, B., Langley, A., and E. Kasper, "Certificate
1547               Transparency", RFC 6962, June 2013.
1548
1549 Authors' Addresses
1550
1551    Viktor Dukhovni
1552    Unaffiliated
1553
1554    Email: ietf-dane@dukhovni.org
1555
1556
1557    Wes Hardaker
1558    Parsons
1559    P.O. Box 382
1560    Davis, CA  95617
1561    US
1562
1563    Email: ietf@hardakers.net
1564
1565
1566
1567
1568 Dukhovni & Hardaker     Expires February 18, 2015              [Page 28]