One document matched: draft-ietf-dane-protocol-08.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2818 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.xml">
<!ENTITY rfc4025 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4025.xml">
<!ENTITY rfc4033 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY rfc4034 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4034.xml">
<!ENTITY rfc4035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4035.xml">
<!ENTITY rfc4255 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4255.xml">
<!ENTITY rfc5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY rfc5280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict='yes'?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc strict="no" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc ipr="trust200902"
docName="draft-ietf-dane-protocol-08"
category="std"
>
<front>
<title abbrev="DNS Cert Linkage for TLS">
Using Secure DNS to Associate Certificates with Domain Names For TLS</title>
<author initials='P.' surname="Hoffman" fullname='Paul Hoffman'>
<organization>VPN Consortium</organization>
<address>
<email>paul.hoffman@vpnc.org</email>
</address>
</author>
<author initials="J." surname="Schlyter" fullname="Jakob Schlyter">
<organization>Kirei AB</organization>
<address>
<email>jakob@kirei.se</email>
</address>
</author>
<date month="July" year="2011"/>
<abstract>
<t>TLS and DTLS use PKIX certificates for authenticating the server. Users
want their applications to verify that the certificate provided by the TLS
server is in fact associated with the domain name they expect. TLSA provides
bindings of keys to domains that are asserted not by external entities, but by the
entities that operate the DNS. This document describes how to use secure DNS
to associate the TLS server's certificate with the intended domain name.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The first response from the server in TLS may contain a certificate. In
order for the TLS client to authenticate that it is talking to the expected
TLS server, the client must validate that this certificate is associated with
the domain name used by the client to get to the server. Currently, the client
must extract the domain name from the certificate, must trust a trust anchor
upon which the server's certificate is rooted, and must successfully validate
the certificate.</t>
<t>Some people want a different way to authenticate the association of the
server's certificate with the intended domain name without trusting an
external certificate authority (CA). Given that the DNS administrator for a
domain name is authorized to give identifying information about the zone, it
makes sense to allow that administrator to also make an authoritative binding
between the domain name and a certificate that might be used by a host at that
domain name. The easiest way to do this is to use the DNS.</t>
<t>There are many use cases for such functionality. <xref
target="DANEUSECASES"/> lists the ones that the protocol in this document is
meant to apply to. <xref target="DANEUSECASES"/> also lists many requirements,
most of which the protocol in this document is believed to meet.
Section 5 covers the applicability of this document to the use cases
in detail.</t>
<t>This document applies to both TLS <xref target='RFC5246'/> and DTLS <xref
target='RFC4347bis'/>. In order to make the document more readable, it mostly
only talks about "TLS", but in all cases, it means "TLS or DTLS". This
document only relates to securely associating certificates for TLS and DTLS
with host names; other security protocols and other forms of identification of
TLS servers (such as IP addresses) are handled in other documents. For
example, keys for IPsec are covered in <xref target='RFC4025'/> and keys for
SSH are covered in <xref target='RFC4255'/>.</t>
<section title="Certificate Associations">
<t>In this document, a certificate association is based on a cryptographic
hash of a certificate (sometimes called a "fingerprint"), a public key, or on the certificate
itself. For a fingerprint, a hash is taken of the binary, DER-encoded
certificate or public key, and that hash is the certificate association; the type of hash
function used can be chosen by the DNS administrator. When using the
certificate itself in the certificate association, the entire certificate in
the normal format is used. This document only applies to PKIX <xref
target="RFC5280"/> certificates, not certificates of other formats.
It also applies to public keys that are extracted from PKIX certificates,
not just full certificates.</t>
<t>Certificate associations are made between a certificate or public key
and a domain name. Server software that is running TLS that is
found at that domain name would use a certificate that has a certificate
association given in the DNS, as described in this document. A DNS query can
return multiple certificate associations, such as in the case of different
server software on a single host using different certificates, or in the case
that a server is changing from one certificate to another.</t>
</section>
<section title="Securing Certificate Associations">
<t>This document defines a secure method to associate the certificate that is
obtained from the TLS server with a domain name using DNS;
the DNS information may need to be be protected by DNSSEC.
Because the certificate association was retrieved based on a DNS query, the
domain name in the query is by definition associated with the certificate.</t>
<t>DNSSEC, which is defined in RFCs 4033, 4034, and 4035 (<xref
target='RFC4033'/>, <xref target='RFC4034'/>, and <xref target='RFC4035'/>),
uses cryptographic keys and digital signatures to provide authentication of
DNS data. Information retrieved from the DNS and that is validated using
DNSSEC is thereby proved to be the authoritative data. The DNSSEC signature
MUST be validated on all responses that use DNSSEC in order to assure the
proof of origin of the data.</t>
<t>This document only relates to securely getting the DNS information for the
certificate association using DNSSEC; other secure DNS mechanisms are out of
scope.</t>
</section>
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in RFC 2119 <xref target='RFC2119'/>.</t>
<t>A note on terminology: Some people have said that this protocol is a form
of "certificate exclusion". This is true, but only in the sense that a DNS
reply that contains the certificate types defined here inherently excludes
every other possible certificate in the universe (other than those found with
a pre-image attack against one of those two). The certificate type defined
here is better thought of as "enumeration" of a small number of certificate
associations, not "exclusion" of a near-infinite number of other
certificates.</t>
</section>
</section>
<section title="The TLSA Resource Record">
<t>The TLSA DNS resource record (RR) is used to associate a certificate with
the domain name where the record is found. The semantics of how the TLSA
RR is interpreted are given later in this document.</t>
<t>The type value for the TLSA RR type is TBD.</t>
<t>The TLSA RR is class independent.</t>
<t>The TLSA RR has no special TTL requirements.</t>
<section title="TLSA RDATA Wire Format">
<t>The RDATA for a TLSA RR consists of a one octet certificate type field, a
one octet reference type field and the certificate for association field.
<figure><artwork><![CDATA[
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cert type | Ref type | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
/ /
/ Certificate for association /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
</t>
<section title="The Certificate Type Field">
<t>A one-octet value, called "certificate type", specifying the provided
association that will be used to match the target certificate. This will be an
IANA registry in order to make it easier to add additional certificate types
in the future. The types defined in this document are:
<list style='empty'>
<t>1 -- A PKIX certificate that identifies an end entity</t>
<t>2 -- A PKIX certification authority's certificate</t>
<t>3 -- A public key expressed as a PKIX SubjectPublicKeyInfo structure</t>
</list>
All three types are structured using the RFC 5280 formatting rules and use the
DER encoding.</t>
<t>The three certificate types defined in this document explicitly only apply
to PKIX-formatted certificates. If TLS allows other formats later, or if
extensions to this protocol are made that accept other formats for
certificates, those certificates will need their own certificate types.</t>
</section>
<section title="The Reference Type Field">
<t>A one-octet value, called "reference type", specifying how the certificate
association is presented. This value is defined in a new IANA registry. The
types defined in this document are:
<list style='empty'>
<t>0 -- Full certificate</t>
<t>1 -- SHA-256 hash of the certificate</t>
<t>2 -- SHA-512 hash of the certificate</t>
</list>
Using the same hash algorithm as is used in the signature in the certificate
will make it more likely that the TLS client will understand this TLSA
data.</t>
</section>
<section title="The Certificate for Association Field">
<t>The "certificate for association". This is the bytes containing the full
certificate, SubjectPublicKeyInfo or the hash of the associated certificate or
SubjectPublicKeyInfo. For certificate types 1 and 2, this is the certificate
or the hash of the certificate itself, not of the TLS ASN.1Cert object.</t>
</section>
</section>
<section title="TLSA RR Presentation Format">
<t>The presentation format of the RDATA portion is as follows:
<list style='symbols'>
<t>The certificate type field MUST be represented as an unsigned decimal
integer.</t>
<t>The reference type field MUST be represented as an unsigned decimal
integer.</t>
<t>The certificate for association field MUST be represented as a string of
hexadecimal characters. Whitespace is allowed within the string of hexadecimal
characters.</t>
</list>
</t>
</section>
<section title="TLSA RR Examples">
<t>An example of a SHA-256 hash (type 1) of an end entity certificate (type 1)
would be:
<figure><artwork><![CDATA[
_443._tcp.www.example.com. IN TLSA (
1 1 5c1502a6549c423be0a0aa9d9a16904de5ef0f5c98
c735fcca79f09230aa7141 )
]]></artwork></figure>
</t>
<t>An example of an unhashed CA certificate (type 2) would be:
<figure><artwork><![CDATA[
_443._tcp.www.example.com. IN TLSA (
2 0 308202c5308201ada00302010202090... )
]]></artwork></figure>
</t>
</section>
</section>
<section title="Domain Names for TLS Certificate Associations">
<t>TLSA resource records are stored at a prefixed DNS domain name. The prefix
is prepared in the following manner:
<list style="numbers">
<t>The decimal representation of the port number on which a TLS-based service
is assumed to exist is prepended with an underscore character ("_") to become
the left-most label in the prepared domain name. This number has no leading
zeros.</t>
<t>The protocol name of the transport on which a TLS-based service is assumed
to exist is prepended with an underscore character ("_") to become the second
left-most label in the prepared domain name. The transport names defined for
this protocol are "tcp", "udp" and "sctp".</t>
<t>The domain name is appended to the result of step 2 to complete the
prepared domain name.</t>
</list></t>
<t>For example, to request a TLSA resource record for an HTTP server running
TLS on port 443 at "www.example.com", you would use
"_443._tcp.www.example.com" in the request. To request a TLSA resource record
for an SMTP server running the STARTTLS protocol on port 25 at
"mail.example.com", you would use "_25._tcp.mail.example.com".</t>
</section>
<section title="Semantics and Features of TLSA Certificate Types">
<t>The three certificate types have very different semantics, but also have
features common to all three types.</t>
<section title="End Entity Certificate">
<t>Certificate type 1 (a certificate that identifies an end entity) is matched
against the first certificate offered by the TLS server. The certificate for
association is used only for exact matching, not for chained validation. With
reference type 0, the certificate association is valid if the certificate in
the TLSA data matches to the first certificate offered by TLS. With reference
types other than 0, the certificate association is valid if the hash of the
first certificate offered by the TLS server matches the value from the TLSA
data.</t>
</section>
<section title="Certification Authority Certificate">
<t>Certificate type 2 (certification authority's certificate) can be used in
one of two ways. With reference type 0, the certificate in the TLSA resource
record is used in chaining from the end entity given in TLS. The certificate
association is valid if the first certificate in the certificate bundle can be
validly chained to the trust anchor from the TLSA data. With reference types
other than 0, if the hash of any certificate past the first in the certificate
bundle from TLS matches the trust anchor from the TLSA data, and the chain in
the certificate bundle is valid up to that TLSA trust anchor, then the
certificate association is valid. Alternately, if the first certificate
offered chains to an existing trust anchor in the TLS client's trust anchor
repository, and the hash of that trust anchor matches the value from the TLSA
data, then the certificate association is valid.</t>
</section>
<section title="Certificate Public Key">
<t>Certificate type 3 (public key expressed as a PKIX SubjectPublicKeyInfo
structure) is used to assert that the public key will appear in one of the
certificates received from the server. A server might choose this type for
many reasons, including (but not limited to):
<list style="symbols">
<t>the trust anchor to which TLS server's certificate chains might change
without the trust anchor's public key changing</t>
<t>the TLS server is using a self-signed certificate that is not marked as a
CA certificate</t>
</list>
A TLS client conforming to this protocol that receives a public key
in a type 3 certificate for association must be able to extract the
SubjectPublicKeyInfo from each of the certificates presented to it by the TLS
server. It then does a bit-for-bit comparison between the certificate for
association and the SubjectPublicKeyInfos in the certificates; if it does not
find a match, the client aborts the TLS handshake.</t>
</section>
<section title="Use of TLS Certificate Associations in TLS">
<t>A TLS client
conforming to this protocol receiving a certificate for association of type 1
MUST compare it for equality, using the specified reference type, with the end
entity certificate received in TLS. A TLS client conforming to this protocol
receiving a certificate for association of type 2 MUST treat it as a trust
anchor for that domain name. A TLS client conforming to this protocol
receiving a certificate for association of type 3 MUST find a matching
SubjectPublicKeyInfo structure in one of the certificates offered by the TLS
server.</t>
<t>The end entity certificate from TLS, regardless of whether it was matched
with a TLSA type 1 certificate or chained to a TLSA type 2 CA certificate,
might have at least one identifier in the subject or subjectAltName field of
the matched certificates that matches the expected identifier for the TLS
server. Some specifications for applications that run under TLS, such as <xref
target="RFC2818"/> for HTTP, require the server's certificate to have a domain
name that matches the host name expected by the client. Further, the TLS
session that is to be set up MUST be for the specific port number and
transport name that was given in the TLSA query. The matching or chaining MUST
be done within the life of the TTL on the TLSA record.</t>
<t>In order to use one or more TLS certificate associations described in this
document obtained from the DNS, an application MUST assure that the
certificates were obtained using DNS protected by DNSSEC. TLSA records must
only be trusted if they were obtained from a trusted source. This could be a
localhost DNS resolver answer with the AD bit set, an inline validating
resolver library primed with the proper trust anchors, or obtained from a
remote nameserver to which one has a secured channel of communication.</t>
<t>If a certificate association contains a reference type that is not
understood by the TLS client, that certificate association MUST be marked as
unusable.</t>
<t>An application that requests TLS certificate associations using the method
described in this document obtains zero or more usable certificate
associations. If the application receives zero usable certificate
associations, it processes TLS in the normal fashion.</t>
<t>If a match between one of the certificate association(s) and the server's
end entity certificate in TLS is found, the TLS client continues the TLS
handshake. If no match between the usable certificate association(s) and the
server's end entity certificate in TLS is found, the TLS client MUST abort the
handshake with an "access_denied" error.</t>
</section>
</section>
<section title="TLSA and DANE Use Cases and Requirements">
<t>The different types of certificates for association defined in TLSA are
matched with various sections of <xref target="DANEUSECASES"/>. [[ IMPORTANT
NOTICE, DANGER OF MOVING PARTS: this draft of the protocol is based on the -02
version of [DANEUSECASES]. As that document changes in the WG and IETF Last
Call, this protocol might change as well. ]]</t>
<t>The three use cases from section 3 of <xref target="DANEUSECASES"/> are covered
in this protocol as follows:</t>
<t><list style='hanging'>
<t hangText="3.1 CA Constraints"> -- Implemented using certificate type 2.
A hashed association is
recommended for well-known certification authorities.</t>
<t hangText="3.2 Certificate Constraints"> -- Implemented using certificate type 1.</t>
<t hangText="3.3 Domain-Issued Certificates"> -- Implemented using certificate type 1
combined with any reference type, or by using certificate type 2 together with a
full certificate association.</t>
</list></t>
<t>The requirements from section 4 of <xref target="DANEUSECASES"/> are covered
in this protocol as follows (note that some of these might be excessively
glib):</t>
<t><list style='hanging'>
<t hangText="Multiple Ports"> -- Covered in the TLSA request syntax.</t>
<t hangText="No Downgrade"> -- Covered by DNSSEC itself.</t>
<t hangText="Encapsulation"> -- Covered in the TLSA response semantics.</t>
<t hangText="Predictability"> -- Covered by this spec.</t>
<t hangText="Opportunistic Security"> -- Covered in the TLSA request syntax.</t>
<t hangText="Combination"> -- Covered in the TLSA response semantics.</t>
<t hangText="Roll-over"> -- Covered by the TTLs on the TLSA records.</t>
<t hangText="Simple Key Management"> -- Implemented using Certificate Type 3.</t>
<t hangText="Minimal Dependencies"> -- Covered in the TLSA response semantics.</t>
<t hangText="Minimal Options"> -- Covered in the TLSA response semantics.</t>
<t hangText="Wild Cards"> -- Covered in the TLSA request syntax.</t>
<t hangText="Redirection"> -- Covered in the TLSA request syntax.</t>
</list></t>
<!--
<t>Certificate type 1 (end entity certificate) is used for "certificate
constraints". Certificate type 2 (CA certificate) is used for "CA
constraints". Certificate type 3 (public key structure) is used for "CA
constraints" and "certificate constraints", depending on which certificate the
public key is extracted from. All three types are also used for "domain-issued
certificates" if the domain owner creates its own CA certificate and then
issues an end entity certificate from that CA. Note that <xref
target="DANEUSECASES"/> discusses "CA constraints" and "certificate
constraints" in terms of a "well-known CA"; TLSA extends this in some cases to
allow domain-issued (not-well-known) CAs.</t>
-->
</section>
<section title='Mandatory-to-Implement Algorithms'>
<t>DNS systems conforming to this specification MUST be able to create TLSA
records containing certificate types 1 and 2. DNS systems conforming to this
specification MUST be able to create TLSA records using reference type 0 (no
hash used) and reference type 1 (SHA-256), and SHOULD be able to create TLSA
records using reference type 2 (SHA-512).</t>
<t>TLS clients conforming to this specification MUST be able to correctly
interpret TLSA records containing certificate types 1, 2 and 3. TLS clients
conforming to this specification MUST be able to compare a certificate for
association with a certificate from TLS using reference type 0 (no hash used)
and reference type 1 (SHA-256), and SHOULD be able to make such comparisons
with reference type 2 (SHA-512).</t>
<t>At the time this is written, it is expected that there will be a new family
of hash algorithms called SHA-3 within the next few years. It is expected that
some of the SHA-3 algorithms will be mandatory and/or recommended for TLSA
records after the algorithms are fully defined. At that time, this
specification will be updated.</t>
</section>
<section title='IANA Considerations'>
<section title='TLSA RRtype'>
<t>This document uses a new DNS RR type, TLSA, whose value is TBD. A separate
request for the RR type will be submitted to the expert reviewer, and future
versions of this document will have that value instead of TBD.</t>
</section>
<section title='TLSA Certificate Types'>
<t>This document creates a new registry, "Certificate Types for TLSA Resource
Records". The registry policy is "RFC Required". The initial entries in the
registry are:
<figure><artwork><![CDATA[
Value Short description Reference
----------------------------------------------------------
0 Reserved [This]
1 Certificate to identify an end entity [This]
2 CA's certificate [This]
3 Public key as SubjectPublicKeyInfo [This]
4-254 Unassigned
255 Private use
]]></artwork></figure></t>
<t>Applications to the registry can request specific values that have yet to
be assigned.</t>
</section>
<section title='TLSA Hash Types'>
<t>This document creates a new registry, "Hash Types for TLSA Resource
Records". The registry policy is "Specification Required". The initial entries
in the registry are:
<figure><artwork><![CDATA[
Value Short description Reference
---------------------------------------------
0 No hash used [This]
1 SHA-256 NIST FIPS 180-3
2 SHA-512 NIST FIPS 180-3
3-254 Unassigned
255 Private use
]]></artwork></figure></t>
<t>Applications to the registry can request specific values that have yet to
be assigned.</t>
</section>
</section>
<section title='Security Considerations'>
<t>The security of the protocols described in this document relies on the
security of DNSSEC as used by the client requesting A/AAAA and TLSA
records.</t>
<t>A DNS administrator who goes rogue and changes both the A/AAAA and TLSA
records for a domain name can cause the user to go to an unauthorized server
that will appear authorized, unless the client performs certificate validation
and rejects the certificate. That administrator could probably get a
certificate issued anyway, so this is not an additional threat.</t>
<t>If the authentication mechanism for adding or changing TLSA data in a zone
is weaker than the authentication mechanism for changing the A/AAAA records, a
man-in-the-middle who can redirect traffic to their site may be able to
impersonate the attacked host in TLS if they can use the weaker authentication
mechanism. A better design for authenticating DNS would be to have the same
level of authentication used for all DNS additions and changes for a
particular host.</t>
<t>SSL proxies can sometimes act as a man-in-the-middle for TLS clients. In
these scenarios, the clients add a new trust anchor whose private key is kept
on the SSL proxy; the proxy intercepts TLS requests, creates a new TLS session
with the intended host, and sets up a TLS session with the client using a
certificate that chains to the trust anchor installed in the client by the
proxy. In such environments, the TLSA protocol will prevent the SSL proxy from
functioning as expected because the TLS client will get a certificate
association from the DNS that will not match the certificate that the SSL
proxy uses with the client. The client, seeing the proxy's new certificate for
the supposed destination will not set up a TLS session. Thus, such proxies
might choose to aggressively block TLSA requests and/or responses.</t>
<t>Client treatment of any information included in the trust anchor is a
matter of local policy. This specification does not mandate that such
information be inspected or validated by the domain name administrator.</t>
</section>
<section title='Acknowledgements'>
<t>Many of the ideas in this document have been discussed over many years.
More recently, the ideas have been discussed by the authors and others in a
more focused fashion. In particular, some of the ideas here originated with
Paul Vixie, Dan Kaminsky, Jeff Hodges, Phill Hallam-Baker, Simon Josefsson,
Warren Kumari, Adam Langley, Ben Laurie, Ilari Liusvaara, Scott Schmit, and
Ondrej Sury.</t>
<t>This document has also been greatly helped by many active participants
of the DANE Working Group.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor='RFC4347bis'>
<front>
<title>Datagram Transport Layer Security version 1.2</title>
<author initials='E.' surname='Rescorla' fullname='Eric Rescorla'>
<organization /></author>
<author initials='N.' surname='Modadugu' fullname='Nagendra Modadugu'>
<organization /></author>
<date year='2010' month='July' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-tls-rfc4347-bis' />
</reference>
<reference anchor="DANEUSECASES">
<front>
<title>Use Cases and Requirements for DNS-based Authentication of Named Entities (DANE)</title>
<author initials="R." surname="Barnes"> <organization/> </author>
<date year='2011'/>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-dane-use-cases' />
</reference>
&rfc2119;
&rfc4033;
&rfc4034;
&rfc4035;
&rfc5246;
&rfc5280;
</references>
<references title="Informative References">
&rfc2818;
&rfc4025;
&rfc4255;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:16:49 |