Commit 2fe2cfd7 authored by Mark Andrews's avatar Mark Andrews
Browse files

new draft

parent 8e2c2ca0
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="http://www.ietf.org/id/draft-ietf-dane-protocol-19.txt">here</a>.</p>
</body></html>
Network Working Group P. Hoffman
Internet-Draft VPN Consortium
Intended status: Standards Track J. Schlyter
Expires: October 13, 2012 Kirei AB
April 11, 2012
The DNS-Based Authentication of Named Entities (DANE) Protocol for
Transport Layer Security (TLS)
draft-ietf-dane-protocol-19
Abstract
Encrypted communication on the Internet often uses Transport Level
Security (TLS), which depends on third parties to certify the keys
used. This document improves on that situation by enabling the
administrators of domain names to specify the keys used in that
domain's TLS servers. This requires matching improvements in TLS
client software, but no change in TLS server software.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 13, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Hoffman & Schlyter Expires October 13, 2012 [Page 1]
Internet-Draft DNS-Based Authentication for TLS April 2012
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Background of the Problem . . . . . . . . . . . . . . . . 4
1.2. Securing the Association with a Server's Certificate . . . 5
1.3. Method For Securing Certificate Associations . . . . . . . 6
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
2. The TLSA Resource Record . . . . . . . . . . . . . . . . . . . 7
2.1. TLSA RDATA Wire Format . . . . . . . . . . . . . . . . . . 7
2.1.1. The Certificate Usage Field . . . . . . . . . . . . . 8
2.1.2. The Selector Field . . . . . . . . . . . . . . . . . . 9
2.1.3. The Matching Type Field . . . . . . . . . . . . . . . 9
2.1.4. The Certificate Association Data Field . . . . . . . . 10
2.2. TLSA RR Presentation Format . . . . . . . . . . . . . . . 10
2.3. TLSA RR Examples . . . . . . . . . . . . . . . . . . . . . 10
3. Domain Names for TLS Certificate Associations . . . . . . . . 11
4. Use of TLSA Records in TLS . . . . . . . . . . . . . . . . . . 11
5. TLSA and DANE Use Cases and Requirements . . . . . . . . . . . 13
6. Mandatory-to-Implement Features . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7.1. TLSA RRtype . . . . . . . . . . . . . . . . . . . . . . . 15
7.2. TLSA Usages . . . . . . . . . . . . . . . . . . . . . . . 15
7.3. TLSA Selectors . . . . . . . . . . . . . . . . . . . . . . 16
7.4. TLSA Matching Types . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8.1. Comparing DANE to Public CAs . . . . . . . . . . . . . . . 18
8.2. DNS Caching . . . . . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Operational Considerations for Deploying TLSA
Records . . . . . . . . . . . . . . . . . . . . . . . 21
A.1. Creating TLSA Records . . . . . . . . . . . . . . . . . . 21
A.1.1. Ambiguities and Corner Cases When TLS Clients
Build Trust Chains . . . . . . . . . . . . . . . . . . 22
A.1.2. Choosing a Selector Type . . . . . . . . . . . . . . . 23
A.2. Provisioning TLSA Records in DNS . . . . . . . . . . . . . 24
A.2.1. Provisioning TLSA Records with Aliases . . . . . . . . 24
A.3. Securing the Last Hop . . . . . . . . . . . . . . . . . . 27
A.4. Handling Certificate Rollover . . . . . . . . . . . . . . 27
Appendix B. Pseudocode for Using TLSA . . . . . . . . . . . . . . 28
B.1. Helper Functions . . . . . . . . . . . . . . . . . . . . . 28
Hoffman & Schlyter Expires October 13, 2012 [Page 2]
Internet-Draft DNS-Based Authentication for TLS April 2012
B.2. Main TLSA Pseudo Code . . . . . . . . . . . . . . . . . . 29
Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Hoffman & Schlyter Expires October 13, 2012 [Page 3]
Internet-Draft DNS-Based Authentication for TLS April 2012
1. Introduction
1.1. Background of the Problem
Applications that communicate over the Internet often need to prevent
eavesdropping, tampering, or forgery of their communications. The
Transport Layer Security (TLS) protocol provides this kind of
communications security over the Internet, using encryption.
The security properties of encryption systems depend strongly on the
keys that they use. If secret keys are revealed, or if public keys
can be replaced by bogus keys, these systems provide little or no
security.
TLS uses certificates to bind keys and names. A certificate combines
a published key with other information such as the name of the
service that uses the key, and this combination is digitally signed
by another key. Having a certificate for a key is only helpful if
one trusts the other key that signed the certificate. If that other
key was itself revealed or substituted, then its signature is
worthless in proving anything about the first key.
On the Internet, this problem has been solved for years by entities
called "Certification Authorities" (CAs). CAs protect their secret
key vigorously, while supplying their public key to the software
vendors who build TLS clients. They then sign certificates, and
supply those to TLS servers. TLS client software uses a set of these
CA keys as "trust anchors" to validate the signatures on certificates
that the client receives from TLS servers. Client software typically
allows any CA to usefully sign any other certificate.
The public CA model upon which TLS has depended is fundamentally
vulnerable because it allows any of these CAs to issue a certificate
for any domain name. A single trusted CA that betrays its trust,
either voluntarily or by providing less-than-vigorous protection for
its secrets and capabilities, can compromise any other certificate
that TLS uses, by signing a replacement certificate that contains a
bogus key. Recent experiences with compromises of CAs or their
trusted partners have lead to very serious security problems, such as
the subversion of major web sites trusted by millions of users.
The DNS Security Extensions (DNSSEC) provides a similar model that
involves trusted keys signing the information for untrusted keys.
However, DNSSEC provides three significant improvements. Keys are
tied to names in the Domain Name System (DNS), rather than to
arbitrary identifying strings; this is more convenient for Internet
protocols. Signed keys for any domain are accessible online through
a straightforward query using the standard DNSSEC protocol, so there
Hoffman & Schlyter Expires October 13, 2012 [Page 4]
Internet-Draft DNS-Based Authentication for TLS April 2012
is no problem distributing the signed keys. Most significantly, the
keys associated with a domain name can only be signed by a key
associated with the parent of that domain name; for example, the keys
for "example.com" can only be signed by the keys for "com", and the
keys for "com" can only be signed by the DNS root. This prevents an
untrustworthy signer from compromising anyone's keys except those in
their own subdomains. Like TLS, DNSSEC relies on public keys that
come built into the DNSSEC client software, but these keys come only
from a single root domain rather than from a multiplicity of CAs.
DNS-Based Authentication of Named Entities (DANE) offers the option
to use the DNSSEC infrastructure to store and sign keys and
certificates that are used by TLS. DANE is envisioned as a
preferable basis for binding public keys to DNS names, because the
entities that vouch for the binding of public key data to DNS names
are the same entities responsible for managing the DNS names in
question. While the resulting system still has residual security
vulnerabilities, it restricts the scope of assertions that can be
made by any entity, consistent with the naming scope imposed by the
DNS hierarchy. As a result, DANE embodies the security "principle of
least privilege" that is lacking in the current public CA model.
1.2. Securing the Association with a Server's Certificate
A TLS client begins a connection by exchanging messages with a TLS
server. It looks up the server's name using the DNS to get an
Internet Protocol (IP) address associated with the name. It then
begins a connection to a client-chosen port at that address, and
sends an initial message there. However, the client does not yet
know whether an adversary is intercepting and/or altering its
communication before it reaches the TLS server. It does not even
know whether the real TLS server associated with that domain name has
ever received its initial messages.
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 and must successfully validate the certificate, including
chaining to a trust anchor.
There is a different way to authenticate the association of the
server's certificate with the intended domain name without trusting
an external 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
Hoffman & Schlyter Expires October 13, 2012 [Page 5]
Internet-Draft DNS-Based Authentication for TLS April 2012
by a host at that domain name. The easiest way to do this is to use
the DNS, securing the binding with DNSSEC.
There are many use cases for such functionality. [RFC6394] lists the
ones to which the DNS RRtype in this document apply. [RFC6394] also
lists many requirements, most of which this document is believed to
meet. Section 5 covers the applicability of this document to the use
cases in detail.
This document applies to both TLS [RFC5246] and DTLS [RFC6347]. 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
[RFC4025] and keys for SSH are covered in [RFC4255].
1.3. Method For Securing Certificate Associations
A certificate association is formed from a piece of information
identifying a certificate and the domain name where the data is
found. The combination of a trust anchor and a domain name can also
be a certificate association.
A DNS query can return multiple certificate associations, such as in
the case of a server is changing from one certificate to another.
This document only applies to PKIX [RFC5280] certificates, not
certificates of other formats.
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 needs 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.
DNSSEC, which is defined in [RFC4033], [RFC4034], and [RFC4035], uses
cryptographic keys and digital signatures to provide authentication
of DNS data. Information that is retrieved from the DNS and that is
validated using DNSSEC is thereby proved to be the authoritative
data. The DNSSEC signature needs to be validated on all responses
that use DNSSEC in order to assure the proof of origin of the data.
This document does not specify how DNSSEC validation occurs because
there are many different proposals for how a client might get
validated DNSSEC results, such as from a DNSSEC-aware resolver that
Hoffman & Schlyter Expires October 13, 2012 [Page 6]
Internet-Draft DNS-Based Authentication for TLS April 2012
is coded in the application, from a trusted DNSSEC resolver on the
machine on which the application is running, or from a trusted DNSSEC
resolver with which the application is communicating over an
authenticated and integrity-protected channel or network. This is
described in more detail in Section 7 of [RFC4033].
This document only relates to getting the DNS information for the
certificate association securely using DNSSEC; other secure DNS
mechanisms are out of scope.
1.4. Terminology
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 [RFC2119].
This document also makes use of standard PKIX, DNSSEC, TLS, and DNS
terminology. See [RFC5280], [RFC4033], [RFC5246], and [STD13]
respectively, for these terms. In addition, terms related to TLS-
protected application services and DNS names are taken from
[RFC6125].
2. The TLSA Resource Record
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.
The type value for the TLSA RR type is defined in Section 7.1.
The TLSA RR is class independent.
The TLSA RR has no special TTL requirements.
2.1. TLSA RDATA Wire Format
The RDATA for a TLSA RR consists of a one octet usage type field, a
one octet selector field, a one octet matching type field and the
certificate association data field.
Hoffman & Schlyter Expires October 13, 2012 [Page 7]
Internet-Draft DNS-Based Authentication for TLS April 2012
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Usage | Selector | Matching Type | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
/ /
/ Certificate Association Data /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.1.1. The Certificate Usage Field
A one-octet value, called "certificate usage" or just "usage",
specifies the provided association that will be used to match the
target certificate from the TLS handshake. This value is defined in
a new IANA registry (see Section 7.2) in order to make it easier to
add additional certificate usages in the future. The usages defined
in this document are:
0 -- Certificate usage 0 is used to specify a CA certificate, or
the public key of such a certificate, that MUST be found in any of
the PKIX certification paths for the end entity certificate given
by the server in TLS. This usage is sometimes referred to as "CA
constraint" because it limits which CA can be used to issue
certificates for a given service on a host. The target
certificate MUST pass PKIX certification path validation and a CA
certificate that matches the TLSA record MUST be included as part
of a valid certification path. Because this usage allows both
trust anchors and CA certificates, the certificate might or might
not have the basicConstraints extension present.
1 -- Certificate usage 1 is used to specify an end entity
certificate, or the public key of such a certificate, that must be
matched with the end entity certificate given by the server in
TLS. This usage is sometimes referred to as "service certificate
constraint" because it limits which end entity certificate can be
used by a given service on a host. The target certificate MUST
pass PKIX certification path validation and MUST match the TLSA
record.
2 -- Certificate usage 2 is used to specify a certificate, or the
public key of such a certificate, that must be used as the trust
anchor when validating the end entity certificate given by the
server in TLS. This usage is sometimes referred to as "trust
anchor assertion" and allows a domain name administrator to
specify a new trust anchor. For example, if the domain issues its
own certificates under its own CA that is not expected to be in
the end users' collection of trust anchors. The target
Hoffman & Schlyter Expires October 13, 2012 [Page 8]
Internet-Draft DNS-Based Authentication for TLS April 2012
certificate MUST pass PKIX certification path validation, with any
certificate matching the TLSA record considered to be a trust
anchor for this certification path validation.
3 -- Certificate usage 3 is used to specify a certificate, or the
public key of such a certificate, that must match the end entity
certificate given by the server in TLS. This usage is sometimes
referred to as "domain-issued certificate" because it allows for a
domain name administrator to issue certificates for a domain
without involving a third-party CA. The target certificate MUST
match the TLSA record. The difference between certificate usage 1
and certificate usage 3 is that certificate usage 1 requires that
the certificate pass PKIX validation, but PKIX validation is not
tested for certificate usage 3.
The certificate usages defined in this document explicitly only apply
to PKIX-formatted certificates in DER encoding. If TLS allows other
formats later, or if extensions to this RRtype are made that accept
other formats for certificates, those certificates will need their
own certificate usage values.
2.1.2. The Selector Field
A one-octet value, called "selector", specifies which part of the TLS
certificate presented by the server will be matched against the
association data. This value is defined in a new IANA registry (see
Section 7.3. The selectors defined in this document are:
0 -- Full certificate
1 -- SubjectPublicKeyInfo
The SubjectPublicKeyInfo is a binary structure defined in [RFC5280].
(Note that the use of "selector" in this document is completely
unrelated to the use of "selector" in DKIM [RFC6376].)
2.1.3. The Matching Type Field
A one-octet value, called "matching type", specifies how the
certificate association is presented. This value is defined in a new
IANA registry (see Section 7.4). The types defined in this document
are:
0 -- Exact match on selected content
1 -- SHA-256 hash of selected content [RFC6234]
Hoffman & Schlyter Expires October 13, 2012 [Page 9]
Internet-Draft DNS-Based Authentication for TLS April 2012
2 -- SHA-512 hash of selected content [RFC6234]
If the TLSA record's matching type is a hash, having the record use
the same hash algorithm that was used in the signature in the
certificate (if possible) will assist clients that support a small
number of hash algorithms.
2.1.4. The Certificate Association Data Field
The "certificate association data" to be matched. This field
contains the data to be matched. These bytes are either raw data
(that is, the full certificate or its SubjectPublicKeyInfo, depending
on the selector) for matching type 0, or the hash of the raw data for
matching types 1 and 2. The data refers to the certificate in the
association, not to the TLS ASN.1 Certificate object.
2.2. TLSA RR Presentation Format
The presentation format of the RDATA portion is as follows:
o The certificate usage field MUST be represented as an 8-bit
unsigned decimal integer.
o The selector field MUST be represented as an 8-bit unsigned
decimal integer.
o The matching type field MUST be represented as an 8-bit unsigned
decimal integer.
o The certificate association data field MUST be represented as a
string of hexadecimal characters. Whitespace is allowed within
the string of hexadecimal characters.
2.3. TLSA RR Examples
In the following examples, the domain name is formed using the rules
in Section 3.
An example of a hashed (SHA-256) association of a PKIX CA
certificate:
_443._tcp.www.example.com. IN TLSA (
0 0 1 d2abde240d7cd3ee6b4b28c54df034b9
7983a1d16e8a410e4561cb106618e971 )
An example of a hashed (SHA-512) subject public key association of a
PKIX end entity certificate:
Hoffman & Schlyter Expires October 13, 2012 [Page 10]
Internet-Draft DNS-Based Authentication for TLS April 2012
_443._tcp.www.example.com. IN TLSA (
1 1 2 92003ba34942dc74152e2f2c408d29ec
a5a520e7f2e06bb944f4dca346baf63c
1b177615d466f6c4b71c216a50292bd5
8c9ebdd2f74e38fe51ffd48c43326cbc )
An example of a full certificate association of a PKIX end entity
certificate:
_443._tcp.www.example.com. IN TLSA (
3 0 0 30820307308201efa003020102020... )
3. Domain Names for TLS Certificate Associations
Unless there is a protocol-specific specification that is different
than this one, TLSA resource records are stored at a prefixed DNS
domain name. The prefix is prepared in the following manner:
1. 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.
2. 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".
3. The domain name is appended to the result of step 2 to complete
the prepared domain name.
For example, to request a TLSA resource record for an HTTP server
running TLS on port 443 at "www.example.com",
"_443._tcp.www.example.com" is used in the request. To request a
TLSA resource record for an SMTP server running the STARTTLS protocol
on port 25 at "mail.example.com", "_25._tcp.mail.example.com" is
used.
4. Use of TLSA Records in TLS
Section 2.1 of this document defines the mandatory matching rules for
the data from the TLSA certificate associations and the certificates
received from the TLS server.
The TLS session that is to be set up MUST be for the specific port
Hoffman & Schlyter Expires October 13, 2012 [Page 11]
Internet-Draft DNS-Based Authentication for TLS April 2012
number and transport name that was given in the TLSA query.
Some specifications for applications that run over TLS, such as
[RFC2818] for HTTP, require the server's certificate to have a domain
name that matches the host name expected by the client. Some
specifications such as [RFC6125] detail how to match the identity
given in a PKIX certificate with those expected by the user.
An implementation of this protocol makes a DNS query for TLSA
records, validates these records using DNSSEC, and uses the resulting
TLSA records and validation status to modify its responses to the TLS
server.