1 Internet Engineering Task Force (IETF)                       V. Dukhovni   
    2 Request for Comments: 7671                                     Two Sigma   
    3 Updates: 6698                                                W. Hardaker   
    4 Category: Standards Track                                        Parsons   
    5 ISSN: 2070-1721                                             October 2015   
    8     The DNS-Based Authentication of Named Entities (DANE) Protocol:        
    9                     Updates and Operational Guidance                       
   11 Abstract                                                                   
   13    This document clarifies and updates the DNS-Based Authentication of     
   14    Named Entities (DANE) TLSA specification (RFC 6698), based on           
   15    subsequent implementation experience.  It also contains guidance for    
   16    implementers, operators, and protocol developers who want to use DANE   
   17    records.                                                                
   19 Status of This Memo                                                        
   21    This is an Internet Standards Track document.                           
   23    This document is a product of the Internet Engineering Task Force       
   24    (IETF).  It represents the consensus of the IETF community.  It has     
   25    received public review and has been approved for publication by the     
   26    Internet Engineering Steering Group (IESG).  Further information on     
   27    Internet Standards is available in Section 2 of RFC 5741.               
   29    Information about the current status of this document, any errata,      
   30    and how to provide feedback on it may be obtained at                    
   31    http://www.rfc-editor.org/info/rfc7671.                                 
   33 Copyright Notice                                                           
   35    Copyright (c) 2015 IETF Trust and the persons identified as the         
   36    document authors.  All rights reserved.                                 
   38    This document is subject to BCP 78 and the IETF Trust's Legal           
   39    Provisions Relating to IETF Documents                                   
   40    (http://trustee.ietf.org/license-info) in effect on the date of         
   41    publication of this document.  Please review these documents            
   42    carefully, as they describe your rights and restrictions with respect   
   43    to this document.  Code Components extracted from this document must    
   44    include Simplified BSD License text as described in Section 4.e of      
   45    the Trust Legal Provisions and are provided without warranty as         
   46    described in the Simplified BSD License.                                
   52 Dukhovni & Hardaker          Standards Track                    [Page 1]   

   53 RFC 7671                     DANE Operations                October 2015   
   56 Table of Contents                                                          
   58    1. Introduction ....................................................3   
   59       1.1. Terminology ................................................4   
   60    2. DANE TLSA Record Overview .......................................5   
   61       2.1. Example TLSA Record ........................................6   
   62    3. DANE TLS Requirements ...........................................6   
   63    4. DANE Certificate Usage Selection Guidelines .....................7   
   64       4.1. Opportunistic Security and PKIX Usages .....................7   
   65       4.2. Interaction with Certificate Transparency ..................8   
   66       4.3. Switching from/to PKIX-TA/EE to/from DANE-TA/EE ............9   
   67    5. Certificate-Usage-Specific DANE Updates and Guidelines ..........9   
   68       5.1. Certificate Usage DANE-EE(3) ...............................9   
   69       5.2. Certificate Usage DANE-TA(2) ..............................11   
   70       5.3. Certificate Usage PKIX-EE(1) ..............................15   
   71       5.4. Certificate Usage PKIX-TA(0) ..............................15   
   72    6. Service Provider and TLSA Publisher Synchronization ............16   
   73    7. TLSA Base Domain and CNAMEs ....................................18   
   74    8. TLSA Publisher Requirements ....................................19   
   75       8.1. Key Rollover with Fixed TLSA Parameters ...................20   
   76       8.2. Switching to DANE-TA(2) from DANE-EE(3) ...................21   
   77       8.3. Switching to New TLSA Parameters ..........................22   
   78       8.4. TLSA Publisher Requirements: Summary ......................23   
   79    9. Digest Algorithm Agility .......................................23   
   80    10. General DANE Guidelines .......................................25   
   81       10.1. DANE DNS Record Size Guidelines ..........................25   
   82       10.2. Certificate Name Check Conventions .......................26   
   83       10.3. Design Considerations for Protocols Using DANE ...........27   
   84    11. Note on DNSSEC Security .......................................28   
   85    12. Summary of Updates to RFC 6698 ................................29   
   86    13. Operational Considerations ....................................29   
   87    14. Security Considerations .......................................30   
   88    15. References ....................................................30   
   89       15.1. Normative References .....................................30   
   90       15.2. Informative References ...................................32   
   91    Acknowledgements ..................................................33   
   92    Authors' Addresses ................................................33   
  107 Dukhovni & Hardaker          Standards Track                    [Page 2]   

  108 RFC 7671                     DANE Operations                October 2015   
  111 1.  Introduction                                                           
  113    The DNS-Based Authentication of Named Entities (DANE) specification     
  114    [RFC6698] introduces the DNS "TLSA" resource record (RR) type ("TLSA"   
  115    is not an acronym).  TLSA records associate a certificate or a public   
  116    key of an end-entity or a trusted issuing authority with the            
  117    corresponding Transport Layer Security (TLS) [RFC5246] or Datagram      
  118    Transport Layer Security (DTLS) [RFC6347] transport endpoint.  DANE     
  119    relies on the DNS Security Extensions (DNSSEC) [RFC4033].  DANE TLSA    
  120    records validated by DNSSEC can be used to augment or replace the use   
  121    of trusted public Certification Authorities (CAs).                      
  123    The TLS and DTLS protocols provide secured TCP and UDP communication,   
  124    respectively, over IP.  In the context of this document, channel        
  125    security is assumed to be provided by TLS or DTLS.  By convention,      
  126    "TLS" will be used throughout this document; unless otherwise           
  127    specified, the text applies equally well to DTLS over UDP.  Used        
  128    without authentication, TLS provides protection only against            
  129    eavesdropping through its use of encryption.  With authentication,      
  130    TLS also protects the transport against man-in-the-middle (MITM)        
  131    attacks.                                                                
  133    [RFC6698] defines three TLSA record fields: the first with four         
  134    possible values, the second with two, and the third with three.         
  135    These yield 24 distinct combinations of TLSA record types.  This        
  136    document recommends a smaller set of best-practice combinations of      
  137    these fields to simplify protocol design, implementation, and           
  138    deployment.                                                             
  140    This document explains and recommends DANE-specific strategies to       
  141    simplify "virtual hosting", where a single Service Provider transport   
  142    endpoint simultaneously supports multiple hosted Customer Domains.      
  144    Other related documents that build on [RFC6698] are [RFC7673] and       
  145    [RFC7672].                                                              
  147    Section 12 summarizes the normative updates this document makes to      
  148    [RFC6698].                                                              
  162 Dukhovni & Hardaker          Standards Track                    [Page 3]   

  163 RFC 7671                     DANE Operations                October 2015   
  166 1.1.  Terminology                                                          
  168    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",     
  170    "OPTIONAL" in this document are to be interpreted as described in       
  171    [RFC2119].                                                              
  173    The following terms are used throughout this document:                  
  175    Web PKI:  The Public Key Infrastructure (PKI) model employed by         
  176       browsers to authenticate web servers.  This employs a set of         
  177       trusted public CAs to vouch for the authenticity of public keys      
  178       associated with a particular party (the subject).                    
  180    Service Provider:  A company or organization that offers to host a      
  181       service on behalf of the owner of a Customer Domain.  The original   
  182       domain name associated with the service often remains under the      
  183       control of the customer.  Connecting applications may be directed    
  184       to the Service Provider via a redirection RR.  Example redirection   
  185       records include MX, SRV, and CNAME.  The Service Provider            
  186       frequently provides services for many customers and needs to         
  187       ensure that the TLS credentials presented to connecting              
  188       applications authenticate it as a valid server for the requested     
  189       domain.                                                              
  191    Customer Domain:  As described above, a TLS client may be interacting   
  192       with a service that is hosted by a third party.  This document       
  193       refers to the domain name used to locate the service (prior to any   
  194       redirection) as the "Customer Domain".                               
  196    TLSA Publisher:  The entity responsible for publishing a TLSA record    
  197       within a DNS zone.  This zone will be assumed DNSSEC-signed and      
  198       validatable to a trust anchor (TA), unless otherwise specified.      
  199       If the Customer Domain is not outsourcing its DNS service, the       
  200       TLSA Publisher will be the customer itself.  Otherwise, the TLSA     
  201       Publisher may be the operator of the outsourced DNS service.         
  203    Public key:  The term "public key" is shorthand for the                 
  204       subjectPublicKeyInfo component of a PKIX [RFC5280] certificate.      
  206    SNI:  The Server Name Indication (SNI) TLS protocol extension allows    
  207       a TLS client to request a connection to a particular service name    
  208       of a TLS server ([RFC6066], Section 3).  Without this TLS            
  209       extension, a TLS server has no choice but to offer a certificate     
  210       with a default list of server names, making it difficult to host     
  211       multiple Customer Domains at the same IP-address-based TLS service   
  212       endpoint (i.e., provide "secure virtual hosting").                   
  217 Dukhovni & Hardaker          Standards Track                    [Page 4]   

  218 RFC 7671                     DANE Operations                October 2015   
  221    TLSA parameters:  In [RFC6698], the TLSA record is defined to consist   
  222       of four fields.  The first three of these are numeric parameters     
  223       that specify the meaning of the data in the fourth and final         
  224       field.  This document refers to the first three fields as "TLSA      
  225       parameters", or sometimes just "parameters" when obvious from        
  226       context.                                                             
  228    TLSA base domain:  Per Section 3 of [RFC6698], TLSA records are         
  229       stored at a DNS domain name that is a combination of a port and      
  230       protocol prefix and a "base domain".  In [RFC6698], the "base        
  231       domain" is the fully qualified domain name of the TLS server.        
  232       This document modifies the TLSA record lookup strategy to prefer     
  233       the fully CNAME-expanded name of the TLS server, provided that       
  234       expansion is "secure" (DNSSEC validated) at each stage of the        
  235       expansion, and TLSA records are published for this fully expanded    
  236       name.  Thus, the "TLSA base domain" is either the fully              
  237       CNAME-expanded TLS server name or otherwise the initial fully        
  238       qualified TLS server name, whichever is used in combination with a   
  239       port and protocol prefix to obtain the TLSA RRset.                   
  241 2.  DANE TLSA Record Overview                                              
  243    DANE TLSA [RFC6698] specifies a protocol for publishing TLS server      
  244    certificate associations via DNSSEC [RFC4033] [RFC4034] [RFC4035].      
  245    DANE TLSA records consist of four fields.  The record type is           
  246    determined by the values of the first three fields, which this          
  247    document refers to as the "TLSA parameters" to distinguish them from    
  248    the fourth and last field.  The numeric values of these parameters      
  249    were given symbolic names in [RFC7218].  The four fields are as         
  250    follows:                                                                
  252    The Certificate Usage field:  Section 2.1.1 of [RFC6698] specifies      
  253       four values: PKIX-TA(0), PKIX-EE(1), DANE-TA(2), and DANE-EE(3).     
  254       There is an additional private-use value: PrivCert(255), which,      
  255       given its private scope, shall not be considered further in this     
  256       document.  All other values are reserved for use by future           
  257       specifications.                                                      
  259    The Selector field:  Section 2.1.2 of [RFC6698] specifies two values:   
  260       Cert(0) and SPKI(1).  There is an additional private-use value:      
  261       PrivSel(255).  All other values are reserved for use by future       
  262       specifications.                                                      
  264    The Matching Type field:  Section 2.1.3 of [RFC6698] specifies three    
  265       values: Full(0), SHA2-256(1), and SHA2-512(2).  There is an          
  266       additional private-use value: PrivMatch(255).  All other values      
  267       are reserved for use by future specifications.                       
  272 Dukhovni & Hardaker          Standards Track                    [Page 5]   

  273 RFC 7671                     DANE Operations                October 2015   
  276    The Certificate Association Data field:  See Section 2.1.4 of           
  277       [RFC6698].  This field stores the full value or digest of the        
  278       certificate or subject public key as determined by the matching      
  279       type and selector, respectively.                                     
  281    In the Matching Type field, of the two digest algorithms --             
  282    SHA2-256(1) and SHA2-512(2) -- as of the time of this writing, only     
  283    SHA2-256(1) is mandatory to implement.  Clients SHOULD implement        
  284    SHA2-512(2), but servers SHOULD NOT exclusively publish SHA2-512(2)     
  285    digests.  The digest algorithm agility protocol defined in Section 9    
  286    SHOULD be used by clients to decide how to process TLSA RRsets that     
  287    employ multiple digest algorithms.  Server operators MUST publish       
  288    TLSA RRsets that are compatible (see Section 8) with digest algorithm   
  289    agility (Section 9).                                                    
  291 2.1.  Example TLSA Record                                                  
  293    In the example TLSA record below, the TLSA certificate usage is         
  294    DANE-TA(2), the selector is Cert(0), and the matching type is           
  295    SHA2-256(1).  The last field is the Certificate Association Data        
  296    field, which in this case contains the SHA2-256 digest of the server    
  297    certificate.                                                            
  299    _25._tcp.mail.example.com. IN TLSA 2 0 1 (                              
  300                               E8B54E0B4BAA815B06D3462D65FBC7C0             
  301                               CF556ECCF9F5303EBFBB77D022F834C0 )           
  303 3.  DANE TLS Requirements                                                  
  305    [RFC6698] does not discuss what versions of TLS are required when       
  306    using DANE records.  This document specifies that TLS clients that      
  307    support DANE/TLSA MUST support at least TLS 1.0 and SHOULD support      
  308    TLS 1.2 or later.                                                       
  310    TLS clients using DANE MUST support the SNI extension of TLS            
  311    [RFC6066].  Servers MAY support SNI and respond with a matching         
  312    certificate chain but MAY also ignore SNI and respond with a default    
  313    certificate chain.  When a server supports SNI but is not configured    
  314    with a certificate chain that exactly matches the client's SNI          
  315    extension, the server SHOULD respond with another certificate chain     
  316    (a default or closest match).  This is because clients might support    
  317    more than one server name but can only put a single name in the SNI     
  318    extension.                                                              
  327 Dukhovni & Hardaker          Standards Track                    [Page 6]   

  328 RFC 7671                     DANE Operations                October 2015   
  331 4.  DANE Certificate Usage Selection Guidelines                            
  333    As mentioned in Section 2, the TLSA Certificate Usage field takes one   
  334    of four possible values.  With PKIX-TA(0) and PKIX-EE(1), the           
  335    validation of peer certificate chains requires additional               
  336    preconfigured CA TAs that are mutually trusted by the operators of      
  337    the TLS server and client.  With DANE-TA(2) and DANE-EE(3), no          
  338    preconfigured CA TAs are required and the published DANE TLSA records   
  339    are sufficient to verify the peer's certificate chain.                  
  341    Standards for application protocols that employ DANE TLSA can specify   
  342    more specific guidance than [RFC6698] or this document.  Such           
  343    application-specific standards need to carefully consider which set     
  344    of DANE certificate usages to support.  Simultaneous support for all    
  345    four usages is NOT RECOMMENDED for DANE clients.  When all four         
  346    usages are supported, an attacker capable of compromising the           
  347    integrity of DNSSEC needs only to replace the server's TLSA RRset       
  348    with one that lists suitable DANE-EE(3) or DANE-TA(2) records,          
  349    effectively bypassing any added verification via public CAs.  In        
  350    other words, when all four usages are supported, PKIX-TA(0) and         
  351    PKIX-EE(1) offer only illusory incremental security over DANE-TA(2)     
  352    and DANE-EE(3).                                                         
  354    Designs in which clients support just the DANE-TA(2) and DANE-EE(3)     
  355    certificate usages are RECOMMENDED.  With DANE-TA(2) and DANE-EE(3),    
  356    clients don't need to track a large changing list of X.509 TAs in       
  357    order to successfully authenticate servers whose certificates are       
  358    issued by a CA that is brand new or not widely trusted.                 
  360    The DNSSEC TLSA records for servers MAY include both sets of usages     
  361    if the server needs to support a mixture of clients, some supporting    
  362    one pair of usages and some the other.                                  
  364 4.1.  Opportunistic Security and PKIX Usages                               
  366    When the client's protocol design is based on "Opportunistic            
  367    Security" (OS) [RFC7435] and the use of authentication is based on      
  368    the presence of server TLSA records, it is especially important to      
  369    avoid the PKIX-EE(1) and PKIX-TA(0) certificate usages.                 
  371    When authenticated TLS is used opportunistically based on the           
  372    presence of DANE TLSA records and no secure TLSA records are present,   
  373    unauthenticated TLS is used if possible, and if TLS is not possible,    
  374    perhaps even cleartext.  However, if usable secure TLSA records are     
  375    published, then authentication MUST succeed.  Also, outside the         
  376    browser space, there is no preordained canon of trusted CAs, and in     
  377    any case there is no security advantage in using PKIX-TA(0) or          
  382 Dukhovni & Hardaker          Standards Track                    [Page 7]   

  383 RFC 7671                     DANE Operations                October 2015   
  386    PKIX-EE(1) when the DANE-TA(2) and DANE-EE(3) usages are also           
  387    supported (as an attacker who can compromise DNS can replace the        
  388    former with the latter).                                                
  390    Authentication via the PKIX-TA(0) and PKIX-EE(1) certificate usages     
  391    is more brittle; the client and server need to happen to agree on a     
  392    mutually trusted CA, but with OS the client is just trying to protect   
  393    the communication channel at the request of the server and would        
  394    otherwise be willing to use cleartext or unauthenticated TLS.  The      
  395    use of fragile mechanisms (like public CA authentication for some       
  396    unspecified set of trusted CAs) is not sufficiently reliable for an     
  397    OS client to honor the server's request for authentication.  OS needs   
  398    to be non-intrusive and to require few, if any, workarounds for valid   
  399    but mismatched peers.                                                   
  401    Because the PKIX-TA(0) and PKIX-EE(1) usages offer no more security     
  402    and are more prone to failure, they are a poor fit for OS and           
  403    SHOULD NOT be used in that context.                                     
  405 4.2.  Interaction with Certificate Transparency                            
  407    Certificate Transparency (CT) [RFC6962] defines an experimental         
  408    approach that could be used to mitigate the risk of rogue or            
  409    compromised public CAs issuing unauthorized certificates.  This         
  410    section clarifies the interaction of the experimental CT and DANE.      
  411    This section may need to be revised in light of any future Standards    
  412    Track version of CT.                                                    
  414    When a server is authenticated via a DANE TLSA RR with TLSA             
  415    certificate usage DANE-EE(3), the domain owner has directly specified   
  416    the certificate associated with the given service without reference     
  417    to any public CA.  Therefore, when a TLS client authenticates the TLS   
  418    server via a TLSA record with usage DANE-EE(3), CT checks SHOULD NOT    
  419    be performed.  Publication of the server certificate or public key      
  420    (digest) in a TLSA record in a DNSSEC-signed zone by the domain owner   
  421    assures the TLS client that the certificate is not an unauthorized      
  422    certificate issued by a rogue CA without the domain owner's consent.    
  424    When a server is authenticated via a DANE TLSA record with TLSA usage   
  425    DANE-TA(2) and the server certificate does not chain to a known         
  426    public root CA, CT cannot apply (CT logs only accept chains that        
  427    start with a known public root).  Since TLSA certificate usage          
  428    DANE-TA(2) is generally intended to support non-public TAs, TLS         
  429    clients SHOULD NOT perform CT checks with usage DANE-TA(2).             
  437 Dukhovni & Hardaker          Standards Track                    [Page 8]   

  438 RFC 7671                     DANE Operations                October 2015   
  441    With certificate usages PKIX-TA(0) and PKIX-EE(1), CT applies just as   
  442    it would without DANE.  TLSA records of this type only constrain        
  443    which CAs are acceptable in PKIX validation.  All checks used in the    
  444    absence of DANE still apply when validating certificate chains with     
  445    DANE PKIX-TA(0) and PKIX-EE(1) constraints.                             
  447 4.3.  Switching from/to PKIX-TA/EE to/from DANE-TA/EE                      
  449    The choice of preferred certificate usages may need to change as an     
  450    application protocol evolves.  When transitioning between PKIX-TA/      
  451    PKIX-EE and DANE-TA/DANE-EE, clients begin to enable support for the    
  452    new certificate usage values.  If the new preferred certificate         
  453    usages are PKIX-TA/EE, this requires installing and managing the        
  454    appropriate set of CA TAs.  During this time, servers will publish      
  455    both types of TLSA records.  At some later time, when the vast          
  456    majority of servers have published the new preferred TLSA records,      
  457    clients can stop supporting the legacy certificate usages.              
  458    Similarly, servers can stop publishing legacy TLSA records once the     
  459    vast majority of clients support the new certificate usages.            
  461 5.  Certificate-Usage-Specific DANE Updates and Guidelines                 
  463    The four certificate usage values from the TLSA record -- DANE-EE(3),   
  464    DANE-TA(2), PKIX-EE(1), and PKIX-TA(0) -- are discussed below.          
  466 5.1.  Certificate Usage DANE-EE(3)                                         
  468    In this section, the meaning of DANE-EE(3) is updated from [RFC6698]    
  469    to specify that peer identity matching and validity period              
  470    enforcement are based solely on the TLSA RRset properties.  This        
  471    document also extends [RFC6698] to cover the use of DANE                
  472    authentication of raw public keys [RFC7250] via TLSA records with       
  473    certificate usage DANE-EE(3) and selector SPKI(1).                      
  475    Authentication via certificate usage DANE-EE(3) TLSA records involves   
  476    simply checking that the server's leaf certificate matches the TLSA     
  477    record.  In particular, the binding of the server public key to its     
  478    name is based entirely on the TLSA record association.  The server      
  479    MUST be considered authenticated even if none of the names in the       
  480    certificate match the client's reference identity for the server.       
  481    This simplifies the operation of servers that host multiple Customer    
  482    Domains, as a single certificate can be associated with multiple        
  483    domains without having to match each of the corresponding reference     
  484    identifiers.                                                            
  492 Dukhovni & Hardaker          Standards Track                    [Page 9]   

  493 RFC 7671                     DANE Operations                October 2015   
  496    ; Multiple Customer Domains hosted by an example.net                    
  497    ; Service Provider:                                                     
  498    ;                                                                       
  499    www.example.com.              IN CNAME ex-com.example.net.              
  500    www.example.org.              IN CNAME ex-org.example.net.              
  501    ;                                                                       
  502    ; In the provider's DNS zone, a single certificate and TLSA             
  503    ; record support multiple Customer Domains, greatly simplifying         
  504    ; "virtual hosting".                                                    
  505    ;                                                                       
  506    ex-com.example.net.           IN A                            
  507    ex-org.example.net.           IN A                            
  508    _443._tcp.ex-com.example.net. IN CNAME tlsa._dane.example.net.          
  509    _443._tcp.ex-org.example.net. IN CNAME tlsa._dane.example.net.          
  510    tlsa._dane.example.net.       IN TLSA 3 1 1 e3b0c44298fc1c14...         
  512    Also, with DANE-EE(3), the expiration date of the server certificate    
  513    MUST be ignored.  The validity period of the TLSA record key binding    
  514    is determined by the validity period of the TLSA record DNSSEC          
  515    signatures.  Validity is reaffirmed on an ongoing basis by continuing   
  516    to publish the TLSA record and signing the zone in which the record     
  517    is contained, rather than via dates "set in stone" in the               
  518    certificate.  The expiration becomes a reminder to the administrator    
  519    that it is likely time to rotate the key, but missing the date no       
  520    longer causes an outage.  When keys are rotated (for whatever           
  521    reason), it is important to follow the procedures outlined in           
  522    Section 8.                                                              
  524    If a server uses just DANE-EE(3) TLSA records and all its clients are   
  525    DANE clients, the server need not employ SNI (i.e., it may ignore the   
  526    client's SNI message) even when the server is known via multiple        
  527    domain names that would otherwise require separate certificates.  It    
  528    is instead sufficient for the TLSA RRsets for all the domain names in   
  529    question to match the server's default certificate.  For application    
  530    protocols where the server name is obtained indirectly via SRV          
  531    records, MX records, or similar records, it is simplest to publish a    
  532    single hostname as the target server name for all the hosted domains.   
  534    In organizations where it is practical to make coordinated changes in   
  535    DNS TLSA records before server key rotation, it is generally best to    
  536    publish end-entity DANE-EE(3) certificate associations in preference    
  537    to other choices of certificate usage.  DANE-EE(3) TLSA records         
  538    support multiple server names without SNI, don't suddenly stop          
  539    working when leaf or intermediate certificates expire, and don't fail   
  540    when a server operator neglects to include all the required issuer      
  541    certificates in the server certificate chain.                           
  547 Dukhovni & Hardaker          Standards Track                   [Page 10]   

  548 RFC 7671                     DANE Operations                October 2015   
  551    More specifically, it is RECOMMENDED that at most sites TLSA records    
  552    published for DANE servers be "DANE-EE(3) SPKI(1) SHA2-256(1)"          
  553    records.  Selector SPKI(1) is chosen because it is compatible with      
  554    raw public keys [RFC7250] and the resulting TLSA record need not        
  555    change across certificate renewals with the same key.  Matching type    
  556    SHA2-256(1) is chosen because all DANE implementations are required     
  557    to support SHA2-256.  This TLSA record type easily supports hosting     
  558    arrangements with a single certificate matching all hosted domains.     
  559    It is also the easiest to implement correctly in the client.            
  561    Clients that support raw public keys can use DANE TLSA records with     
  562    certificate usage DANE-EE(3) and selector SPKI(1) to authenticate       
  563    servers that negotiate the use of raw public keys.  Provided the        
  564    server adheres to the requirements of Section 8, the fact that raw      
  565    public keys are not compatible with any other TLSA record types will    
  566    not get in the way of successful authentication.  Clients that employ   
  567    DANE to authenticate the peer server SHOULD NOT negotiate the use of    
  568    raw public keys unless the server's TLSA RRset includes "DANE-EE(3)     
  569    SPKI(1)" TLSA records.                                                  
  571    While it is, in principle, also possible to authenticate raw public     
  572    keys via "DANE-EE(3) Cert(0) Full(0)" records by extracting the         
  573    public key from the certificate in DNS, extracting just the public      
  574    key from a "3 0 0" TLSA record requires extra logic on clients that     
  575    not all implementations are expected to provide.  Servers that wish     
  576    to support [RFC7250] raw public keys need to publish TLSA records       
  577    with a certificate usage of DANE-EE(3) and a selector of SPKI(1).       
  579    While DANE-EE(3) TLSA records are expected to be by far the most        
  580    prevalent, as explained in Section 5.2, DANE-TA(2) records are a        
  581    valid alternative for sites with many DANE services.  Note, however,    
  582    that virtual hosting is more complex with DANE-TA(2).  Also, with       
  583    DANE-TA(2), server operators MUST ensure that the server is             
  584    configured with a sufficiently complete certificate chain and need to   
  585    remember to replace certificates prior to their expiration dates.       
  587 5.2.  Certificate Usage DANE-TA(2)                                         
  589    This section updates [RFC6698] by specifying a new operational          
  590    requirement for servers publishing TLSA records with a usage of         
  591    DANE-TA(2): such servers MUST include the TA certificate in their TLS   
  592    server certificate message unless all such TLSA records are "2 0 0"     
  593    records that publish the server certificate in full.                    
  595    Some domains may prefer to avoid the operational complexity of          
  596    publishing unique TLSA RRs for each TLS service.  If the domain         
  597    employs a common issuing CA to create certificates for multiple TLS     
  598    services, it may be simpler to publish the issuing authority as a TA    
  602 Dukhovni & Hardaker          Standards Track                   [Page 11]   

  603 RFC 7671                     DANE Operations                October 2015   
  606    for the certificate chains of all relevant services.  The TLSA query    
  607    domain (TLSA base domain with port and protocol prefix labels) for      
  608    each service issued by the same TA may then be set to a CNAME alias     
  609    that points to a common TLSA RRset that matches the TA.  For example:   
  611    ; Two servers, each with its own certificate, that share                
  612    ; a common issuer (TA).                                                 
  613    ;                                                                       
  614    www1.example.com.            IN A                             
  615    www2.example.com.            IN A                             
  616    _443._tcp.www1.example.com.  IN CNAME tlsa._dane.example.com.           
  617    _443._tcp.www2.example.com.  IN CNAME tlsa._dane.example.com.           
  618    tlsa._dane.example.com.      IN TLSA 2 0 1 e3b0c44298fc1c14...          
  620    The above configuration simplifies server key rotation, because while   
  621    the servers continue to receive new certificates from a CA matched by   
  622    the shared (target of the CNAMEs) TLSA record, server certificates      
  623    can be updated without making any DNS changes.  As the list of active   
  624    issuing CAs changes, the shared TLSA record will be updated (much       
  625    less frequently) by the administrators who manage the CAs.  Those       
  626    administrators still need to perform TLSA record updates with care,     
  627    as described in Section 8.                                              
  629    With usage DANE-TA(2), the server certificates will need to have        
  630    names that match one of the client's reference identifiers (see         
  631    [RFC6125]).  When hosting multiple unrelated Customer Domains (that     
  632    can't all appear in a single certificate), such a server SHOULD         
  633    employ SNI to select the appropriate certificate to present to the      
  634    client.                                                                 
  636 5.2.1.  Recommended Record Combinations                                    
  638    TLSA records with a matching type of Full(0) are NOT RECOMMENDED.       
  639    While these potentially obviate the need to transmit the TA             
  640    certificate in the TLS server certificate message, client               
  641    implementations may not be able to augment the server certificate       
  642    chain with the data obtained from DNS, especially when the TLSA         
  643    record supplies a bare key (selector SPKI(1)).  Since the server will   
  644    need to transmit the TA certificate in any case, server operators       
  645    SHOULD publish TLSA records with a matching type other than Full(0)     
  646    and avoid potential DNS interoperability issues with large TLSA         
  647    records containing full certificates or keys (see Section 10.1.1).      
  657 Dukhovni & Hardaker          Standards Track                   [Page 12]   

  658 RFC 7671                     DANE Operations                October 2015   
  661    TLSA Publishers employing DANE-TA(2) records SHOULD publish records     
  662    with a selector of Cert(0).  Such TLSA records are associated with      
  663    the whole TA certificate, not just with the TA public key.  In          
  664    particular, when authenticating the peer certificate chain via such a   
  665    TLSA record, the client SHOULD apply any relevant constraints from      
  666    the TA certificate, such as, for example, path length constraints.      
  668    While a selector of SPKI(1) may also be employed, the resulting TLSA    
  669    record will not specify the full TA certificate content, and elements   
  670    of the TA certificate other than the public key become mutable.  This   
  671    may, for example, enable a subsidiary CA to issue a chain that          
  672    violates the TA's path length or name constraints.                      
  674 5.2.2.  Trust Anchor Digests and Server Certificate Chain                  
  676    With DANE-TA(2), a complication arises when the TA certificate is       
  677    omitted from the server's certificate chain, perhaps on the basis of    
  678    Section 7.4.2 of [RFC5246]:                                             
  680       The sender's certificate MUST come first in the list.  Each          
  681       following certificate MUST directly certify the one preceding it.    
  682       Because certificate validation requires that root keys be            
  683       distributed independently, the self-signed certificate that          
  684       specifies the root certificate authority MAY be omitted from the     
  685       chain, under the assumption that the remote end must already         
  686       possess it in order to validate it in any case.                      
  688    With TLSA certificate usage DANE-TA(2), there is no expectation that    
  689    the client is preconfigured with the TA certificate.  In fact, client   
  690    implementations are free to ignore all locally configured TAs when      
  691    processing usage DANE-TA(2) TLSA records and may rely exclusively on    
  692    the certificates provided in the server's certificate chain.  But,      
  693    with a digest in the TLSA record, the TLSA record contains neither      
  694    the full TA certificate nor the full public key.  If the TLS server's   
  695    certificate chain does not contain the TA certificate, DANE clients     
  696    will be unable to authenticate the server.                              
  698    TLSA Publishers that publish TLSA certificate usage DANE-TA(2)          
  699    associations with a selector of SPKI(1) or with a digest-based          
  700    matching type (not Full(0)) MUST ensure that the corresponding server   
  701    is configured to also include the TA certificate in its TLS handshake   
  702    certificate chain, even if that certificate is a self-signed root CA    
  703    and would have been optional in the context of the existing public      
  704    CA PKI.                                                                 
  712 Dukhovni & Hardaker          Standards Track                   [Page 13]   

  713 RFC 7671                     DANE Operations                October 2015   
  716    Only when the server TLSA record includes a "DANE-TA(2) Cert(0)         
  717    Full(0)" TLSA record containing a full TA certificate is the TA         
  718    certificate optional in the server's TLS certificate message.  This     
  719    is also the only type of DANE-TA(2) record for which the client MUST    
  720    be able to verify the server's certificate chain even if the TA         
  721    certificate appears only in DNS and is absent from the TLS handshake    
  722    server certificate message.                                             
  724 5.2.3.  Trust Anchor Public Keys                                           
  726    TLSA records with TLSA certificate usage DANE-TA(2), selector           
  727    SPKI(1), and a matching type of Full(0) publish the full public key     
  728    of a TA via DNS.  In Section 6.1.1 of [RFC5280], the definition of a    
  729    TA consists of the following four parts:                                
  731    1.  the trusted issuer name,                                            
  733    2.  the trusted public key algorithm,                                   
  735    3.  the trusted public key, and                                         
  737    4.  optionally, the trusted public key parameters associated with the   
  738        public key.                                                         
  740    Items 2-4 are precisely the contents of the subjectPublicKeyInfo        
  741    published in the TLSA record.  The issuer name is not included in the   
  742    subjectPublicKeyInfo.                                                   
  744    With TLSA certificate usage DANE-TA(2), the client may not have the     
  745    associated TA certificate and cannot generally verify whether or not    
  746    a particular certificate chain is "issued by" the TA described in the   
  747    TLSA record.                                                            
  749    When the server certificate chain includes a CA certificate whose       
  750    public key matches the TLSA record, the client can match that CA as     
  751    the intended issuer.  Otherwise, the client can only check that the     
  752    topmost certificate in the server's chain is "signed by" the TA's       
  753    public key in the TLSA record.  Such a check may be difficult to        
  754    implement and cannot be expected to be supported by all clients.        
  756    Thus, servers cannot rely on "DANE-TA(2) SPKI(1) Full(0)" TLSA          
  757    records to be sufficient to authenticate chains issued by the           
  758    associated public key in the absence of a corresponding certificate     
  759    in the server's TLS certificate message.  Servers employing "2 1 0"     
  760    TLSA records MUST include the corresponding TA certificate in their     
  761    certificate chain.                                                      
  767 Dukhovni & Hardaker          Standards Track                   [Page 14]   

  768 RFC 7671                     DANE Operations                October 2015   
  771    If none of the server's certificate chain elements match a public key   
  772    specified in a TLSA record, and at least one "DANE-TA(2) SPKI(1)        
  773    Full(0)" TLSA record is available, it is RECOMMENDED that clients       
  774    check to see whether or not the topmost certificate in the chain is     
  775    signed by the provided public key and has not expired, and in that      
  776    case consider the server authenticated, provided the rest of the        
  777    chain passes validation, including leaf certificate name checks.        
  779 5.3.  Certificate Usage PKIX-EE(1)                                         
  781    This certificate usage is similar to DANE-EE(3); but, in addition,      
  782    PKIX verification is required.  Therefore, name checks, certificate     
  783    expiration, CT, etc. apply as they would without DANE.                  
  785 5.4.  Certificate Usage PKIX-TA(0)                                         
  787    This section updates [RFC6698] by specifying new client                 
  788    implementation requirements.  Clients that trust intermediate           
  789    certificates MUST be prepared to construct longer PKIX chains than      
  790    would be required for PKIX alone.                                       
  792    TLSA certificate usage PKIX-TA(0) allows a domain to publish            
  793    constraints on the set of PKIX CAs trusted to issue certificates for    
  794    its TLS servers.  A PKIX-TA(0) TLSA record matches PKIX-verified        
  795    trust chains that contain an issuer certificate (root or                
  796    intermediate) that matches its Certificate Association Data field       
  797    (typically a certificate or digest).                                    
  799    PKIX-TA(0) requires more complex coordination (than with DANE-TA(2)     
  800    or DANE-EE(3)) between the Customer Domain and the Service Provider     
  801    in hosting arrangements.  Thus, this certificate usage is               
  802    NOT RECOMMENDED when the Service Provider is not also the TLSA          
  803    Publisher (at the TLSA base domain obtained via CNAMEs, SRV records,    
  804    or MX records).                                                         
  806    TLSA Publishers who publish TLSA records for a particular public root   
  807    CA will expect that clients will only accept chains anchored at that    
  808    root.  It is possible, however, that the client's trusted certificate   
  809    store includes some intermediate CAs, either with or without the        
  810    corresponding root CA.  When a client constructs a trust chain          
  811    leading from a trusted intermediate CA to the server leaf               
  812    certificate, such a "truncated" chain might not contain the trusted     
  813    root published in the server's TLSA record.                             
  815    If the omitted root is also trusted, the client may erroneously         
  816    reject the server chain if it fails to determine that the shorter       
  817    chain it constructed extends to a longer trusted chain that matches     
  818    the TLSA record.  Thus, when matching a usage PKIX-TA(0) TLSA record,   
  822 Dukhovni & Hardaker          Standards Track                   [Page 15]   

  823 RFC 7671                     DANE Operations                October 2015   
  826    so long as no matching certificate has yet been found, a client MUST    
  827    continue extending the chain even after any locally trusted             
  828    certificate is found.  If no TLSA records have matched any of the       
  829    elements of the chain and the trusted certificate found is not          
  830    self-issued, the client MUST attempt to build a longer chain in case    
  831    a certificate closer to the root matches the server's TLSA record.      
  833 6.  Service Provider and TLSA Publisher Synchronization                    
  835    Whenever possible, the TLSA Publisher and the Service Provider should   
  836    be the same entity.  Otherwise, they need to coordinate changes to      
  837    ensure that TLSA records published by the TLSA Publisher don't fall     
  838    out of sync with the server certificate used by the Service Provider.   
  839    Such coordination is difficult, and service outages will result when    
  840    coordination fails.                                                     
  842    Publishing the TLSA record in the Service Provider's zone avoids the    
  843    complexity of bilateral coordination of server certificate              
  844    configuration and TLSA record management.  Even when the TLSA RRset     
  845    has to be published in the Customer Domain's DNS zone (perhaps the      
  846    client application does not "chase" CNAMEs to the TLSA base domain),    
  847    it is possible to employ CNAME records to delegate the content of the   
  848    TLSA RRset to a domain operated by the Service Provider.                
  850    Only certificate usages DANE-EE(3) and DANE-TA(2) work well with TLSA   
  851    CNAMEs across organizational boundaries.  With PKIX-TA(0) or            
  852    PKIX-EE(1), the Service Provider would need to obtain certificates in   
  853    the name of the Customer Domain from a suitable public CA (securely     
  854    impersonate the customer), or the customer would need to provision      
  855    the relevant private keys and certificates at the Service Provider's    
  856    systems.                                                                
  858    Certificate Usage DANE-EE(3):  In this case, the Service Provider can   
  859       publish a single TLSA RRset that matches the server certificate or   
  860       public key digest.  The same RRset works for all Customer Domains    
  861       because name checks do not apply with DANE-EE(3) TLSA records (see   
  862       Section 5.1).  A Customer Domain can create a CNAME record           
  863       pointing to the TLSA RRset published by the Service Provider.        
  865    Certificate Usage DANE-TA(2):  When the Service Provider operates a     
  866       private CA, the Service Provider is free to issue a certificate      
  867       bearing any customer's domain name.  Without DANE, such a            
  868       certificate would not pass trust verification, but with DANE, the    
  869       customer's TLSA RRset that is aliased to the provider's TLSA RRset   
  870       can delegate authority to the provider's CA for the corresponding    
  871       service.  The Service Provider can generate appropriate              
  877 Dukhovni & Hardaker          Standards Track                   [Page 16]   

  878 RFC 7671                     DANE Operations                October 2015   
  881       certificates for each customer and use the SNI information           
  882       provided by clients to select the right certificate chain to         
  883       present to each client.                                              
  885    Below are example DNS records (assumed "secure" and shown without the   
  886    associated DNSSEC information, such as record signatures) that          
  887    illustrate both of the above models in the case of an HTTPS service     
  888    whose clients all support DANE TLS.  These examples work even with      
  889    clients that don't "chase" CNAMEs when constructing the TLSA base       
  890    domain (see Section 7 below).                                           
  892    ; The hosted web service is redirected via a CNAME alias.               
  893    ; The associated TLSA RRset is also redirected via a CNAME alias.       
  894    ;                                                                       
  895    ; Certificate usage DANE-EE(3) makes it possible to deploy              
  896    ; a single provider certificate for all Customer Domains.               
  897    ;                                                                       
  898    www1.example.com.            IN CNAME w1.example.net.                   
  899    _443._tcp.www1.example.com.  IN CNAME _443._tcp.w1.example.net.         
  900    _443._tcp.w1.example.net.    IN TLSA 3 1 1 (                            
  901                                    8A9A70596E869BED72C69D97A8895DFA        
  902                                    D86F300A343FECEFF19E89C27C896BC9 )      
  904    ;                                                                       
  905    ; A CA at the provider can also issue certificates for each Customer    
  906    ; Domain and employ the DANE-TA(2) certificate usage to                 
  907    ; designate the provider's CA as a TA.                                  
  908    ;                                                                       
  909    www2.example.com.            IN CNAME w2.example.net.                   
  910    _443._tcp.www2.example.com.  IN CNAME _443._tcp.w2.example.net.         
  911    _443._tcp.w2.example.net.    IN TLSA 2 0 1 (                            
  912                                    C164B2C3F36D068D42A6138E446152F5        
  913                                    68615F28C69BD96A73E354CAC88ED00C )      
  915    With protocols that support explicit transport redirection via DNS MX   
  916    records, SRV records, or other similar records, the TLSA base domain    
  917    is based on the redirected transport endpoint rather than the origin    
  918    domain.  With SMTP, for example, when an email service is hosted by a   
  919    Service Provider, the Customer Domain's MX hostnames will point at      
  920    the Service Provider's SMTP hosts.  When the Customer Domain's DNS      
  921    zone is signed, the MX hostnames can be securely used as the base       
  932 Dukhovni & Hardaker          Standards Track                   [Page 17]   

  933 RFC 7671                     DANE Operations                October 2015   
  936    domains for TLSA records that are published and managed by the          
  937    Service Provider.  For example (without the required DNSSEC             
  938    information, such as record signatures):                                
  940    ; Hosted SMTP service.                                                  
  941    ;                                                                       
  942    example.com.               IN MX 0 mx1.example.net.                     
  943    example.com.               IN MX 0 mx2.example.net.                     
  944    _25._tcp.mx1.example.net.  IN TLSA 3 1 1 (                              
  945                                  8A9A70596E869BED72C69D97A8895DFA          
  946                                  D86F300A343FECEFF19E89C27C896BC9 )        
  947    _25._tcp.mx2.example.net.  IN TLSA 3 1 1 (                              
  948                                  C164B2C3F36D068D42A6138E446152F5          
  949                                  68615F28C69BD96A73E354CAC88ED00C )        
  951    If redirection to the Service Provider's domain (via MX records, SRV    
  952    records, or any similar mechanism) is not possible and aliasing of      
  953    the TLSA record is not an option, then more complex coordination        
  954    between the Customer Domain and Service Provider will be required.      
  955    Either the Customer Domain periodically provides private keys and a     
  956    corresponding certificate chain to the provider (after making           
  957    appropriate changes in its TLSA records), or the Service Provider       
  958    periodically generates the keys and certificates and needs to wait      
  959    for matching TLSA records to be published by its Customer Domains       
  960    before deploying newly generated keys and certificate chains.           
  961    Section 7 below describes an approach that employs CNAME "chasing" to   
  962    avoid the difficulties of coordinating key management across            
  963    organizational boundaries.                                              
  965    For further information about combining DANE and SRV, please see        
  966    [RFC7673].                                                              
  968 7.  TLSA Base Domain and CNAMEs                                            
  970    When the application protocol does not support service location         
  971    indirection via MX, SRV, or similar DNS records, the service may be     
  972    redirected via a CNAME.  A CNAME is a more blunt instrument for this    
  973    purpose because, unlike an MX or SRV record, it remaps the entire       
  974    origin domain to the target domain for all protocols.                   
  976    The complexity of coordinating key management is largely eliminated     
  977    when DANE TLSA records are found in the Service Provider's domain, as   
  978    discussed in Section 6.  Therefore, DANE TLS clients connecting to a    
  979    server whose domain name is a CNAME alias SHOULD follow the CNAME       
  980    "hop by hop" to its ultimate target host (noting at each step whether   
  981    or not the CNAME is DNSSEC validated).  If at each stage of CNAME       
  982    expansion the DNSSEC validation status is "secure", the final target    
  983    name SHOULD be the preferred base domain for TLSA lookups.              
  987 Dukhovni & Hardaker          Standards Track                   [Page 18]   

  988 RFC 7671                     DANE Operations                October 2015   
  991    Implementations failing to find a TLSA record using a base name of      
  992    the final target of a CNAME expansion SHOULD issue a TLSA query using   
  993    the original destination name.  That is, the preferred TLSA base        
  994    domain SHOULD be derived from the fully expanded name and, failing      
  995    that, SHOULD be the initial domain name.                                
  997    When the TLSA base domain is the result of "secure" CNAME expansion,    
  998    the resulting domain name MUST be used as the HostName in the           
  999    client's SNI extension and MUST be the primary reference identifier     
 1000    for peer certificate matching with certificate usages other than        
 1001    DANE-EE(3).                                                             
 1003    Protocol-specific TLSA specifications may provide additional guidance   
 1004    or restrictions when following CNAME expansions.                        
 1006    Though CNAMEs are illegal on the right-hand side of most indirection    
 1007    records, such as MX and SRV records, they are supported by some         
 1008    implementations.  For example, if the MX or SRV host is a CNAME         
 1009    alias, some implementations may "chase" the CNAME.  If they do, they    
 1010    SHOULD use the target hostname as the preferred TLSA base domain as     
 1011    described above (and, if the TLSA records are found there, also use     
 1012    the CNAME-expanded domain in SNI and certificate name checks).          
 1014 8.  TLSA Publisher Requirements                                            
 1016    This section updates [RFC6698] by specifying that the TLSA Publisher    
 1017    MUST ensure that each combination of certificate usage, selector, and   
 1018    matching type in the server's TLSA RRset includes at least one record   
 1019    that matches the server's current certificate chain.  TLSA records      
 1020    that match recently retired or yet-to-be-deployed certificate chains    
 1021    will be present during key rollover.  Such past or future records       
 1022    MUST NOT at any time be the only records published for any given        
 1023    combination of usage, selector, and matching type.  The TLSA record     
 1024    update process described below ensures that this requirement is met.    
 1026    While a server is to be considered authenticated when its certificate   
 1027    chain is matched by any of the published TLSA records, not all          
 1028    clients support all combinations of TLSA record parameters.  Some       
 1029    clients may not support some digest algorithms; others may either not   
 1030    support or exclusively support the PKIX certificate usages.  Some       
 1031    clients may prefer to negotiate [RFC7250] raw public keys, which are    
 1032    only compatible with TLSA records whose certificate usage is            
 1033    DANE-EE(3) with selector SPKI(1).  The only other TLSA record type      
 1034    that is potentially compatible with raw public keys is "DANE-EE(3)      
 1035    Cert(0) Full(0)", but support for raw public keys with that TLSA        
 1036    record type is not expected to be broadly implemented.                  
 1042 Dukhovni & Hardaker          Standards Track                   [Page 19]   

 1043 RFC 7671                     DANE Operations                October 2015   
 1046    A consequence of the above uncertainty as to which TLSA parameters      
 1047    are supported by any given client is that servers need to ensure that   
 1048    each and every parameter combination that appears in the TLSA RRset     
 1049    is, on its own, sufficient to match the server's current certificate    
 1050    chain.  In particular, when deploying new keys or new parameter         
 1051    combinations, some care is required to not generate parameter           
 1052    combinations that only match past or future certificate chains (or      
 1053    raw public keys).  The rest of this section explains how to update      
 1054    the TLSA RRset in a manner that ensures that the above requirement      
 1055    is met.                                                                 
 1057 8.1.  Key Rollover with Fixed TLSA Parameters                              
 1059    The simplest case is key rollover while retaining the same set of       
 1060    published parameter combinations.  In this case, TLSA records           
 1061    matching the existing server certificate chain (or raw public keys)     
 1062    are first augmented with corresponding records matching the future      
 1063    keys, at least two Times to Live (TTLs) or longer before the new        
 1064    chain is deployed.  This allows the obsolete RRset to age out of        
 1065    client caches before the new chain is used in TLS handshakes.  Once     
 1066    sufficient time has elapsed and all clients performing DNS lookups      
 1067    are retrieving the updated TLSA records, the server administrator may   
 1068    deploy the new certificate chain, verify that it works, and then        
 1069    remove any obsolete records matching the chain that is no longer        
 1070    active:                                                                 
 1072    ; Initial TLSA RRset.                                                   
 1073    ;                                                                       
 1074    _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...            
 1076    ; Transitional TLSA RRset published at least two TTLs before            
 1077    ; the actual key change.                                                
 1078    ;                                                                       
 1079    _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...            
 1080    _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...            
 1082    ; Final TLSA RRset after the key change.                                
 1083    ;                                                                       
 1084    _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...            
 1097 Dukhovni & Hardaker          Standards Track                   [Page 20]   

 1098 RFC 7671                     DANE Operations                October 2015   
 1101    The next case to consider is adding or switching to a new combination   
 1102    of TLSA parameters.  In this case, publish the new parameter            
 1103    combinations for the server's existing certificate chain first, and     
 1104    only then deploy new keys if desired:                                   
 1106    ; Initial TLSA RRset.                                                   
 1107    ;                                                                       
 1108    _443._tcp.www.example.org. IN TLSA 1 1 1 01d09d19c2139a46...            
 1110    ; New TLSA RRset, same key re-published as DANE-EE(3).                  
 1111    ;                                                                       
 1112    _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...            
 1114 8.2.  Switching to DANE-TA(2) from DANE-EE(3)                              
 1116    This section explains how to migrate to a new certificate chain and     
 1117    TLSA record with usage DANE-TA(2) from a self-signed server             
 1118    certificate and a "DANE-EE(3) SPKI(1) SHA2-256(1)" TLSA record.  This   
 1119    example assumes that a new private key is generated in conjunction      
 1120    with transitioning to a new certificate issued by the desired TA.       
 1122    The original "3 1 1" TLSA record supports [RFC7250] raw public keys,    
 1123    and clients may choose to negotiate their use.  The use of raw public   
 1124    keys rules out the possibility of certificate chain verification.       
 1125    Therefore, the transitional TLSA record for the planned DANE-TA(2)      
 1126    certificate chain is a "3 1 1" record that works even when raw public   
 1127    keys are used.  The TLSA RRset is updated to use DANE-TA(2) only        
 1128    after the new chain is deployed and the "3 1 1" record matching the     
 1129    original key is dropped.                                                
 1131    This process follows the requirement that each combination of           
 1132    parameters present in the RRset is always sufficient to validate the    
 1133    server.  It avoids publishing a transitional TLSA RRset in which        
 1134    "3 1 1" matches only the current key and "2 0 1" matches only the       
 1135    future certificate chain, because these might not work reliably         
 1136    during the initial deployment of the new keys.                          
 1152 Dukhovni & Hardaker          Standards Track                   [Page 21]   

 1153 RFC 7671                     DANE Operations                October 2015   
 1156    ; Initial TLSA RRset.                                                   
 1157    ;                                                                       
 1158    _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...            
 1160    ; Transitional TLSA RRset, published at least two TTLs before the       
 1161    ; actual key change.  The new keys are issued by a DANE-TA(2) CA        
 1162    ; but are initially specified via a DANE-EE(3) association.             
 1163    ;                                                                       
 1164    _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...            
 1165    _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...            
 1167    ; The final TLSA RRset after the key change.  Now that the old          
 1168    ; self-signed EE key is out of the picture, publish the issuing         
 1169    ; TA of the new chain.                                                  
 1170    ;                                                                       
 1171    _443._tcp.www.example.org. IN TLSA 2 0 1 c57bce38455d9e3d...            
 1173 8.3.  Switching to New TLSA Parameters                                     
 1175    When employing a new digest algorithm in the TLSA RRset, for            
 1176    compatibility with digest algorithm agility as specified in Section 9   
 1177    below, administrators SHOULD publish the new digest algorithm with      
 1178    each combination of certificate usage and selector for each             
 1179    associated key or chain used with any other digest algorithm.  When     
 1180    removing an algorithm, remove it entirely.  Each digest algorithm       
 1181    employed SHOULD match the same set of chains (or raw public keys).      
 1183    ; Initial TLSA RRset with "DANE-EE(3) SHA2-256(1)" associations         
 1184    ; for two keys.                                                         
 1185    ;                                                                       
 1186    _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...            
 1187    _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...            
 1189    ; New TLSA RRset, also with SHA2-512(2) associations                    
 1190    ; for each key.                                                         
 1191    ;                                                                       
 1192    _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...            
 1193    _443._tcp.www.example.org. IN TLSA 3 1 2 d9947c35089310bc...            
 1194    _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...            
 1195    _443._tcp.www.example.org. IN TLSA 3 1 2 89a7486a4b6ae714...            
 1207 Dukhovni & Hardaker          Standards Track                   [Page 22]   

 1208 RFC 7671                     DANE Operations                October 2015   
 1211 8.4.  TLSA Publisher Requirements: Summary                                 
 1213    In summary, server operators updating TLSA records should make one      
 1214    change at a time.  The individual safe changes are as follows:          
 1216    o  Pre-publish new certificate associations that employ the same TLSA   
 1217       parameters (usage, selector, and matching type) as existing TLSA     
 1218       records, but match certificate chains that will be deployed in the   
 1219       near future.                                                         
 1221    o  Wait for stale TLSA RRsets to expire from DNS caches before          
 1222       configuring servers to use the new certificate chain.                
 1224    o  Remove TLSA records matching any certificate chains that are no      
 1225       longer deployed.                                                     
 1227    o  Publish TLSA RRsets in which all parameter combinations              
 1228       (certificate usage, selector, and matching type) present in the      
 1229       RRset match the same set of current and planned certificate          
 1230       chains.                                                              
 1232    The above steps are intended to ensure that at all times, and for       
 1233    each combination of usage, selector, and matching type, at least one    
 1234    TLSA record corresponds to the server's current certificate chain.      
 1235    Each combination of certificate usage, selector, and matching type in   
 1236    a server's TLSA RRset SHOULD NOT at any time (including unexpired       
 1237    RRsets in client caches) match only some combination of future or       
 1238    past certificate chains.  As a result, no matter what combinations of   
 1239    usage, selector, and matching type may be supported by a given          
 1240    client, they will be sufficient to authenticate the server.             
 1242 9.  Digest Algorithm Agility                                               
 1244    While [RFC6698] specifies multiple digest algorithms, it does not       
 1245    specify a protocol by which the client and TLSA record publisher can    
 1246    agree on the strongest shared algorithm.  Such a protocol would allow   
 1247    the client and server to avoid exposure to deprecated weaker            
 1248    algorithms that are published for compatibility with less capable       
 1249    clients but that SHOULD be avoided when possible.  Such a protocol is   
 1250    specified below.                                                        
 1252    This section defines a protocol for avoiding deprecated digest          
 1253    algorithms when these are published in a peer's TLSA RRset alongside    
 1254    stronger digest algorithms.  Note that this protocol never avoids RRs   
 1255    with a DANE matching type of Full(0), as these do not employ a digest   
 1256    algorithm that might someday be weakened by cryptanalysis.              
 1262 Dukhovni & Hardaker          Standards Track                   [Page 23]   

 1263 RFC 7671                     DANE Operations                October 2015   
 1266    Client implementations SHOULD implement a default order of digest       
 1267    algorithms by strength.  This order SHOULD be configurable by the       
 1268    administrator or user of the client software.  If possible, a           
 1269    configurable mapping from numeric DANE TLSA matching types to           
 1270    underlying digest algorithms provided by the cryptographic library      
 1271    SHOULD be implemented to allow new matching types to be used with       
 1272    software that predates their introduction.  Configurable ordering of    
 1273    digest algorithms SHOULD be extensible to any new digest algorithms.    
 1275    To make digest algorithm agility possible, all published DANE TLSA      
 1276    RRsets MUST conform to the requirements of Section 8.  Clients SHOULD   
 1277    use digest algorithm agility when processing the peer's DANE TLSA       
 1278    records.  Algorithm agility is to be applied after first discarding     
 1279    any unusable or malformed records (unsupported digest algorithm, or     
 1280    incorrect digest length).  For each usage and selector, the client      
 1281    SHOULD process only any usable records with a matching type of          
 1282    Full(0) and the usable records whose digest algorithm is considered     
 1283    by the client to be the strongest among usable records with the given   
 1284    usage and selector.                                                     
 1286    Example: a client implements digest algorithm agility and prefers       
 1287    SHA2-512(2) over SHA2-256(1), while the server publishes an RRset       
 1288    that employs both digest algorithms as well as a Full(0) record.        
 1290    _25._tcp.mail.example.com. IN TLSA 3 1 1 (                              
 1291                                  3FE246A848798236DD2AB78D39F0651D          
 1292                                  6B6E7CA8E2984012EB0A2E1AC8A87B72 )        
 1293    _25._tcp.mail.example.com. IN TLSA 3 1 2 (                              
 1294                                  D4F5AF015B46C5057B841C7E7BAB759C          
 1295                                  BF029526D29520C5BE6A32C67475439E          
 1296                                  54AB3A945D80C743347C9BD4DADC9D8D          
 1297                                  57FAB78EAA835362F3CA07CCC19A3214 )        
 1298    _25._tcp.mail.example.com. IN TLSA 3 1 0 (                              
 1299                                  3059301306072A8648CE3D020106082A          
 1300                                  8648CE3D0301070342000471CB1F504F          
 1301                                  9E4B33971376C005445DACD33CD79A28          
 1302                                  81C3DED1981F18E7AAA76609DD0E4EF2          
 1303                                  8265C82703030AD60C5DBA6FB8A9397A          
 1304                                  C0FCF06D424C885D484887 )                  
 1306    In this case, the client SHOULD accept a server public key that         
 1307    matches either the "3 1 0" record or the "3 1 2" record, but it         
 1308    SHOULD NOT accept keys that match only the weaker "3 1 1" record.       
 1317 Dukhovni & Hardaker          Standards Track                   [Page 24]   

 1318 RFC 7671                     DANE Operations                October 2015   
 1321 10.  General DANE Guidelines                                               
 1323    These guidelines provide guidance for using or designing protocols      
 1324    for DANE.                                                               
 1326 10.1.  DANE DNS Record Size Guidelines                                     
 1328    Selecting a combination of TLSA parameters to use requires careful      
 1329    thought.  One important consideration to take into account is the       
 1330    size of the resulting TLSA record after its parameters are selected.    
 1332 10.1.1.  UDP and TCP Considerations                                        
 1334    Deployments SHOULD avoid TLSA record sizes that cause UDP               
 1335    fragmentation.                                                          
 1337    Although DNS over TCP would provide the ability to more easily          
 1338    transfer larger DNS records between clients and servers, it is not      
 1339    universally deployed and is still prohibited by some firewalls.         
 1340    Clients that request DNS records via UDP typically only use TCP upon    
 1341    receipt of a truncated response in the DNS response message sent over   
 1342    UDP.  Setting the Truncation (TC) bit (Section 4.1.1 of [RFC1035])      
 1343    alone will be insufficient if the response containing the TC bit is     
 1344    itself fragmented.                                                      
 1346 10.1.2.  Packet Size Considerations for TLSA Parameters                    
 1348    Server operators SHOULD NOT publish TLSA records using both a TLSA      
 1349    selector of Cert(0) and a TLSA matching type of Full(0), as even a      
 1350    single certificate is generally too large to be reliably delivered      
 1351    via DNS over UDP.  Furthermore, two TLSA records containing full        
 1352    certificates will need to be published simultaneously during a          
 1353    certificate rollover, as discussed in Section 8.1.                      
 1355    While TLSA records using a TLSA selector of SPKI(1) and a TLSA          
 1356    matching type of Full(0) (which publish the bare public keys, i.e.,     
 1357    without the overhead of encapsulating the keys in an X.509              
 1358    certificate) are generally more compact, these are also best avoided    
 1359    when significantly larger than their digests.  Rather, servers SHOULD   
 1360    publish digest-based TLSA matching types in their TLSA records, in      
 1361    which case the complete corresponding certificate MUST be transmitted   
 1362    to the client in-band during the TLS handshake.  The certificate (or    
 1363    raw public key) can be easily verified using the digest value.          
 1365    In summary, the use of a TLSA matching type of Full(0) is               
 1366    NOT RECOMMENDED, and a digest-based matching type, such as              
 1367    SHA2-256(1), SHOULD be used instead.                                    
 1372 Dukhovni & Hardaker          Standards Track                   [Page 25]   

 1373 RFC 7671                     DANE Operations                October 2015   
 1376 10.2.  Certificate Name Check Conventions                                  
 1378    Certificates presented by a TLS server will generally contain a         
 1379    subjectAltName (SAN) extension or a Common Name (CN) element within     
 1380    the subject Distinguished Name (DN).  The TLS server's DNS domain       
 1381    name is normally published within these elements, ideally within the    
 1382    SAN extension.  (The use of the CN field for this purpose is            
 1383    deprecated.)                                                            
 1385    When a server hosts multiple domains at the same transport endpoint,    
 1386    the server's ability to respond with the right certificate chain is     
 1387    predicated on correct SNI information from the client.  DANE clients    
 1388    MUST send the SNI extension with a HostName value of the base domain    
 1389    of the TLSA RRset.                                                      
 1391    With the exception of TLSA certificate usage DANE-EE(3), where name     
 1392    checks are not applicable (see Section 5.1), DANE clients MUST verify   
 1393    that the client has reached the correct server by checking that the     
 1394    server name is listed in the server certificate's SAN or CN (when       
 1395    still supported).  The primary server name used for this comparison     
 1396    MUST be the TLSA base domain; however, additional acceptable names      
 1397    may be specified by protocol-specific DANE standards.  For example,     
 1398    with SMTP, both the destination domain name and the MX hostname are     
 1399    acceptable names to be found in the server certificate (see             
 1400    [RFC7672]).                                                             
 1402    It is the responsibility of the service operator, in coordination       
 1403    with the TLSA Publisher, to ensure that at least one of the TLSA        
 1404    records published for the service will match the server's certificate   
 1405    chain (either the default chain or the certificate that was selected    
 1406    based on the SNI information provided by the client).                   
 1408    Given the DNSSEC-validated DNS records below:                           
 1410    example.com.               IN MX 0 mail.example.com.                    
 1411    mail.example.com.          IN A                               
 1412    _25._tcp.mail.example.com. IN TLSA 2 0 1 (                              
 1413                                  E8B54E0B4BAA815B06D3462D65FBC7C0          
 1414                                  CF556ECCF9F5303EBFBB77D022F834C0 )        
 1416    The TLSA base domain is "mail.example.com" and is required to be the    
 1417    HostName in the client's SNI extension.  The server certificate chain   
 1418    is required to be signed by a TA with the above certificate SHA2-256    
 1419    digest.  Finally, one of the DNS names in the server certificate is     
 1420    required to be either "mail.example.com" or "example.com" (this         
 1421    additional name is a concession to compatibility with prior practice;   
 1422    see [RFC7672] for details).                                             
 1427 Dukhovni & Hardaker          Standards Track                   [Page 26]   

 1428 RFC 7671                     DANE Operations                October 2015   
 1431    [RFC6125] specifies the semantics of wildcards in server certificates   
 1432    for various application protocols.  DANE does not change how            
 1433    wildcards are treated by any given application.                         
 1435 10.3.  Design Considerations for Protocols Using DANE                      
 1437    When a TLS client goes to the trouble of authenticating a certificate   
 1438    chain presented by a TLS server, it will typically not continue to      
 1439    use that server in the event of authentication failure, or else         
 1440    authentication serves no purpose.  Some clients may, at times,          
 1441    operate in an "audit" mode, where authentication failure is reported    
 1442    to the user or in logs as a potential problem, but the connection       
 1443    proceeds despite the failure.  Nevertheless, servers publishing TLSA    
 1444    records MUST be configured to allow correctly configured clients to     
 1445    successfully authenticate their TLS certificate chains.                 
 1447    A service with DNSSEC-validated TLSA records implicitly promises TLS    
 1448    support.  When all the TLSA records for a service are found             
 1449    "unusable" due to unsupported parameter combinations or malformed       
 1450    certificate association data, DANE clients cannot authenticate the      
 1451    service certificate chain.  When authenticated TLS is mandatory, the    
 1452    client MUST NOT connect to the associated server.                       
 1454    If, on the other hand, the use of TLS and DANE is "opportunistic"       
 1455    [RFC7435], then when all TLSA records are unusable, the client SHOULD   
 1456    connect to the server via an unauthenticated TLS connection, and if     
 1457    TLS encryption cannot be established, the client MUST NOT connect to    
 1458    the server.                                                             
 1460    Standards for opportunistic DANE TLS specific to a particular           
 1461    application protocol may modify the above requirements.  The key        
 1462    consideration is whether or not mandating the use of                    
 1463    (unauthenticated) TLS even with unusable TLSA records is asking for     
 1464    more security than one can realistically expect.  If expecting TLS      
 1465    support when unusable TLSA records are published is realistic for the   
 1466    application in question, then the application MUST avoid cleartext.     
 1467    If not realistic, then mandating TLS would cause clients (even in the   
 1468    absence of active attacks) to run into problems with various peers      
 1469    that do not interoperate "securely enough".  That would create strong   
 1470    incentives to just disable Opportunistic Security and stick with        
 1471    cleartext.                                                              
 1482 Dukhovni & Hardaker          Standards Track                   [Page 27]   

 1483 RFC 7671                     DANE Operations                October 2015   
 1486 11.  Note on DNSSEC Security                                               
 1488    Clearly, the security of the DANE TLSA PKI rests on the security of     
 1489    the underlying DNSSEC infrastructure.  While this document is not a     
 1490    guide to DNSSEC security, a few comments may be helpful to TLSA         
 1491    implementers.                                                           
 1493    With the existing public CA Web PKI, name constraints are rarely        
 1494    used, and a public root CA can issue certificates for any domain of     
 1495    its choice.  With DNSSEC, under the Registry/Registrar/Registrant       
 1496    model, the situation is different: only the registrar of record can     
 1497    update a domain's DS record [RFC4034] in the registry parent zone (in   
 1498    some cases, however, the registry is the sole registrar).  With many    
 1499    Generic Top-Level Domains (gTLDs) for which multiple registrars         
 1500    compete to provide domains in a single registry, it is important to     
 1501    make sure that rogue registrars cannot easily initiate an               
 1502    unauthorized domain transfer and thus take over DNSSEC for the          
 1503    domain.  DNS operators are advised to set a registrar lock on their     
 1504    domains to offer some protection against this possibility.              
 1506    When the registrar is also the DNS operator for the domain, one needs   
 1507    to consider whether or not the registrar will allow orderly migration   
 1508    of the domain to another registrar or DNS operator in a way that will   
 1509    maintain DNSSEC integrity.  TLSA Publishers are advised to seek out a   
 1510    DNS hosting registrar that makes it possible to transfer domains to     
 1511    another hosting provider without disabling DNSSEC.                      
 1513    DNSSEC-signed RRsets cannot be securely revoked before they expire.     
 1514    Operators need to plan accordingly and not generate signatures of       
 1515    excessively long duration.  For domains publishing high-value keys, a   
 1516    signature lifetime (length of the "signature validity period" as        
 1517    described in Section 8.1 of [RFC4033]) of a few days is reasonable,     
 1518    and the zone can be re-signed daily.  For domains with less critical    
 1519    data, a reasonable signature lifetime is a couple of weeks to a         
 1520    month, and the zone can be re-signed weekly.                            
 1522    Short signature lifetimes require tighter synchronization of primary    
 1523    and secondary nameservers, to make sure that secondary servers never    
 1524    serve records with expired signatures.  They also limit the maximum     
 1525    time for which a primary server that signs the zone can be down.        
 1526    Therefore, short signature lifetimes are more appropriate for sites     
 1527    with dedicated operations staff, who can restore service quickly in     
 1528    case of a problem.                                                      
 1530    Monitoring is important.  If a DNS zone is not re-signed in a timely    
 1531    manner, a major outage is likely, as the entire domain and all its      
 1532    sub-domains become "bogus".                                             
 1537 Dukhovni & Hardaker          Standards Track                   [Page 28]   

 1538 RFC 7671                     DANE Operations                October 2015   
 1541 12.  Summary of Updates to RFC 6698                                        
 1543    o  Section 3 updates [RFC6698] to specify a requirement for clients     
 1544       to support at least TLS 1.0 and to support SNI.                      
 1546    o  Section 4 explains that application support for all four             
 1547       certificate usages is NOT RECOMMENDED.  The recommended design is    
 1548       to support just DANE-EE(3) and DANE-TA(2).                           
 1550    o  Section 5.1 updates [RFC6698] to specify that peer identity          
 1551       matching and validity period enforcement are based solely on the     
 1552       TLSA RRset properties.  It also specifies DANE authentication of     
 1553       raw public keys [RFC7250] via TLSA records with certificate usage    
 1554       DANE-EE(3) and selector SPKI(1).                                     
 1556    o  Section 5.2 updates [RFC6698] to require that servers publishing     
 1557       digest TLSA records with a usage of DANE-TA(2) MUST include the      
 1558       TA certificate in their TLS server certificate message.  This        
 1559       extends to the case of "2 1 0" TLSA records that publish a full      
 1560       public key.                                                          
 1562    o  Section 5.4 observes that with usage PKIX-TA(0), clients may need    
 1563       to process extended trust chains beyond the first trusted issuer     
 1564       when that issuer is not self-signed.                                 
 1566    o  Section 7 recommends that DANE application protocols specify that,   
 1567       when possible, securely CNAME-expanded names be used to derive the   
 1568       TLSA base domain.                                                    
 1570    o  Section 8 specifies a strategy for managing TLSA records that        
 1571       interoperates with DANE clients regardless of what subset of the     
 1572       possible TLSA record types (combinations of TLSA parameters) is      
 1573       supported by the client.                                             
 1575    o  Section 9 specifies a digest algorithm agility protocol.             
 1577    o  Section 10.1 recommends against the use of Full(0) TLSA records,     
 1578       as digest records are generally much more compact.                   
 1580 13.  Operational Considerations                                            
 1582    The DNS TTL of TLSA records needs to be chosen with care.  When an      
 1583    unplanned change in the server's certificate chain and TLSA RRset is    
 1584    required, such as when keys are compromised or lost, clients that       
 1585    cache stale TLSA records will fail to validate the certificate chain    
 1586    of the updated server.  Publish TLSA RRsets with TTLs that are short    
 1587    enough to limit unplanned service disruption to an acceptable           
 1588    duration.                                                               
 1592 Dukhovni & Hardaker          Standards Track                   [Page 29]   

 1593 RFC 7671                     DANE Operations                October 2015   
 1596    The signature lifetime (length of the signature validity period) for    
 1597    TLSA records SHOULD NOT be too long.  Signed DNSSEC records can be      
 1598    replayed by an MITM attacker, provided the signatures have not yet      
 1599    expired.  Shorter signature validity periods allow for faster           
 1600    invalidation of compromised keys.  Zone refresh and expiration times    
 1601    for secondary nameservers often imply a lower bound on the signature    
 1602    validity period (Section 11).  See Section 4.4.1 of [RFC6781].          
 1604 14.  Security Considerations                                               
 1606    Application protocols that cannot use the existing public CA Web PKI    
 1607    may choose to not implement certain TLSA record types defined in        
 1608    [RFC6698].  If such records are published despite not being supported   
 1609    by the application protocol, they are treated as "unusable".  When      
 1610    TLS is opportunistic, the client MAY proceed to use the server with     
 1611    mandatory unauthenticated TLS.  This is stronger than opportunistic     
 1612    TLS without DANE, since in that case the client may also proceed with   
 1613    a cleartext connection.  When TLS is not opportunistic, the client      
 1614    MUST NOT connect to the server.                                         
 1616    Thus, when TLSA records are used with opportunistic protocols where     
 1617    PKIX-TA(0) and PKIX-EE(1) do not apply, the recommended protocol        
 1618    design is for servers to not publish such TLSA records, and for         
 1619    opportunistic TLS clients to use them to only enforce the use of        
 1620    (albeit unauthenticated) TLS but otherwise treat them as unusable.      
 1621    Of course, when PKIX-TA(0) and PKIX-EE(1) are supported by the          
 1622    application protocol, clients MUST implement these certificate usages   
 1623    as described in [RFC6698] and this document.                            
 1625 15.  References                                                            
 1627 15.1.  Normative References                                                
 1629    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate          
 1630               Requirement Levels", BCP 14, RFC 2119,                       
 1631               DOI 10.17487/RFC2119, March 1997,                            
 1632               <http://www.rfc-editor.org/info/rfc2119>.                    
 1634    [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.      
 1635               Rose, "DNS Security Introduction and Requirements",          
 1636               RFC 4033, DOI 10.17487/RFC4033, March 2005,                  
 1637               <http://www.rfc-editor.org/info/rfc4033>.                    
 1639    [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.      
 1640               Rose, "Resource Records for the DNS Security Extensions",    
 1641               RFC 4034, DOI 10.17487/RFC4034, March 2005,                  
 1642               <http://www.rfc-editor.org/info/rfc4034>.                    
 1647 Dukhovni & Hardaker          Standards Track                   [Page 30]   

 1648 RFC 7671                     DANE Operations                October 2015   
 1651    [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.      
 1652               Rose, "Protocol Modifications for the DNS Security           
 1653               Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,     
 1654               <http://www.rfc-editor.org/info/rfc4035>.                    
 1656    [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security    
 1657               (TLS) Protocol Version 1.2", RFC 5246,                       
 1658               DOI 10.17487/RFC5246, August 2008,                           
 1659               <http://www.rfc-editor.org/info/rfc5246>.                    
 1661    [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,          
 1662               Housley, R., and W. Polk, "Internet X.509 Public Key         
 1663               Infrastructure Certificate and Certificate Revocation List   
 1664               (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,    
 1665               <http://www.rfc-editor.org/info/rfc5280>.                    
 1667    [RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)            
 1668               Extensions: Extension Definitions", RFC 6066,                
 1669               DOI 10.17487/RFC6066, January 2011,                          
 1670               <http://www.rfc-editor.org/info/rfc6066>.                    
 1672    [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and           
 1673               Verification of Domain-Based Application Service Identity    
 1674               within Internet Public Key Infrastructure Using X.509        
 1675               (PKIX) Certificates in the Context of Transport Layer        
 1676               Security (TLS)", RFC 6125, DOI 10.17487/RFC6125,             
 1677               March 2011, <http://www.rfc-editor.org/info/rfc6125>.        
 1679    [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer      
 1680               Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,       
 1681               January 2012, <http://www.rfc-editor.org/info/rfc6347>.      
 1683    [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication   
 1684               of Named Entities (DANE) Transport Layer Security (TLS)      
 1685               Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698,             
 1686               August 2012, <http://www.rfc-editor.org/info/rfc6698>.       
 1688    [RFC7218]  Gudmundsson, O., "Adding Acronyms to Simplify                
 1689               Conversations about DNS-Based Authentication of Named        
 1690               Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218,            
 1691               April 2014, <http://www.rfc-editor.org/info/rfc7218>.        
 1693    [RFC7250]  Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,          
 1694               Weiler, S., and T. Kivinen, "Using Raw Public Keys in        
 1695               Transport Layer Security (TLS) and Datagram Transport        
 1696               Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,      
 1697               June 2014, <http://www.rfc-editor.org/info/rfc7250>.         
 1702 Dukhovni & Hardaker          Standards Track                   [Page 31]   

 1703 RFC 7671                     DANE Operations                October 2015   
 1706 15.2.  Informative References                                              
 1708    [RFC1035]  Mockapetris, P., "Domain names - implementation and          
 1709               specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,      
 1710               November 1987, <http://www.rfc-editor.org/info/rfc1035>.     
 1712    [RFC6781]  Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC             
 1713               Operational Practices, Version 2", RFC 6781,                 
 1714               DOI 10.17487/RFC6781, December 2012,                         
 1715               <http://www.rfc-editor.org/info/rfc6781>.                    
 1717    [RFC6962]  Laurie, B., Langley, A., and E. Kasper, "Certificate         
 1718               Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,    
 1719               <http://www.rfc-editor.org/info/rfc6962>.                    
 1721    [RFC7435]  Dukhovni, V., "Opportunistic Security: Some Protection       
 1722               Most of the Time", RFC 7435, DOI 10.17487/RFC7435,           
 1723               December 2014, <http://www.rfc-editor.org/info/rfc7435>.     
 1725    [RFC7672]  Dukhovni, V. and W. Hardaker, "SMTP Security via             
 1726               Opportunistic DNS-Based Authentication of Named Entities     
 1727               (DANE) Transport Layer Security (TLS)", RFC 7672,            
 1728               DOI 10.17487/RFC7672, October 2015,                          
 1729               <http://www.rfc-editor.org/info/rfc7672>.                    
 1731    [RFC7673]  Finch, T., Miller, M., and P. Saint-Andre, "Using            
 1732               DNS-Based Authentication of Named Entities (DANE) TLSA       
 1733               Records with SRV Records", RFC 7673, DOI 10.17487/RFC7673,   
 1734               October 2015, <http://www.rfc-editor.org/info/rfc7673>.      
 1757 Dukhovni & Hardaker          Standards Track                   [Page 32]   

 1758 RFC 7671                     DANE Operations                October 2015   
 1761 Acknowledgements                                                           
 1763    The authors would like to thank Phil Pennock for his comments and       
 1764    advice on this document.                                                
 1766    Acknowledgements from Viktor: Thanks to Tony Finch, who finally         
 1767    prodded me into participating in DANE working group discussions.        
 1768    Thanks to Paul Hoffman, who motivated me to produce this document and   
 1769    provided feedback on early draft versions of it.  Thanks also to        
 1770    Samuel Dukhovni for editorial assistance.                               
 1772 Authors' Addresses                                                         
 1774    Viktor Dukhovni                                                         
 1775    Two Sigma                                                               
 1777    Email: ietf-dane@dukhovni.org                                           
 1780    Wes Hardaker                                                            
 1781    Parsons                                                                 
 1782    P.O. Box 382                                                            
 1783    Davis, CA  95617                                                        
 1784    United States                                                           
 1786    Email: ietf@hardakers.net                                               
 1812 Dukhovni & Hardaker          Standards Track                   [Page 33]   

The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.

This RFC is included in the DNS RFCs annotation project whose home page is here.