GnuTLS: Fix client detection of server reject of client cert under TLS1.3
[exim.git] / doc / doc-txt / rfc6698-dane.txt
1
2
3
4
5
6
7 Internet Engineering Task Force (IETF)                        P. Hoffman
8 Request for Comments: 6698                                VPN Consortium
9 Category: Standards Track                                    J. Schlyter
10 ISSN: 2070-1721                                                 Kirei AB
11                                                              August 2012
12
13
14          The DNS-Based Authentication of Named Entities (DANE)
15              Transport Layer Security (TLS) Protocol: TLSA
16
17 Abstract
18
19    Encrypted communication on the Internet often uses Transport Layer
20    Security (TLS), which depends on third parties to certify the keys
21    used.  This document improves on that situation by enabling the
22    administrators of domain names to specify the keys used in that
23    domain's TLS servers.  This requires matching improvements in TLS
24    client software, but no change in TLS server software.
25
26 Status of This Memo
27
28    This is an Internet Standards Track document.
29
30    This document is a product of the Internet Engineering Task Force
31    (IETF).  It represents the consensus of the IETF community.  It has
32    received public review and has been approved for publication by the
33    Internet Engineering Steering Group (IESG).  Further information on
34    Internet Standards is available in Section 2 of RFC 5741.
35
36    Information about the current status of this document, any errata,
37    and how to provide feedback on it may be obtained at
38    http://www.rfc-editor.org/info/rfc6698.
39
40 Copyright Notice
41
42    Copyright (c) 2012 IETF Trust and the persons identified as the
43    document authors.  All rights reserved.
44
45    This document is subject to BCP 78 and the IETF Trust's Legal
46    Provisions Relating to IETF Documents
47    (http://trustee.ietf.org/license-info) in effect on the date of
48    publication of this document.  Please review these documents
49    carefully, as they describe your rights and restrictions with respect
50    to this document.  Code Components extracted from this document must
51    include Simplified BSD License text as described in Section 4.e of
52    the Trust Legal Provisions and are provided without warranty as
53    described in the Simplified BSD License.
54
55
56
57
58 Hoffman & Schlyter           Standards Track                    [Page 1]
59 \f
60 RFC 6698            DNS-Based Authentication for TLS         August 2012
61
62
63 Table of Contents
64
65    1. Introduction ....................................................3
66       1.1. Background and Motivation ..................................3
67       1.2. Securing the Association of a Domain Name with a
68            Server's Certificate .......................................4
69       1.3. Method for Securing Certificate Associations ...............5
70       1.4. Terminology ................................................6
71    2. The TLSA Resource Record ........................................7
72       2.1. TLSA RDATA Wire Format .....................................7
73            2.1.1. The Certificate Usage Field .........................7
74            2.1.2. The Selector Field ..................................8
75            2.1.3. The Matching Type Field .............................9
76            2.1.4. The Certificate Association Data Field ..............9
77       2.2. TLSA RR Presentation Format ................................9
78       2.3. TLSA RR Examples ..........................................10
79    3. Domain Names for TLSA Certificate Associations .................10
80    4. Use of TLSA Records in TLS .....................................11
81       4.1. Usable Certificate Associations ...........................11
82    5. TLSA and DANE Use Cases and Requirements .......................13
83    6. Mandatory-to-Implement Features ................................15
84    7. IANA Considerations ............................................15
85       7.1. TLSA RRtype ...............................................15
86       7.2. TLSA Certificate Usages ...................................15
87       7.3. TLSA Selectors ............................................16
88       7.4. TLSA Matching Types .......................................16
89    8. Security Considerations ........................................16
90       8.1. Comparing DANE to Public CAs ..............................18
91            8.1.1. Risk of Key Compromise .............................19
92            8.1.2. Impact of Key Compromise ...........................20
93            8.1.3. Detection of Key Compromise ........................20
94            8.1.4. Spoofing Hostnames .................................20
95       8.2. DNS Caching ...............................................21
96       8.3. External DNSSEC Validators ................................21
97    9. Acknowledgements ...............................................22
98    10. References ....................................................22
99       10.1. Normative References .....................................22
100       10.2. Informative References ...................................23
101    Appendix A. Operational Considerations for Deploying TLSA
102                Records ...............................................25
103      A.1. Creating TLSA Records ......................................25
104        A.1.1. Ambiguities and Corner Cases When TLS Clients
105               Build Trust Chains .....................................26
106        A.1.2. Choosing a Selector Type ...............................26
107      A.2. Provisioning TLSA Records in DNS ...........................28
108        A.2.1. Provisioning TLSA Records with Aliases .................28
109      A.3. Securing the Last Hop ......................................30
110      A.4. Handling Certificate Rollover ..............................31
111
112
113
114 Hoffman & Schlyter           Standards Track                    [Page 2]
115 \f
116 RFC 6698            DNS-Based Authentication for TLS         August 2012
117
118
119    Appendix B. Pseudocode for Using TLSA .............................32
120      B.1. Helper Functions ...........................................32
121      B.2. Main TLSA Pseudocode .......................................33
122    Appendix C. Examples ..............................................35
123
124 1.  Introduction
125
126 1.1.  Background and Motivation
127
128    Applications that communicate over the Internet often need to prevent
129    eavesdropping, tampering, or forgery of their communications.  The
130    Transport Layer Security (TLS) protocol provides this kind of
131    communications security over the Internet, using channel encryption.
132
133    The security properties of encryption systems depend strongly on the
134    keys that they use.  If secret keys are revealed, or if public keys
135    can be replaced by fake keys (that is, a key not corresponding to the
136    entity identified in the certificate), these systems provide little
137    or no security.
138
139    TLS uses certificates to bind keys and names.  A certificate combines
140    a published key with other information such as the name of the
141    service that uses the key, and this combination is digitally signed
142    by another key.  Having a key in a certificate is only helpful if one
143    trusts the other key that signed the certificate.  If that other key
144    was itself revealed or substituted, then its signature is worthless
145    in proving anything about the first key.
146
147    On the Internet, this problem has been solved for years by entities
148    called "Certification Authorities" (CAs).  CAs protect their secret
149    key vigorously, while supplying their public key to the software
150    vendors who build TLS clients.  They then sign certificates, and
151    supply those to TLS servers.  TLS client software uses a set of these
152    CA keys as "trust anchors" to validate the signatures on certificates
153    that the client receives from TLS servers.  Client software typically
154    allows any CA to usefully sign any other certificate.
155
156    The public CA model upon which TLS has depended is fundamentally
157    vulnerable because it allows any of these CAs to issue a certificate
158    for any domain name.  A single trusted CA that betrays its trust,
159    either voluntarily or by providing less-than-vigorous protection for
160    its secrets and capabilities, can undermine the security offered by
161    any certificates employed with TLS.  This problem arises because a
162    compromised CA can issue a replacement certificate that contains a
163    fake key.  Recent experiences with compromises of CAs or their
164    trusted partners have led to very serious security problems, such as
165    the governments of multiple countries attempting to wiretap and/or
166    subvert major TLS-protected web sites trusted by millions of users.
167
168
169
170 Hoffman & Schlyter           Standards Track                    [Page 3]
171 \f
172 RFC 6698            DNS-Based Authentication for TLS         August 2012
173
174
175    The DNS Security Extensions (DNSSEC) provide a similar model that
176    involves trusted keys signing the information for untrusted keys.
177    However, DNSSEC provides three significant improvements.  Keys are
178    tied to names in the Domain Name System (DNS), rather than to
179    arbitrary identifying strings; this is more convenient for Internet
180    protocols.  Signed keys for any domain are accessible online through
181    a straightforward query using the standard DNSSEC protocol, so there
182    is no problem distributing the signed keys.  Most significantly, the
183    keys associated with a domain name can only be signed by a key
184    associated with the parent of that domain name; for example, the keys
185    for "example.com" can only be signed by the keys for "com", and the
186    keys for "com" can only be signed by the DNS root.  This prevents an
187    untrustworthy signer from compromising anyone's keys except those in
188    their own subdomains.  Like TLS, DNSSEC relies on public keys that
189    come built into the DNSSEC client software, but these keys come only
190    from a single root domain rather than from a multiplicity of CAs.
191
192    DNS-Based Authentication of Named Entities (DANE) offers the option
193    to use the DNSSEC infrastructure to store and sign keys and
194    certificates that are used by TLS.  DANE is envisioned as a
195    preferable basis for binding public keys to DNS names, because the
196    entities that vouch for the binding of public key data to DNS names
197    are the same entities responsible for managing the DNS names in
198    question.  While the resulting system still has residual security
199    vulnerabilities, it restricts the scope of assertions that can be
200    made by any entity, consistent with the naming scope imposed by the
201    DNS hierarchy.  As a result, DANE embodies the security "principle of
202    least privilege" that is lacking in the current public CA model.
203
204 1.2.  Securing the Association of a Domain Name with a Server's
205       Certificate
206
207    A TLS client begins a connection by exchanging messages with a TLS
208    server.  For many application protocols, it looks up the server's
209    name using the DNS to get an Internet Protocol (IP) address
210    associated with the name.  It then begins a connection to a
211    particular port at that address, and sends an initial message there.
212    However, the client does not yet know whether an adversary is
213    intercepting and/or altering its communication before it reaches the
214    TLS server.  It does not even know whether the real TLS server
215    associated with that domain name has ever received its initial
216    messages.
217
218    The first response from the server in TLS may contain a certificate.
219    In order for the TLS client to authenticate that it is talking to the
220    expected TLS server, the client must validate that this certificate
221    is associated with the domain name used by the client to get to the
222    server.  Currently, the client must extract the domain name from the
223
224
225
226 Hoffman & Schlyter           Standards Track                    [Page 4]
227 \f
228 RFC 6698            DNS-Based Authentication for TLS         August 2012
229
230
231    certificate and must successfully validate the certificate, including
232    chaining to a trust anchor.
233
234    There is a different way to authenticate the association of the
235    server's certificate with the intended domain name without trusting
236    an external CA.  Given that the DNS administrator for a domain name
237    is authorized to give identifying information about the zone, it
238    makes sense to allow that administrator to also make an authoritative
239    binding between the domain name and a certificate that might be used
240    by a host at that domain name.  The easiest way to do this is to use
241    the DNS, securing the binding with DNSSEC.
242
243    There are many use cases for such functionality.  [RFC6394] lists the
244    ones to which the DNS RRtype in this document apply.  [RFC6394] also
245    lists many requirements, most of which this document is believed to
246    meet.  Section 5 covers the applicability of this document to the use
247    cases in detail.  The protocol in this document can generally be
248    referred to as the "DANE TLSA" protocol.  ("TLSA" does not stand for
249    anything; it is just the name of the RRtype.)
250
251    This document applies to both TLS [RFC5246] and Datagram TLS (DTLS)
252    [RFC6347].  In order to make the document more readable, it mostly
253    only talks about "TLS", but in all cases, it means "TLS or DTLS".
254    Although the references in this paragraph are to TLS and DTLS
255    version 1.2, the DANE TLSA protocol can also be used with earlier
256    versions of TLS and DTLS.
257
258    This document only relates to securely associating certificates for
259    TLS and DTLS with host names; retrieving certificates from DNS for
260    other protocols is handled in other documents.  For example, keys for
261    IPsec are covered in [RFC4025], and keys for Secure SHell (SSH) are
262    covered in [RFC4255].
263
264 1.3.  Method for Securing Certificate Associations
265
266    A certificate association is formed from a piece of information
267    identifying a certificate and the domain name where the server
268    application runs.  The combination of a trust anchor and a domain
269    name can also be a certificate association.
270
271    A DNS query can return multiple certificate associations, such as in
272    the case of a server that is changing from one certificate to another
273    (described in more detail in Appendix A.4).
274
275    This document only applies to PKIX [RFC5280] certificates, not
276    certificates of other formats.
277
278
279
280
281
282 Hoffman & Schlyter           Standards Track                    [Page 5]
283 \f
284 RFC 6698            DNS-Based Authentication for TLS         August 2012
285
286
287    This document defines a secure method to associate the certificate
288    that is obtained from the TLS server with a domain name using DNS;
289    the DNS information needs to be protected by DNSSEC.  Because the
290    certificate association was retrieved based on a DNS query, the
291    domain name in the query is by definition associated with the
292    certificate.  Note that this document does not cover how to associate
293    certificates with domain names for application protocols that depend
294    on SRV, NAPTR, and similar DNS resource records.  It is expected that
295    future documents will cover methods for making those associations,
296    and those documents may or may not need to update this one.
297
298    DNSSEC, which is defined in [RFC4033], [RFC4034], and [RFC4035], uses
299    cryptographic keys and digital signatures to provide authentication
300    of DNS data.  Information that is retrieved from the DNS and that is
301    validated using DNSSEC is thereby proved to be the authoritative
302    data.  The DNSSEC signature needs to be validated on all responses
303    that use DNSSEC in order to assure the proof of origin of the data.
304
305    This document does not specify how DNSSEC validation occurs because
306    there are many different proposals for how a client might get
307    validated DNSSEC results, such as from a DNSSEC-aware resolver that
308    is coded in the application, from a trusted DNSSEC resolver on the
309    machine on which the application is running, or from a trusted DNSSEC
310    resolver with which the application is communicating over an
311    authenticated and integrity-protected channel or network.  This is
312    described in more detail in Section 7 of [RFC4033].
313
314    This document only relates to getting the DNS information for the
315    certificate association securely using DNSSEC; other secure DNS
316    mechanisms are out of scope.
317
318 1.4.  Terminology
319
320    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
321    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
322    document are to be interpreted as described in RFC 2119 [RFC2119].
323
324    This document also makes use of standard PKIX, DNSSEC, TLS, and DNS
325    terminology.  See [RFC5280], [RFC4033], [RFC5246], and STD 13
326    [RFC1034] [RFC1035], respectively, for these terms.  In addition,
327    terms related to TLS-protected application services and DNS names are
328    taken from [RFC6125].
329
330
331
332
333
334
335
336
337
338 Hoffman & Schlyter           Standards Track                    [Page 6]
339 \f
340 RFC 6698            DNS-Based Authentication for TLS         August 2012
341
342
343 2.  The TLSA Resource Record
344
345    The TLSA DNS resource record (RR) is used to associate a TLS server
346    certificate or public key with the domain name where the record is
347    found, thus forming a "TLSA certificate association".  The semantics
348    of how the TLSA RR is interpreted are given later in this document.
349
350    The type value for the TLSA RR type is defined in Section 7.1.
351
352    The TLSA RR is class independent.
353
354    The TLSA RR has no special Time to Live (TTL) requirements.
355
356 2.1.  TLSA RDATA Wire Format
357
358    The RDATA for a TLSA RR consists of a one-octet certificate usage
359    field, a one-octet selector field, a one-octet matching type field,
360    and the certificate association data field.
361
362                         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
363     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
364    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
365    |  Cert. Usage  |   Selector    | Matching Type |               /
366    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               /
367    /                                                               /
368    /                 Certificate Association Data                  /
369    /                                                               /
370    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
371
372 2.1.1.  The Certificate Usage Field
373
374    A one-octet value, called "certificate usage", specifies the provided
375    association that will be used to match the certificate presented in
376    the TLS handshake.  This value is defined in a new IANA registry (see
377    Section 7.2) in order to make it easier to add additional certificate
378    usages in the future.  The certificate usages defined in this
379    document are:
380
381       0 -- Certificate usage 0 is used to specify a CA certificate, or
382       the public key of such a certificate, that MUST be found in any of
383       the PKIX certification paths for the end entity certificate given
384       by the server in TLS.  This certificate usage is sometimes
385       referred to as "CA constraint" because it limits which CA can be
386       used to issue certificates for a given service on a host.  The
387       presented certificate MUST pass PKIX certification path
388       validation, and a CA certificate that matches the TLSA record MUST
389       be included as part of a valid certification path.  Because this
390       certificate usage allows both trust anchors and CA certificates,
391
392
393
394 Hoffman & Schlyter           Standards Track                    [Page 7]
395 \f
396 RFC 6698            DNS-Based Authentication for TLS         August 2012
397
398
399       the certificate might or might not have the basicConstraints
400       extension present.
401
402       1 -- Certificate usage 1 is used to specify an end entity
403       certificate, or the public key of such a certificate, that MUST be
404       matched with the end entity certificate given by the server in
405       TLS.  This certificate usage is sometimes referred to as "service
406       certificate constraint" because it limits which end entity
407       certificate can be used by a given service on a host.  The target
408       certificate MUST pass PKIX certification path validation and MUST
409       match the TLSA record.
410
411       2 -- Certificate usage 2 is used to specify a certificate, or the
412       public key of such a certificate, that MUST be used as the trust
413       anchor when validating the end entity certificate given by the
414       server in TLS.  This certificate usage is sometimes referred to as
415       "trust anchor assertion" and allows a domain name administrator to
416       specify a new trust anchor -- for example, if the domain issues
417       its own certificates under its own CA that is not expected to be
418       in the end users' collection of trust anchors.  The target
419       certificate MUST pass PKIX certification path validation, with any
420       certificate matching the TLSA record considered to be a trust
421       anchor for this certification path validation.
422
423       3 -- Certificate usage 3 is used to specify a certificate, or the
424       public key of such a certificate, that MUST match the end entity
425       certificate given by the server in TLS.  This certificate usage is
426       sometimes referred to as "domain-issued certificate" because it
427       allows for a domain name administrator to issue certificates for a
428       domain without involving a third-party CA.  The target certificate
429       MUST match the TLSA record.  The difference between certificate
430       usage 1 and certificate usage 3 is that certificate usage 1
431       requires that the certificate pass PKIX validation, but PKIX
432       validation is not tested for certificate usage 3.
433
434    The certificate usages defined in this document explicitly only apply
435    to PKIX-formatted certificates in DER encoding [X.690].  If TLS
436    allows other formats later, or if extensions to this RRtype are made
437    that accept other formats for certificates, those certificates will
438    need their own certificate usage values.
439
440 2.1.2.  The Selector Field
441
442    A one-octet value, called "selector", specifies which part of the TLS
443    certificate presented by the server will be matched against the
444    association data.  This value is defined in a new IANA registry (see
445    Section 7.3).  The selectors defined in this document are:
446
447
448
449
450 Hoffman & Schlyter           Standards Track                    [Page 8]
451 \f
452 RFC 6698            DNS-Based Authentication for TLS         August 2012
453
454
455       0 -- Full certificate: the Certificate binary structure as defined
456       in [RFC5280]
457
458       1 -- SubjectPublicKeyInfo: DER-encoded binary structure as defined
459       in [RFC5280]
460
461    (Note that the use of "selector" in this document is completely
462    unrelated to the use of "selector" in DomainKeys Identified Mail
463    (DKIM) [RFC6376].)
464
465 2.1.3.  The Matching Type Field
466
467    A one-octet value, called "matching type", specifies how the
468    certificate association is presented.  This value is defined in a new
469    IANA registry (see Section 7.4).  The types defined in this document
470    are:
471
472       0 -- Exact match on selected content
473
474       1 -- SHA-256 hash of selected content [RFC6234]
475
476       2 -- SHA-512 hash of selected content [RFC6234]
477
478    If the TLSA record's matching type is a hash, having the record use
479    the same hash algorithm that was used in the signature in the
480    certificate (if possible) will assist clients that support a small
481    number of hash algorithms.
482
483 2.1.4.  The Certificate Association Data Field
484
485    This field specifies the "certificate association data" to be
486    matched.  These bytes are either raw data (that is, the full
487    certificate or its SubjectPublicKeyInfo, depending on the selector)
488    for matching type 0, or the hash of the raw data for matching types 1
489    and 2.  The data refers to the certificate in the association, not to
490    the TLS ASN.1 Certificate object.
491
492 2.2.  TLSA RR Presentation Format
493
494    The presentation format of the RDATA portion (as defined in
495    [RFC1035]) is as follows:
496
497    o  The certificate usage field MUST be represented as an 8-bit
498       unsigned integer.
499
500    o  The selector field MUST be represented as an 8-bit unsigned
501       integer.
502
503
504
505
506 Hoffman & Schlyter           Standards Track                    [Page 9]
507 \f
508 RFC 6698            DNS-Based Authentication for TLS         August 2012
509
510
511    o  The matching type field MUST be represented as an 8-bit unsigned
512       integer.
513
514    o  The certificate association data field MUST be represented as a
515       string of hexadecimal characters.  Whitespace is allowed within
516       the string of hexadecimal characters, as described in [RFC1035].
517
518 2.3.  TLSA RR Examples
519
520    In the following examples, the domain name is formed using the rules
521    in Section 3.
522
523    An example of a hashed (SHA-256) association of a PKIX CA
524    certificate:
525
526    _443._tcp.www.example.com. IN TLSA (
527       0 0 1 d2abde240d7cd3ee6b4b28c54df034b9
528             7983a1d16e8a410e4561cb106618e971 )
529
530    An example of a hashed (SHA-512) subject public key association of a
531    PKIX end entity certificate:
532
533    _443._tcp.www.example.com. IN TLSA (
534       1 1 2 92003ba34942dc74152e2f2c408d29ec
535             a5a520e7f2e06bb944f4dca346baf63c
536             1b177615d466f6c4b71c216a50292bd5
537             8c9ebdd2f74e38fe51ffd48c43326cbc )
538
539    An example of a full certificate association of a PKIX end entity
540    certificate:
541
542    _443._tcp.www.example.com. IN TLSA (
543       3 0 0 30820307308201efa003020102020... )
544
545 3.  Domain Names for TLSA Certificate Associations
546
547    Unless there is a protocol-specific specification that is different
548    than this one, TLSA resource records are stored at a prefixed DNS
549    domain name.  The prefix is prepared in the following manner:
550
551    1.  The decimal representation of the port number on which a TLS-
552        based service is assumed to exist is prepended with an underscore
553        character ("_") to become the left-most label in the prepared
554        domain name.  This number has no leading zeros.
555
556
557
558
559
560
561
562 Hoffman & Schlyter           Standards Track                   [Page 10]
563 \f
564 RFC 6698            DNS-Based Authentication for TLS         August 2012
565
566
567    2.  The protocol name of the transport on which a TLS-based service
568        is assumed to exist is prepended with an underscore character
569        ("_") to become the second left-most label in the prepared domain
570        name.  The transport names defined for this protocol are "tcp",
571        "udp", and "sctp".
572
573    3.  The base domain name is appended to the result of step 2 to
574        complete the prepared domain name.  The base domain name is the
575        fully qualified DNS domain name [RFC1035] of the TLS server, with
576        the additional restriction that every label MUST meet the rules
577        of [RFC0952].  The latter restriction means that, if the query is
578        for an internationalized domain name, it MUST use the A-label
579        form as defined in [RFC5890].
580
581    For example, to request a TLSA resource record for an HTTP server
582    running TLS on port 443 at "www.example.com",
583    "_443._tcp.www.example.com" is used in the request.  To request a
584    TLSA resource record for an SMTP server running the STARTTLS protocol
585    on port 25 at "mail.example.com", "_25._tcp.mail.example.com" is
586    used.
587
588 4.  Use of TLSA Records in TLS
589
590    Section 2.1 of this document defines the mandatory matching rules for
591    the data from the TLSA certificate associations and the certificates
592    received from the TLS server.
593
594    The TLS session that is to be set up MUST be for the specific port
595    number and transport name that was given in the TLSA query.
596
597    Some specifications for applications that run over TLS, such as
598    [RFC2818] for HTTP, require that the server's certificate have a
599    domain name that matches the host name expected by the client.  Some
600    specifications, such as [RFC6125], detail how to match the identity
601    given in a PKIX certificate with those expected by the user.
602
603    If a TLSA record has certificate usage 2, the corresponding TLS
604    server SHOULD send the certificate that is referenced just like it
605    currently sends intermediate certificates.
606
607 4.1.  Usable Certificate Associations
608
609    An implementation of this protocol makes a DNS query for TLSA
610    records, validates these records using DNSSEC, and uses the resulting
611    TLSA records and validation status to modify its responses to the TLS
612    server.
613
614
615
616
617
618 Hoffman & Schlyter           Standards Track                   [Page 11]
619 \f
620 RFC 6698            DNS-Based Authentication for TLS         August 2012
621
622
623    Determining whether a TLSA RRSet can be used MUST be based on the
624    DNSSEC validation state (as defined in [RFC4033]).
625
626    o  A TLSA RRSet whose DNSSEC validation state is secure MUST be used
627       as a certificate association for TLS unless a local policy would
628       prohibit the use of the specific certificate association in the
629       secure TLSA RRSet.
630
631    o  If the DNSSEC validation state on the response to the request for
632       the TLSA RRSet is bogus, this MUST cause TLS not to be started or,
633       if the TLS negotiation is already in progress, MUST cause the
634       connection to be aborted.
635
636    o  A TLSA RRSet whose DNSSEC validation state is indeterminate or
637       insecure cannot be used for TLS and MUST be considered unusable.
638
639    Clients that validate the DNSSEC signatures themselves MUST use
640    standard DNSSEC validation procedures.  Clients that rely on another
641    entity to perform the DNSSEC signature validation MUST use a secure
642    mechanism between themselves and the validator.  Examples of secure
643    transports to other hosts include TSIG [RFC2845], SIG(0) [RFC2931],
644    and IPsec [RFC6071].  Note that it is not sufficient to use secure
645    transport to a DNS resolver that does not do DNSSEC signature
646    validation.  See Section 8.3 for more security considerations related
647    to external validators.
648
649    If a certificate association contains a certificate usage, selector,
650    or matching type that is not understood by the TLS client, that
651    certificate association MUST be considered unusable.  If the
652    comparison data for a certificate is malformed, the certificate
653    association MUST be considered unusable.
654
655    If a certificate association contains a matching type or certificate
656    association data that uses a cryptographic algorithm that is
657    considered too weak for the TLS client's policy, the certificate
658    association MUST be considered unusable.
659
660    If an application receives zero usable certificate associations from
661    a DNS request or from its cache, it processes TLS in the normal
662    fashion without any input from the TLSA records.  If an application
663    receives one or more usable certificate associations, it attempts to
664    match each certificate association with the TLS server's end entity
665    certificate until a successful match is found.  During the TLS
666    handshake, if none of the certificate associations matches the
667    certificate given by the TLS server, the TLS client MUST abort the
668    handshake.
669
670
671
672
673
674 Hoffman & Schlyter           Standards Track                   [Page 12]
675 \f
676 RFC 6698            DNS-Based Authentication for TLS         August 2012
677
678
679    An attacker who is able to divert a user to a server under his
680    control is also likely to be able to block DNS requests from the user
681    or DNS responses being sent to the user.  Thus, in order to achieve
682    any security benefit from certificate usage 0 or 1, an application
683    that sends a request for TLSA records needs to get either a valid
684    signed response containing TLSA records or verification that the
685    domain is insecure or indeterminate.  If a request for a TLSA record
686    does not meet one of those two criteria but the application continues
687    with the TLS handshake anyway, the application has gotten no benefit
688    from TLSA and SHOULD NOT make any internal or external indication
689    that TLSA was applied.  If an application has a configuration setting
690    that has turned on TLSA use, or has any indication that TLSA is in
691    use (regardless of whether or not this is configurable), that
692    application either MUST NOT start a TLS connection or it MUST abort a
693    TLS handshake if both of the two criteria above are not met.
694
695    The application can perform the TLSA lookup before initiating the TLS
696    handshake, or do it during the TLS handshake: the choice is up to the
697    client.
698
699 5.  TLSA and DANE Use Cases and Requirements
700
701    The different types of certificate associations defined in TLSA are
702    matched with various sections of [RFC6394].  The use cases from
703    Section 3 of [RFC6394] are covered in this document as follows:
704
705    3.1 CA Constraints -- Implemented using certificate usage 0.
706
707    3.2 Certificate Constraints -- Implemented using certificate usage 1.
708
709    3.3 Trust Anchor Assertion and Domain-Issued Certificates --
710       Implemented using certificate usages 2 and 3, respectively.
711
712    The requirements from Section 4 of [RFC6394] are covered in this
713    document as follows:
714
715    Multiple Ports -- The TLSA records for different application services
716       running on a single host can be distinguished through the service
717       name and port number prefixed to the host name (see Section 3).
718
719    No Downgrade -- Section 4 specifies the conditions under which a
720       client can process and act upon TLSA records.  Specifically, if
721       the DNSSEC status for the TLSA resource record set is determined
722       to be bogus, the TLS connection (if started) will fail.
723
724    Encapsulation -- Encapsulation is covered in the TLSA response
725       semantics.
726
727
728
729
730 Hoffman & Schlyter           Standards Track                   [Page 13]
731 \f
732 RFC 6698            DNS-Based Authentication for TLS         August 2012
733
734
735    Predictability -- The appendices of this specification provide
736       operational considerations and implementation guidance in order to
737       enable application developers to form a consistent interpretation
738       of the recommended client behavior.
739
740    Opportunistic Security -- If a client conformant to this
741       specification can reliably determine the presence of a TLSA
742       record, it will attempt to use this information.  Conversely, if a
743       client can reliably determine the absence of any TLSA record, it
744       will fall back to processing TLS in the normal fashion.  This is
745       discussed in Section 4.
746
747    Combination -- Multiple TLSA records can be published for a given
748       host name, thus enabling the client to construct multiple TLSA
749       certificate associations that reflect different assertions.  No
750       support is provided to combine two TLSA certificate associations
751       in a single operation.
752
753    Roll-over -- TLSA records are processed in the normal manner within
754       the scope of the DNS protocol, including the TTL expiration of the
755       records.  This ensures that clients will not latch onto assertions
756       made by expired TLSA records, and will be able to transition from
757       using one public key or certificate usage to another.
758
759    Simple Key Management -- The SubjectPublicKeyInfo selector in the
760       TLSA record provides a mode that enables a domain holder to only
761       have to maintain a single long-lived public/private key pair
762       without the need to manage certificates.  Appendix A outlines the
763       usefulness and the potential downsides to using this mode.
764
765    Minimal Dependencies -- This specification relies on DNSSEC to
766       protect the origin authenticity and integrity of the TLSA resource
767       record set.  Additionally, if DNSSEC validation is not performed
768       on the system that wishes to use TLSA certificate bindings, this
769       specification requires that the "last mile" be over a secure
770       transport.  There are no other deployment dependencies for this
771       approach.
772
773    Minimal Options -- The operating modes map precisely to the DANE use
774       cases and requirements.  DNSSEC use is mandatory in that this
775       specification encourages applications to use only those TLSA
776       records that are shown to be validated.
777
778    Wildcards -- Wildcards are covered in a limited manner in the TLSA
779       request syntax; see Appendix A.
780
781    Redirection -- Redirection is covered in the TLSA request syntax; see
782       Appendix A.
783
784
785
786 Hoffman & Schlyter           Standards Track                   [Page 14]
787 \f
788 RFC 6698            DNS-Based Authentication for TLS         August 2012
789
790
791 6.  Mandatory-to-Implement Features
792
793    TLS clients conforming to this specification MUST be able to
794    correctly interpret TLSA records with certificate usages 0, 1, 2,
795    and 3.  TLS clients conforming to this specification MUST be able to
796    compare a certificate association with a certificate from the TLS
797    handshake using selector types 0 and 1, and matching type 0 (no hash
798    used) and matching type 1 (SHA-256), and SHOULD be able to make such
799    comparisons with matching type 2 (SHA-512).
800
801 7.  IANA Considerations
802
803    IANA has made the assignments in this section.
804
805    In the following sections, "RFC Required" was chosen for TLSA
806    certificate usages and "Specification Required" for selectors and
807    matching types because of the amount of detail that is likely to be
808    needed for implementers to correctly implement new certificate usages
809    as compared to new selectors and matching types.
810
811 7.1.  TLSA RRtype
812
813    This document uses a new DNS RR type, TLSA, whose value (52) was
814    allocated by IANA from the Resource Record (RR) TYPEs subregistry of
815    the Domain Name System (DNS) Parameters registry.
816
817 7.2.  TLSA Certificate Usages
818
819    This document creates a new registry, "TLSA Certificate Usages".  The
820    registry policy is "RFC Required".  The initial entries in the
821    registry are:
822
823    Value    Short description                       Reference
824    ----------------------------------------------------------
825    0        CA constraint                           RFC 6698
826    1        Service certificate constraint          RFC 6698
827    2        Trust anchor assertion                  RFC 6698
828    3        Domain-issued certificate               RFC 6698
829    4-254    Unassigned
830    255      Private use
831
832    Applications to the registry can request specific values that have
833    yet to be assigned.
834
835
836
837
838
839
840
841
842 Hoffman & Schlyter           Standards Track                   [Page 15]
843 \f
844 RFC 6698            DNS-Based Authentication for TLS         August 2012
845
846
847 7.3.  TLSA Selectors
848
849    This document creates a new registry, "TLSA Selectors".  The registry
850    policy is "Specification Required".  The initial entries in the
851    registry are:
852
853    Value    Short description                       Reference
854    ----------------------------------------------------------
855    0        Full certificate                        RFC 6698
856    1        SubjectPublicKeyInfo                    RFC 6698
857    2-254    Unassigned
858    255      Private use
859
860    Applications to the registry can request specific values that have
861    yet to be assigned.
862
863 7.4.  TLSA Matching Types
864
865    This document creates a new registry, "TLSA Matching Types".  The
866    registry policy is "Specification Required".  The initial entries in
867    the registry are:
868
869    Value    Short description                       Reference
870    ----------------------------------------------------------
871    0        No hash used                            RFC 6698
872    1        SHA-256                                 RFC 6234
873    2        SHA-512                                 RFC 6234
874    3-254    Unassigned
875    255      Private use
876
877    Applications to the registry can request specific values that have
878    yet to be assigned.
879
880 8.  Security Considerations
881
882    The security of the DNS RRtype described in this document relies on
883    the security of DNSSEC to verify that the TLSA record has not been
884    altered.
885
886    A rogue DNS administrator who changes the A, AAAA, and/or TLSA
887    records for a domain name can cause the client to go to an
888    unauthorized server that will appear authorized, unless the client
889    performs PKIX certification path validation and rejects the
890    certificate.  That administrator could probably get a certificate
891    issued by some CA anyway, so this is not an additional threat.
892
893
894
895
896
897
898 Hoffman & Schlyter           Standards Track                   [Page 16]
899 \f
900 RFC 6698            DNS-Based Authentication for TLS         August 2012
901
902
903    If the authentication mechanism for adding or changing TLSA data in a
904    zone is weaker than the authentication mechanism for changing the A
905    and/or AAAA records, a man-in-the-middle who can redirect traffic to
906    his site may be able to impersonate the attacked host in TLS if he
907    can use the weaker authentication mechanism.  A better design for
908    authenticating DNS would be to have the same level of authentication
909    used for all DNS additions and changes for a particular domain name.
910
911    Secure Socket Layer (SSL) proxies can sometimes act as a man-in-the-
912    middle for TLS clients.  In these scenarios, the clients add a new
913    trust anchor whose private key is kept on the SSL proxy; the proxy
914    intercepts TLS requests, creates a new TLS session with the intended
915    host, and sets up a TLS session with the client using a certificate
916    that chains to the trust anchor installed in the client by the proxy.
917    In such environments, using TLSA records will prevent the SSL proxy
918    from functioning as expected because the TLS client will get a
919    certificate association from the DNS that will not match the
920    certificate that the SSL proxy uses with the client.  The client,
921    seeing the proxy's new certificate for the supposed destination, will
922    not set up a TLS session.
923
924    Client treatment of any information included in the trust anchor is a
925    matter of local policy.  This specification does not mandate that
926    such information be inspected or validated by the server's domain
927    name administrator.
928
929    If a server's certificate is revoked, or if an intermediate CA in a
930    chain between the server and a trust anchor has its certificate
931    revoked, a TLSA record with a certificate usage of 2 that matches the
932    revoked certificate would in essence override the revocation because
933    the client would treat that revoked certificate as a trust anchor and
934    thus not check its revocation status.  Because of this, domain
935    administrators need to be responsible for being sure that the keys or
936    certificates used in TLSA records with a certificate usage of 2 are
937    in fact able to be used as reliable trust anchors.
938
939    Certificates that are delivered in TLSA with certificate usage 2
940    fundamentally change the way the TLS server's end entity certificate
941    is evaluated.  For example, the server's certificate might chain to
942    an existing CA through an intermediate CA that has certain policy
943    restrictions, and the certificate would not pass those restrictions
944    and thus normally be rejected.  That intermediate CA could issue
945    itself a new certificate without the policy restrictions and tell its
946    customers to use that certificate with certificate usage 2.  This in
947    essence allows an intermediate CA to become a trust anchor for
948    certificates that the end user might have expected to chain to an
949    existing trust anchor.
950
951
952
953
954 Hoffman & Schlyter           Standards Track                   [Page 17]
955 \f
956 RFC 6698            DNS-Based Authentication for TLS         August 2012
957
958
959    If an administrator wishes to stop using a TLSA record, the
960    administrator can simply remove it from the DNS.  Normal clients will
961    stop using the TLSA record after the TTL has expired.  Replay attacks
962    against the TLSA record are not possible after the expiration date on
963    the RRsig of the TLSA record that was removed.
964
965    Generators of TLSA records should be aware that the client's full
966    trust of a certificate association retrieved from a TLSA record may
967    be a matter of local policy.  While such trust is limited to the
968    specific domain name, protocol, and port for which the TLSA query was
969    made, local policy may decline to accept the certificate (for reasons
970    such as weak cryptography), as is also the case with PKIX trust
971    anchors.
972
973 8.1.  Comparing DANE to Public CAs
974
975    As stated above, the security of the DNS RRtype described in this
976    document relies on the security of DNSSEC to verify that the TLSA
977    record has not been altered.  This section describes where the
978    security of public CAs and the security of TLSA are similar and
979    different.  This section applies equally to other security-related
980    DNS RRtypes such as keys for IPsec and SSH.
981
982    DNSSEC forms certificates (the binding of an identity to a key) by
983    combining a DNSKEY, DS, or DLV resource record with an associated
984    RRSIG record.  These records then form a signing chain extending from
985    the client's trust anchors to the RR of interest.
986
987    Although the DNSSEC protocol does not enforce it, DNSKEYs are often
988    marked with a SEP flag indicating whether the key is a Zone Signing
989    Key (ZSK) or a Key Signing Key (KSK).  ZSKs protect records in the
990    zone (including DS and DLV records), and KSKs protect ZSK DNSKEY
991    records.  This allows KSKs to be stored offline.
992
993    The TLSA RRtype allows keys from the DNSSEC PKI hierarchy to
994    authenticate keys wrapped in PKIX certificates for a particular host
995    name, protocol, and port.
996
997    With the exception of the DLV RRtype, all of these certificates
998    constrain the keys they identify to names that are within the zone
999    signing the certificate.  In order for a domain's DLV resource
1000    records to be honored, the domain must be configured as a DLV domain,
1001    and the domain's DNSKEYs must be configured as trust anchors or be
1002    authentic [RFC5074].
1003
1004
1005
1006
1007
1008
1009
1010 Hoffman & Schlyter           Standards Track                   [Page 18]
1011 \f
1012 RFC 6698            DNS-Based Authentication for TLS         August 2012
1013
1014
1015 8.1.1.  Risk of Key Compromise
1016
1017    The risk that a given certificate that has a valid signing chain is
1018    fake is related to the number of keys that can contribute to the
1019    validation of the certificate, the quality of protection each private
1020    key receives, the value of each key to an attacker, and the value of
1021    falsifying the certificate.
1022
1023    DNSSEC allows any set of domains to be configured as trust anchors
1024    and/or DLVs, but most clients are likely to use the root zone as
1025    their only trust anchor.  Also, because a given DNSKEY can only sign
1026    resource records for that zone, the number of private keys capable of
1027    compromising a given TLSA resource record is limited to the number of
1028    zones between the TLSA resource record and the nearest trust anchor,
1029    plus any configured DLV domains.  Typically, this will be six keys,
1030    half of which will be KSKs.
1031
1032    PKIX only describes how to validate a certificate based on a client-
1033    chosen set of trust anchors, but says nothing about how many trust
1034    anchors to use or how they should be constrained.  As currently
1035    deployed, most PKIX clients use a large number of trust anchors
1036    provided with the client or operating system software.  These trust
1037    anchors are selected carefully, but with a desire for broad
1038    interoperability.  The trust anchors and CA certificates for public
1039    CAs rarely have name constraints applied.
1040
1041    A combination of technical protections, process controls, and
1042    personnel experience contribute to the quality of security that keys
1043    receive.
1044
1045    o  The security surrounding DNSSEC DNSKEYs varies significantly.  The
1046       KSK/ZSK split allows the KSK to be stored offline and protected
1047       more carefully than the ZSK, but not all domains do so.  The
1048       security applied to a zone's DNSKEYs should be proportional to the
1049       value of the domain, but that is difficult to estimate.  For
1050       example, the root DNSKEY has protections and controls comparable
1051       to or exceeding those of public CAs.  On the other end of the
1052       spectrum, small domains might provide no more protection to their
1053       keys than they do to their other data.
1054
1055    o  The security surrounding public CAs also varies.  However, due to
1056       financial incentives and standards imposed by clients for
1057       acceptance into their trust anchor stores, CAs generally employ
1058       security experts and protect their keys carefully, though highly
1059       public compromises have occurred.
1060
1061
1062
1063
1064
1065
1066 Hoffman & Schlyter           Standards Track                   [Page 19]
1067 \f
1068 RFC 6698            DNS-Based Authentication for TLS         August 2012
1069
1070
1071 8.1.2.  Impact of Key Compromise
1072
1073    The impact of a key compromise differs significantly between the two
1074    models.
1075
1076    o  DNSKEYs are inherently limited in what they can sign, so a
1077       compromise of the DNSKEY for "example.com" provides no avenue of
1078       attack against "example.org".  Even the impact of a compromise of
1079       .com's DNSKEY, while considerable, would be limited to .com
1080       domains.  Only the compromise of the root DNSKEY would have the
1081       equivalent impact of an unconstrained public CA.
1082
1083    o  Public CAs are not typically constrained in what names they can
1084       sign, and therefore a compromise of even one CA allows the
1085       attacker to generate a certificate for any name in the DNS.  A
1086       domain holder can get a certificate from any willing CA, or even
1087       multiple CAs simultaneously, making it impossible for a client to
1088       determine whether the certificate it is validating is legitimate
1089       or fraudulent.
1090
1091    Because a TLSA certificate association is constrained to its
1092    associated name, protocol, and port, the PKIX certificate is
1093    similarly constrained, even if its public CAs signing the certificate
1094    (if any) are not.
1095
1096 8.1.3.  Detection of Key Compromise
1097
1098    If a key is compromised, rapid and reliable detection is important in
1099    order to limit the impact of the compromise.  In this regard, neither
1100    model prevents an attacker from near-invisibly attacking their
1101    victim, provided that the necessary keys are compromised.
1102
1103    If a public CA is compromised, only the victim will see the
1104    fraudulent certificate, as there is typically no publicly accessible
1105    directory of all the certificates issued by a CA that can be
1106    inspected.  DNS resource records are typically published publicly.
1107    However, the attacker could also allow the uncompromised records to
1108    be published to the Internet as usual but provide a compromised DNS
1109    view to the victim to achieve the same effect.
1110
1111 8.1.4.  Spoofing Hostnames
1112
1113    Some CAs implement technical controls to ensure that certificates are
1114    not issued to domains with names similar to domains that are popular
1115    and prone to attack.  Of course, an attacker can attempt to
1116    circumvent this restriction by finding a CA willing to issue the
1117    certificate anyway.  However, by using DNSSEC and TLSA, the attacker
1118    can circumvent this check completely.
1119
1120
1121
1122 Hoffman & Schlyter           Standards Track                   [Page 20]
1123 \f
1124 RFC 6698            DNS-Based Authentication for TLS         August 2012
1125
1126
1127 8.2.  DNS Caching
1128
1129    Implementations of this protocol rely heavily on the DNS, and are
1130    thus prone to security attacks based on the deliberate
1131    mis-association of TLSA records and DNS names.  Implementations need
1132    to be cautious in assuming the continuing validity of an association
1133    between a TLSA record and a DNS name.
1134
1135    In particular, implementations SHOULD rely on their DNS resolver for
1136    confirmation of an association between a TLSA record and a DNS name,
1137    rather than caching the result of previous domain name lookups.  Many
1138    platforms already can cache domain name lookups locally when
1139    appropriate, and they SHOULD be configured to do so.  It is proper
1140    for these lookups to be cached, however, only when the TTL (Time To
1141    Live) information reported by the DNS makes it likely that the cached
1142    information will remain useful.
1143
1144    If implementations cache the results of domain name lookups in order
1145    to achieve a performance improvement, they MUST observe the TTL
1146    information reported by DNS.  Implementations that fail to follow
1147    this rule could be spoofed or have access denied when a previously
1148    accessed server's TLSA record changes, such as during a certificate
1149    rollover.
1150
1151 8.3.  External DNSSEC Validators
1152
1153    Due to a lack of DNSSEC support in the most commonly deployed stub
1154    resolvers today, some ISPs have begun checking DNSSEC in the
1155    recursive resolvers they provide to their customers, setting the
1156    Authentic Data (AD) flag as appropriate.  DNSSEC-aware clients could
1157    use that data, ignoring the fact that the DNSSEC data has been
1158    validated externally.  Because there is typically no authentication
1159    of the recursive resolver or integrity protection of the data and AD
1160    flag between the client and the recursive resolver, this can be
1161    trivially spoofed by an attacker.
1162
1163    However, even with secure communications between a host and the
1164    external validating resolver, there is a risk that the external
1165    validator could become compromised.  Nothing prevents a compromised
1166    external DNSSEC validator from claiming that all the records it
1167    provides are secure, even if the data is falsified, unless the client
1168    checks the DNSSEC data itself (rendering the external validator
1169    unnecessary).
1170
1171    For this reason, DNSSEC validation is best performed on-host, even
1172    when a secure path to an external validator is available.
1173
1174
1175
1176
1177
1178 Hoffman & Schlyter           Standards Track                   [Page 21]
1179 \f
1180 RFC 6698            DNS-Based Authentication for TLS         August 2012
1181
1182
1183 9.  Acknowledgements
1184
1185    Many of the ideas in this document have been discussed over many
1186    years.  More recently, the ideas have been discussed by the authors
1187    and others in a more focused fashion.  In particular, some of the
1188    ideas and words here originated with Paul Vixie, Dan Kaminsky, Jeff
1189    Hodges, Phillip Hallam-Baker, Simon Josefsson, Warren Kumari, Adam
1190    Langley, Ben Laurie, Ilari Liusvaara, Ondrej Mikle, Scott Schmit,
1191    Ondrej Sury, Richard Barnes, Jim Schaad, Stephen Farrell, Suresh
1192    Krishnaswamy, Peter Palfrader, Pieter Lexis, Wouter Wijngaards, John
1193    Gilmore, and Murray Kucherawy.
1194
1195    This document has also been greatly helped by many active
1196    participants of the DANE Working Group.
1197
1198 10.  References
1199
1200 10.1.  Normative References
1201
1202    [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
1203               STD 13, RFC 1034, November 1987.
1204
1205    [RFC1035]  Mockapetris, P., "Domain names - implementation and
1206               specification", STD 13, RFC 1035, November 1987.
1207
1208    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
1209               Requirement Levels", BCP 14, RFC 2119, March 1997.
1210
1211    [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
1212               Rose, "DNS Security Introduction and Requirements",
1213               RFC 4033, March 2005.
1214
1215    [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
1216               Rose, "Resource Records for the DNS Security Extensions",
1217               RFC 4034, March 2005.
1218
1219    [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
1220               Rose, "Protocol Modifications for the DNS Security
1221               Extensions", RFC 4035, March 2005.
1222
1223    [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
1224               (TLS) Protocol Version 1.2", RFC 5246, August 2008.
1225
1226    [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
1227               Housley, R., and W. Polk, "Internet X.509 Public Key
1228               Infrastructure Certificate and Certificate Revocation List
1229               (CRL) Profile", RFC 5280, May 2008.
1230
1231
1232
1233
1234 Hoffman & Schlyter           Standards Track                   [Page 22]
1235 \f
1236 RFC 6698            DNS-Based Authentication for TLS         August 2012
1237
1238
1239    [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
1240               Verification of Domain-Based Application Service Identity
1241               within Internet Public Key Infrastructure Using X.509
1242               (PKIX) Certificates in the Context of Transport Layer
1243               Security (TLS)", RFC 6125, March 2011.
1244
1245    [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
1246               Security Version 1.2", RFC 6347, January 2012.
1247
1248 10.2.  Informative References
1249
1250    [RFC0952]  Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
1251               host table specification", RFC 952, October 1985.
1252
1253    [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
1254               specifying the location of services (DNS SRV)", RFC 2782,
1255               February 2000.
1256
1257    [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
1258
1259    [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
1260               Wellington, "Secret Key Transaction Authentication for DNS
1261               (TSIG)", RFC 2845, May 2000.
1262
1263    [RFC2931]  Eastlake 3rd, D., "DNS Request and Transaction Signatures
1264               ( SIG(0)s)", RFC 2931, September 2000.
1265
1266    [RFC4025]  Richardson, M., "A Method for Storing IPsec Keying
1267               Material in DNS", RFC 4025, March 2005.
1268
1269    [RFC4255]  Schlyter, J. and W. Griffin, "Using DNS to Securely
1270               Publish Secure Shell (SSH) Key Fingerprints", RFC 4255,
1271               January 2006.
1272
1273    [RFC4641]  Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
1274               RFC 4641, September 2006.
1275
1276    [RFC5074]  Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074,
1277               November 2007.
1278
1279    [RFC5890]  Klensin, J., "Internationalized Domain Names for
1280               Applications (IDNA): Definitions and Document Framework",
1281               RFC 5890, August 2010.
1282
1283    [RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)
1284               Extensions: Extension Definitions", RFC 6066,
1285               January 2011.
1286
1287
1288
1289
1290 Hoffman & Schlyter           Standards Track                   [Page 23]
1291 \f
1292 RFC 6698            DNS-Based Authentication for TLS         August 2012
1293
1294
1295    [RFC6071]  Frankel, S. and S. Krishnan, "IP Security (IPsec) and
1296               Internet Key Exchange (IKE) Document Roadmap", RFC 6071,
1297               February 2011.
1298
1299    [RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
1300               (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.
1301
1302    [RFC6376]  Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
1303               "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376,
1304               September 2011.
1305
1306    [RFC6394]  Barnes, R., "Use Cases and Requirements for DNS-Based
1307               Authentication of Named Entities (DANE)", RFC 6394,
1308               October 2011.
1309
1310    [X.690]    "Recommendation ITU-T X.690 (2002) | ISO/IEC 8825-1:2002,
1311               Information technology - ASN.1 encoding rules:
1312               Specification of Basic Encoding Rules (BER), Canonical
1313               Encoding Rules (CER) and Distinguished Encoding Rules
1314               (DER)", July 2002.
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346 Hoffman & Schlyter           Standards Track                   [Page 24]
1347 \f
1348 RFC 6698            DNS-Based Authentication for TLS         August 2012
1349
1350
1351 Appendix A.  Operational Considerations for Deploying TLSA Records
1352
1353 A.1.  Creating TLSA Records
1354
1355    When creating TLSA records, care must be taken to avoid
1356    misconfigurations.  Section 4 of this document states that a TLSA
1357    RRSet whose validation state is secure MUST be used.  This means that
1358    the existence of such a RRSet effectively disables other forms of
1359    name and path validation.  A misconfigured TLSA RRSet will
1360    effectively disable access to the TLS server for all conforming
1361    clients, and this document does not provide any means of making a
1362    gradual transition to using TLSA.
1363
1364    When creating TLSA records with certificate usage 0 (CA certificate)
1365    or usage 2 (trust anchor), one needs to understand the implications
1366    when choosing between selector type 0 (Full certificate) and 1
1367    (SubjectPublicKeyInfo).  A careful choice is required because
1368    different methods for building trust chains are used by different TLS
1369    clients.  The following outlines the cases that one ought to be aware
1370    of and discusses the implications of the choice of selector type.
1371
1372    Certificate usage 2 is not affected by the different types of chain
1373    building when the end entity certificate is the same as the trust
1374    anchor certificate.
1375
1376 A.1.1.  Ambiguities and Corner Cases When TLS Clients Build Trust Chains
1377
1378    TLS clients can implement their own chain-building code rather than
1379    rely on the chain presented by the TLS server.  This means that,
1380    except for the end entity certificate, any certificate presented in
1381    the suggested chain might or might not be present in the final chain
1382    built by the client.
1383
1384    Certificates that the client can use to replace certificates from the
1385    original chain include:
1386
1387    o  Client's trust anchors
1388
1389    o  Certificates cached locally
1390
1391    o  Certificates retrieved from a URI listed in an Authority
1392       Information Access X.509v3 extension
1393
1394    CAs frequently reissue certificates with different validity periods,
1395    signature algorithms (such as a different hash algorithm in the
1396    signature algorithm), CA key pairs (such as for a cross-certificate),
1397
1398
1399
1400
1401
1402 Hoffman & Schlyter           Standards Track                   [Page 25]
1403 \f
1404 RFC 6698            DNS-Based Authentication for TLS         August 2012
1405
1406
1407    or PKIX extensions where the public key and subject remain the same.
1408    These reissued certificates are the certificates that the TLS client
1409    can use in place of an original certificate.
1410
1411    Clients are known to exchange or remove certificates that could cause
1412    TLSA certificate associations that rely on the full certificate to
1413    fail.  For example:
1414
1415    o  The client considers the signature algorithm of a certificate to
1416       no longer be sufficiently secure.
1417
1418    o  The client might not have an associated root certificate in its
1419       trust store and instead uses a cross-certificate with an identical
1420       subject and public key.
1421
1422 A.1.2.  Choosing a Selector Type
1423
1424    In this section, "false-negative failure" means that a client will
1425    not accept the TLSA certificate association for a certificate
1426    designated by the DNS administrator.  Also, "false-positive
1427    acceptance" means that the client accepts a TLSA association for a
1428    certificate that is not designated by the DNS administrator.
1429
1430 A.1.2.1.  Selector Type 0 (Full Certificate)
1431
1432    The "Full certificate" selector provides the most precise
1433    specification of a TLSA certificate association, capturing all
1434    fields of the PKIX certificate.  For a DNS administrator, the best
1435    course to avoid false-negative failures in the client when using this
1436    selector is:
1437
1438    1.  If a CA issued a replacement certificate, don't associate to CA
1439        certificates that have a signature algorithm with a hash that is
1440        considered weak by local policy.
1441
1442    2.  Determine how common client applications process the TLSA
1443        certificate association using a fresh client installation -- that
1444        is, with the local certificate cache empty.
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458 Hoffman & Schlyter           Standards Track                   [Page 26]
1459 \f
1460 RFC 6698            DNS-Based Authentication for TLS         August 2012
1461
1462
1463 A.1.2.2.  Selector Type 1 (SubjectPublicKeyInfo)
1464
1465    A SubjectPublicKeyInfo selector gives greater flexibility in avoiding
1466    some false-negative failures caused by trust-chain-building
1467    algorithms used in clients.
1468
1469    One specific use case ought to be noted: creating a TLSA certificate
1470    association to CA certificate I1 that directly signed end entity
1471    certificate S1 of the server.  The case can be illustrated by the
1472    following graph:
1473
1474            +----+                      +----+
1475            | I1 |                      | I2 |
1476            +----+                      +----+
1477               |                           |
1478               v                           v
1479            +----+                      +----+
1480            | S1 |                      | S1 |
1481            +----+                      +----+
1482    Certificate chain sent by    A different validation path
1483    server in TLS handshake      built by the TLS client
1484
1485    I2 is a reissued version of CA certificate I1 (that is, it has a
1486    different hash in its signature algorithm).
1487
1488    In the above scenario, both certificates I1 and I2 that sign S1 need
1489    to have identical SubjectPublicKeyInfo fields because the key used to
1490    sign S1 is fixed.  An association to SubjectPublicKeyInfo (selector
1491    type 1) will always succeed in such a case, but an association with a
1492    full certificate (selector type 0) might not work due to a false-
1493    negative failure.
1494
1495    The attack surface is a bit broader compared to the "Full
1496    certificate" selector: the DNS administrator might unintentionally
1497    specify an association that would lead to false-positive acceptance.
1498
1499    o  The administrator must know or trust that the CA does not engage
1500       in bad practices, such as not sharing the key of I1 for unrelated
1501       CA certificates (which would lead to trust-chain redirection).  If
1502       possible, the administrator ought to review all CA certificates
1503       that have the same SubjectPublicKeyInfo field.
1504
1505    o  The administrator ought to understand whether some PKIX extension
1506       may adversely affect security of the association.  If possible,
1507       administrators ought to review all CA certificates that share the
1508       SubjectPublicKeyInfo.
1509
1510
1511
1512
1513
1514 Hoffman & Schlyter           Standards Track                   [Page 27]
1515 \f
1516 RFC 6698            DNS-Based Authentication for TLS         August 2012
1517
1518
1519    o  The administrator ought to understand that any CA could, in the
1520       future, issue a certificate that contains the same
1521       SubjectPublicKeyInfo.  Therefore, new chains can crop up in the
1522       future without any warning.
1523
1524    Using the SubjectPublicKeyInfo selector for association with a
1525    certificate in a chain above I1 needs to be decided on a case-by-case
1526    basis: there are too many possibilities based on the issuing CA's
1527    practices.  Unless the full implications of such an association are
1528    understood by the administrator, using selector type 0 is a better
1529    option from a security perspective.
1530
1531 A.2.  Provisioning TLSA Records in DNS
1532
1533 A.2.1.  Provisioning TLSA Records with Aliases
1534
1535    The TLSA resource record is not special in the DNS; it acts exactly
1536    like any other RRtype where the queried name has one or more labels
1537    prefixed to the base name, such as the SRV RRtype [RFC2782].  This
1538    affects the way that the TLSA resource record is used when aliasing
1539    in the DNS.
1540
1541    Note that the IETF sometimes adds new types of aliasing in the DNS.
1542    If that happens in the future, those aliases might affect TLSA
1543    records, hopefully in a good way.
1544
1545 A.2.1.1.  Provisioning TLSA Records with CNAME Records
1546
1547    Using CNAME to alias in DNS only aliases from the exact name given,
1548    not any zones below the given name.  For example, assume that a zone
1549    file has only the following:
1550
1551    sub1.example.com.          IN CNAME sub2.example.com.
1552
1553    In this case, a request for the A record at "bottom.sub1.example.com"
1554    would not return any records because the CNAME given only aliases the
1555    name given.  Assume, instead, the zone file has the following:
1556
1557    sub3.example.com.          IN CNAME sub4.example.com.
1558    bottom.sub3.example.com.   IN CNAME bottom.sub4.example.com.
1559
1560    In this case, a request for the A record at bottom.sub3.example.com
1561    would in fact return whatever value for the A record exists at
1562    bottom.sub4.example.com.
1563
1564
1565
1566
1567
1568
1569
1570 Hoffman & Schlyter           Standards Track                   [Page 28]
1571 \f
1572 RFC 6698            DNS-Based Authentication for TLS         August 2012
1573
1574
1575    Application implementations and full-service resolvers request DNS
1576    records using libraries that automatically follow CNAME (and DNAME)
1577    aliasing.  This allows hosts to put TLSA records in their own zones
1578    or to use CNAME to do redirection.
1579
1580    If the owner of the original domain wants a TLSA record for the same,
1581    they simply enter it under the defined prefix:
1582
1583    ; No TLSA record in target domain
1584    ;
1585    sub5.example.com.            IN CNAME sub6.example.com.
1586    _443._tcp.sub5.example.com.  IN TLSA 1 1 1 308202c5308201ab...
1587    sub6.example.com.            IN A 192.0.2.1
1588    sub6.example.com.            IN AAAA 2001:db8::1
1589
1590    If the owner of the original domain wants to have the target domain
1591    host the TLSA record, the original domain uses a CNAME record:
1592
1593    ; TLSA record for original domain has CNAME to target domain
1594    ;
1595    sub5.example.com.            IN CNAME sub6.example.com.
1596    _443._tcp.sub5.example.com.  IN CNAME _443._tcp.sub6.example.com.
1597    sub6.example.com.            IN A 192.0.2.1
1598    sub6.example.com.            IN AAAA 2001:db8::1
1599    _443._tcp.sub6.example.com.  IN TLSA 1 1 1 536a570ac49d9ba4...
1600
1601    Note that it is acceptable for both the original domain and the
1602    target domain to have TLSA records, but the two records are
1603    unrelated.  Consider the following:
1604
1605    ; TLSA record in both the original and target domain
1606    ;
1607    sub5.example.com.            IN CNAME sub6.example.com.
1608    _443._tcp.sub5.example.com.  IN TLSA 1 1 1 308202c5308201ab...
1609    sub6.example.com.            IN A 192.0.2.1
1610    sub6.example.com.            IN AAAA 2001:db8::1
1611    _443._tcp.sub6.example.com.  IN TLSA 1 1 1 ac49d9ba4570ac49...
1612
1613    In this example, someone looking for the TLSA record for
1614    sub5.example.com would always get the record whose value starts with
1615    "308202c5308201ab"; the TLSA record whose value starts with
1616    "ac49d9ba4570ac49" would only be sought by someone who is looking for
1617    the TLSA record for sub6.example.com, and never for sub5.example.com.
1618    Note that deploying different certificates for multiple services
1619    located at a shared TLS listener often requires the use of TLS SNI
1620    (Server Name Indication) [RFC6066].
1621
1622
1623
1624
1625
1626 Hoffman & Schlyter           Standards Track                   [Page 29]
1627 \f
1628 RFC 6698            DNS-Based Authentication for TLS         August 2012
1629
1630
1631    Note that these methods use the normal method for DNS aliasing using
1632    CNAME: the DNS client requests the record type that they actually
1633    want.
1634
1635 A.2.1.2.  Provisioning TLSA Records with DNAME Records
1636
1637    Using DNAME records allows a zone owner to alias an entire subtree of
1638    names below the name that has the DNAME.  This allows the wholesale
1639    aliasing of prefixed records such as those used by TLSA, SRV, and so
1640    on without aliasing the name itself.  However, because DNAME can only
1641    be used for subtrees of a base name, it is rarely used to alias
1642    individual hosts that might also be running TLS.
1643
1644    ; TLSA record in target domain, visible in original domain via DNAME
1645    ;
1646    sub5.example.com.            IN CNAME sub6.example.com.
1647    _tcp.sub5.example.com.       IN DNAME _tcp.sub6.example.com.
1648    sub6.example.com.            IN A 192.0.2.1
1649    sub6.example.com.            IN AAAA 2001:db8::1
1650    _443._tcp.sub6.example.com.  IN TLSA 1 1 1 536a570ac49d9ba4...
1651
1652 A.2.1.3.  Provisioning TLSA Records with Wildcards
1653
1654    Wildcards are generally not terribly useful for RRtypes that require
1655    prefixing because one can only wildcard at a layer below the host
1656    name.  For example, if one wants to have the same TLSA record for
1657    every TCP port for www.example.com, the result might be:
1658
1659    *._tcp.www.example.com.    IN TLSA 1 1 1 5c1502a6549c423b...
1660
1661    This is possibly useful in some scenarios where the same service is
1662    offered on many ports or the same certificate and/or key is used for
1663    all services on a host.  Note that the domain being searched for is
1664    not necessarily related to the domain name found in the certificate,
1665    so a certificate with a wildcard in it is not searched for using a
1666    wildcard in the search request.
1667
1668 A.3.  Securing the Last Hop
1669
1670    As described in Section 4, an application processing TLSA records
1671    must know the DNSSEC validity of those records.  There are many ways
1672    for the application to determine this securely, and this
1673    specification does not mandate any single method.
1674
1675
1676
1677
1678
1679
1680
1681
1682 Hoffman & Schlyter           Standards Track                   [Page 30]
1683 \f
1684 RFC 6698            DNS-Based Authentication for TLS         August 2012
1685
1686
1687    Some common methods for an application to know the DNSSEC validity of
1688    TLSA records include:
1689
1690    o  The application can have its own DNS resolver and DNSSEC
1691       validation stack.
1692
1693    o  The application can communicate through a trusted channel (such as
1694       requests to the operating system under which the application is
1695       running) to a local DNS resolver that does DNSSEC validation.
1696
1697    o  The application can communicate through a secured channel (such as
1698       requests running over TLS, IPsec, TSIG, or SIG(0)) to a non-local
1699       DNS resolver that does DNSSEC validation.
1700
1701    o  The application can communicate through a secured channel (such as
1702       requests running over TLS, IPsec, TSIG, or SIG(0)) to a non-local
1703       DNS resolver that does not do DNSSEC validation, but gets
1704       responses through a secured channel from a different DNS resolver
1705       that does DNSSEC validation.
1706
1707 A.4.  Handling Certificate Rollover
1708
1709    Certificate rollover is handled in much the same way as for rolling
1710    DNSSEC zone signing keys using the pre-publish key rollover method
1711    [RFC4641].  Suppose example.com has a single TLSA record for a TLS
1712    service on TCP port 990:
1713
1714    _990._tcp.example.com IN TLSA 1 1 1 1CFC98A706BCF3683015...
1715
1716    To start the rollover process, obtain or generate the new certificate
1717    or SubjectPublicKeyInfo to be used after the rollover and generate
1718    the new TLSA record.  Add that record alongside the old one:
1719
1720    _990._tcp.example.com IN TLSA 1 1 1 1CFC98A706BCF3683015...
1721    _990._tcp.example.com IN TLSA 1 1 1 62D5414CD1CC657E3D30...
1722
1723    After the new records have propagated to the authoritative
1724    nameservers and the TTL of the old record has expired, switch to the
1725    new certificate on the TLS server.  Once this has occurred, the old
1726    TLSA record can be removed:
1727
1728    _990._tcp.example.com IN TLSA 1 1 1 62D5414CD1CC657E3D30...
1729
1730    This completes the certificate rollover.
1731
1732
1733
1734
1735
1736
1737
1738 Hoffman & Schlyter           Standards Track                   [Page 31]
1739 \f
1740 RFC 6698            DNS-Based Authentication for TLS         August 2012
1741
1742
1743 Appendix B.  Pseudocode for Using TLSA
1744
1745    This appendix describes, in pseudocode format, the interactions given
1746    earlier in this specification.  If the steps below disagree with the
1747    text earlier in the document, the steps earlier in the document ought
1748    to be considered correct and this text incorrect.
1749
1750    Note that this pseudocode is more strict than the normative text.
1751    For instance, it forces an order on the evaluation of criteria, which
1752    is not mandatory from the normative text.
1753
1754 B.1.  Helper Functions
1755
1756    // implement the function for exiting
1757    function Finish (F) = {
1758      if (F == ABORT_TLS) {
1759        abort the TLS handshake or prevent TLS from starting
1760        exit
1761      }
1762
1763      if (F == NO_TLSA) {
1764        fall back to non-TLSA certificate validation
1765        exit
1766      }
1767
1768      if (F == ACCEPT) {
1769        accept the TLS connection
1770        exit
1771      }
1772
1773      // unreachable
1774    }
1775
1776    // implement the selector function
1777    function Select (S, X) = {
1778      // Full certificate
1779      if (S == 0) {
1780        return X in DER encoding
1781      }
1782
1783      // SubjectPublicKeyInfo
1784      if (S == 1) {
1785        return X.SubjectPublicKeyInfo in DER encoding
1786      }
1787
1788      // unreachable
1789    }
1790
1791
1792
1793
1794 Hoffman & Schlyter           Standards Track                   [Page 32]
1795 \f
1796 RFC 6698            DNS-Based Authentication for TLS         August 2012
1797
1798
1799    // implement the matching function
1800    function Match (M, X, Y) {
1801      // Exact match on selected content
1802      if (M == 0) {
1803        return (X == Y)
1804      }
1805
1806      // SHA-256 hash of selected content
1807      if (M == 1) {
1808        return (SHA-256(X) == Y)
1809      }
1810
1811      // SHA-512 hash of selected content
1812      if (M == 2) {
1813        return (SHA-512(X) == Y)
1814      }
1815
1816      // unreachable
1817    }
1818
1819 B.2.  Main TLSA Pseudocode
1820
1821    TLS connect using [transport] to [name] on [port] and receiving end
1822    entity cert C for the TLS server:
1823
1824    (TLSArecords, ValState) = DNSSECValidatedLookup(
1825      domainname=_[port]._[transport].[name], RRtype=TLSA)
1826
1827    // check for states that would change processing
1828    if (ValState == BOGUS) {
1829      Finish(ABORT_TLS)
1830    }
1831    if ((ValState == INDETERMINATE) or (ValState == INSECURE)) {
1832      Finish(NO_TLSA)
1833    }
1834    // if here, ValState must be SECURE
1835
1836    for each R in TLSArecords {
1837      // unusable records include unknown certUsage, unknown
1838      // selectorType, unknown matchingType, erroneous RDATA, and
1839      // prohibited by local policy
1840      if (R is unusable) {
1841        remove R from TLSArecords
1842      }
1843    }
1844    if (length(TLSArecords) == 0) {
1845      Finish(NO_TLSA)
1846    }
1847
1848
1849
1850 Hoffman & Schlyter           Standards Track                   [Page 33]
1851 \f
1852 RFC 6698            DNS-Based Authentication for TLS         August 2012
1853
1854
1855    // A TLS client might have multiple trust anchors that it might use
1856    //    when validating the TLS server's end entity (EE) certificate.
1857    //    Also, there can be multiple PKIX certification paths for the
1858    //    certificates given by the server in TLS.  Thus, there are
1859    //    possibly many chains that might need to be tested during
1860    //    PKIX path validation.
1861
1862    for each R in TLSArecords {
1863
1864      // pass PKIX certificate validation and chain through a CA cert
1865      //    that comes from TLSA
1866      if (R.certUsage == 0) {
1867        for each PKIX certification path H {
1868          if (C passes PKIX certification path validation in H) {
1869            for each D in H {
1870              if ((D is a CA certificate) and
1871                  Match(R.matchingType, Select(R.selectorType, D),
1872                        R.cert)) {
1873                Finish(ACCEPT)
1874              }
1875            }
1876          }
1877        }
1878      }
1879
1880      // pass PKIX certificate validation and match EE cert from TLSA
1881      if (R.certUsage == 1) {
1882        for each PKIX certification path H {
1883          if ((C passes PKIX certificate validation in H) and
1884                  Match(R.matchingType, Select(R.selectorType, C),
1885                  R.cert)) {
1886              Finish(ACCEPT)
1887          }
1888        }
1889      }
1890
1891      // pass PKIX certification validation using TLSA record as the
1892      //    trust anchor
1893      if (R.certUsage == 2) {
1894        // the following assert() is merely a formalization of the
1895        // "trust anchor" condition for a certificate D matching R
1896        assert(Match(R.matchingType, Select(R.selectorType, D), R.cert))
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906 Hoffman & Schlyter           Standards Track                   [Page 34]
1907 \f
1908 RFC 6698            DNS-Based Authentication for TLS         August 2012
1909
1910
1911        for each PKIX certification path H that has certificate D
1912            matching R as the trust anchor {
1913          if (C passes PKIX validation in H) {
1914            Finish(ACCEPT);
1915          }
1916        }
1917      }
1918
1919      // match the TLSA record and the TLS certificate
1920      if (R.certUsage == 3) {
1921        if Match(R.matchingType, Select(R.selectorType, C), R.cert)
1922          Finish(ACCEPT)
1923        }
1924      }
1925
1926    }
1927
1928    // if here, then none of the TLSA records ended in "Finish(ACCEPT)"
1929    //   so abort TLS
1930    Finish(ABORT_TLS)
1931
1932 Appendix C.  Examples
1933
1934    The following are examples of self-signed certificates that have been
1935    generated with various selectors and matching types.  They were
1936    generated with one piece of software, and validated by an individual
1937    using other tools.
1938
1939    S = Selector
1940    M = Matching Type
1941
1942    S M Association Data
1943    0 0 30820454308202BC020900AB58D24E77AD2AF6300D06092A86
1944        4886F70D0101050500306C310B3009060355040613024E4C31163014
1945        0603550408130D4E6F6F72642D486F6C6C616E643112301006035504
1946        071309416D7374657264616D310C300A060355040A13034F53333123
1947        30210603550403131A64616E652E6B6965762E70726163746963756D
1948        2E6F73332E6E6C301E170D3132303131363136353730335A170D3232
1949        303131333136353730335A306C310B3009060355040613024E4C3116
1950        30140603550408130D4E6F6F72642D486F6C6C616E64311230100603
1951        5504071309416D7374657264616D310C300A060355040A13034F5333
1952        312330210603550403131A64616E652E6B6965762E70726163746963
1953        756D2E6F73332E6E6C308201A2300D06092A864886F70D0101010500
1954        0382018F003082018A0282018100E62C84A5AFE59F0A2A6B250DEE68
1955        7AC8C5C604F57D26CEB2119140FFAC38C4B9CBBE8923082E7F81626B
1956        6AD5DEA0C8771C74E3CAA7F613054AEFA3673E48FFE47B3F7AF987DE
1957        281A68230B24B9DA1A98DCBE51195B60E42FD7517C328D983E26A827
1958        C877AB914EE4C1BFDEAD48BD25BE5F2C473BA9C1CBBDDDA0C374D0D5
1959
1960
1961
1962 Hoffman & Schlyter           Standards Track                   [Page 35]
1963 \f
1964 RFC 6698            DNS-Based Authentication for TLS         August 2012
1965
1966
1967        8C389CC3D6D8C20662E19CF768F32441B7F7D14AEA8966CE7C32A172
1968        2AB38623D008029A9E4702883F8B977A1A1E5292BF8AD72239D40393
1969        37B86A3AC60FA001290452177BF1798609A05A130F033457A5212629
1970        FBDDB8E70E2A9E6556873C4F7CA46AE4A8B178F05FB319005E1C1C7D
1971        4BD77DFA34035563C126AA2C3328B900E7990AC9787F01DA82F74C3D
1972        4B6674CCECE1FD4C6EF9E6644F4635EDEDA39D8B0E2F7C8E06DAE775
1973        6213BD3D60831175BE290442B4AFC5AE6F46B769855A067C1097E617
1974        962529E166F22AEE10DDB981B8CD6FF17D3D70723169038DBFBC1A44
1975        9C8D0D31BC683C5F3CE26148E42EC9BBD4D9F261569B25B53C1D7FC2
1976        DDFF6B4CAC050203010001300D06092A864886F70D01010505000382
1977        0181002B2ABE063E9C86AC4A1F7835372091079C8276A9C2C5D1EC57
1978        64DE523FDDABDEAB3FD34E6FE6CBA054580A6785A663595D90132B93
1979        D473929E81FA0887D2FFF78A81C7D014B97778AB6AC9E5E690F6F5A9
1980        E92BB5FBAB71B857AE69B6E18BDCCB0BA6FCD9D4B084A34F3635148C
1981        495D48FE635903B888EC1DEB2610548EDD48D63F86513A4562469831
1982        48C0D5DB82D73A4C350A42BB661D763430FC6C8E5F9D13EA1B76AA52
1983        A4C358E5EA04000F794618303AB6CEEA4E9A8E9C74D73C1B0B7BAF16
1984        DEDE7696B5E2F206F777100F5727E1684D4132F5E692F47AF6756EA8
1985        B421000BE031B5D8F0220E436B51FB154FE9595333C13A2403F9DE08
1986        E5DDC5A22FD6182E339593E26374450220BC14F3E40FF33F084526B0
1987        9C34250702E8A352B332CCCB0F9DE2CF2B338823B92AFC61C0B6B8AB
1988        DB5AF718ED8DDA97C298E46B82A01B14814868CFA4F2C36268BFFF4A
1989        591F42658BF75918902D3E426DFE1D5FF0FC6A212071F6DA8BD833FE
1990        2E560D87775E8EE9333C05B6FB8EB56589D910DB5EA903
1991
1992    0 1 EFDDF0D915C7BDC5782C0881E1B2A95AD099FBDD06D7B1F779
1993        82D9364338D955
1994
1995    0 2 81EE7F6C0ECC6B09B7785A9418F54432DE630DD54DC6EE9E3C
1996        49DE547708D236D4C413C3E97E44F969E635958AA410495844127C04
1997        883503E5B024CF7A8F6A94
1998
1999    1 0 308201A2300D06092A864886F70D01010105000382018F0030
2000        82018A0282018100E62C84A5AFE59F0A2A6B250DEE687AC8C5C604F5
2001        7D26CEB2119140FFAC38C4B9CBBE8923082E7F81626B6AD5DEA0C877
2002        1C74E3CAA7F613054AEFA3673E48FFE47B3F7AF987DE281A68230B24
2003        B9DA1A98DCBE51195B60E42FD7517C328D983E26A827C877AB914EE4
2004        C1BFDEAD48BD25BE5F2C473BA9C1CBBDDDA0C374D0D58C389CC3D6D8
2005        C20662E19CF768F32441B7F7D14AEA8966CE7C32A1722AB38623D008
2006        029A9E4702883F8B977A1A1E5292BF8AD72239D4039337B86A3AC60F
2007        A001290452177BF1798609A05A130F033457A5212629FBDDB8E70E2A
2008        9E6556873C4F7CA46AE4A8B178F05FB319005E1C1C7D4BD77DFA3403
2009        5563C126AA2C3328B900E7990AC9787F01DA82F74C3D4B6674CCECE1
2010        FD4C6EF9E6644F4635EDEDA39D8B0E2F7C8E06DAE7756213BD3D6083
2011        1175BE290442B4AFC5AE6F46B769855A067C1097E617962529E166F2
2012        2AEE10DDB981B8CD6FF17D3D70723169038DBFBC1A449C8D0D31BC68
2013        3C5F3CE26148E42EC9BBD4D9F261569B25B53C1D7FC2DDFF6B4CAC05
2014        0203010001
2015
2016
2017
2018 Hoffman & Schlyter           Standards Track                   [Page 36]
2019 \f
2020 RFC 6698            DNS-Based Authentication for TLS         August 2012
2021
2022
2023    1 1 8755CDAA8FE24EF16CC0F2C918063185E433FAAF1415664911
2024        D9E30A924138C4
2025
2026    1 2 D43165B4CDF8F8660AECCCC5344D9D9AE45FFD7E6AAB7AB9EE
2027        C169B58E11F227ED90C17330CC17B5CCEF0390066008C720CEC6AAE5
2028        33A934B3A2D7E232C94AB4
2029
2030 Authors' Addresses
2031
2032    Paul Hoffman
2033    VPN Consortium
2034
2035    EMail: paul.hoffman@vpnc.org
2036
2037
2038    Jakob Schlyter
2039    Kirei AB
2040
2041    EMail: jakob@kirei.se
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074 Hoffman & Schlyter           Standards Track                   [Page 37]
2075 \f