draft-ietf-dane-protocol-03.txt   draft-ietf-dane-protocol-04.txt 
Network Working Group P. Hoffman Network Working Group P. Hoffman
Internet-Draft VPN Consortium Internet-Draft VPN Consortium
Intended status: Standards Track J. Schlyter Intended status: Standards Track J. Schlyter
Expires: July 29, 2011 Kirei AB Expires: August 14, 2011 Kirei AB
January 25, 2011 February 10, 2011
Using Secure DNS to Associate Certificates with Domain Names For TLS Using Secure DNS to Associate Certificates with Domain Names For TLS
draft-ietf-dane-protocol-03 draft-ietf-dane-protocol-04
Abstract Abstract
TLS and DTLS use certificates for authenticating the server. Users TLS and DTLS use certificates for authenticating the server. Users
want their applications to verify that the certificate provided by want their applications to verify that the certificate provided by
the TLS server is in fact associated with the domain name they the TLS server is in fact associated with the domain name they
expect. Instead of trusting a certification authority to have made expect. Instead of trusting a certification authority to have made
this association correctly, the user might instead trust the this association correctly, the user might instead trust the
authoritative DNS server for the domain name to make that authoritative DNS server for the domain name to make that
association. This document describes how to use secure DNS to association. This document describes how to use secure DNS to
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 29, 2011. This Internet-Draft will expire on August 14, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Certificate Associations . . . . . . . . . . . . . . . . . 3
1.2. Securing Certificate Associations . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Getting TLS Certificate Associations from the DNS . . . . . . 5
2.1. Requested Domain Name . . . . . . . . . . . . . . . . . . 5
2.2. Format of the Resource Record . . . . . . . . . . . . . . 5
2.3. Making Certificate Associations . . . . . . . . . . . . . 6
2.4. Presentation Format . . . . . . . . . . . . . . . . . . . 7
2.5. Wire Format . . . . . . . . . . . . . . . . . . . . . . . 7
3. Use of TLS Certificate Associations in TLS . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
4.1. TLSA RRtype . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. TLSA Certificate Types . . . . . . . . . . . . . . . . . . 9
4.3. TLSA Hash Types . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The first response from the server in TLS may contain a certificate. 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 In order for the TLS client to authenticate that it is talking to the
expected TLS server, the client must validate that this certificate expected TLS server, the client must validate that this certificate
is associated with the domain name used by the client to get to the 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 server. Currently, the client must extract the domain name from the
certificate, must trust a trust anchor upon which the server's certificate, must trust a trust anchor upon which the server's
certificate is rooted, and must successfully validate the certificate is rooted, and must successfully validate the
certificate. certificate.
skipping to change at page 4, line 11 skipping to change at page 5, line 8
Some of the terminology in this draft may not match with the Some of the terminology in this draft may not match with the
terminology used in RFC 5280. This will be fixed in future versions terminology used in RFC 5280. This will be fixed in future versions
of this draft, with help from the PKIX community. In specific, we of this draft, with help from the PKIX community. In specific, we
need to say (in a PKIX-appropriate way) that when we say "valid up need to say (in a PKIX-appropriate way) that when we say "valid up
to" and "chains to", full RFC 5280 path processing including to" and "chains to", full RFC 5280 path processing including
revocation status checking is intended. revocation status checking is intended.
2. Getting TLS Certificate Associations from the DNS 2. Getting TLS Certificate Associations from the DNS
This document defines a new DNS resource record type, "TLSA". A This document defines a new DNS resource record type, "TLSA". A
query on a domain name for the TLSA RR can return one or more records query on a prepared domain name for the TLSA RR can return one or
of the type TLSA. The TLSA RRType is TBD. more records of the type TLSA. The TLSA RRType is TBD.
2.1. Requested Domain Name
Domain names are prepared for requests 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.
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", 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".
2.2. Format of the Resource Record
The format of the data in the resource record is a binary record with The format of the data in the resource record is a binary record with
three values, which MUST be in the order defined here: three values, which MUST be in the order defined here:
o A one-octet value, called "certificate type", specifying the o A one-octet value, called "certificate type", specifying the
provided association that will be used to match the target provided association that will be used to match the target
certificate. This will be an IANA registry in order to make it certificate. This will be an IANA registry in order to make it
easier to add additional certificate types in the future. The easier to add additional certificate types in the future. The
types defined in this document are: types defined in this document are:
skipping to change at page 5, line 5 skipping to change at page 6, line 24
o The "certificate for association". This is the bytes containing o The "certificate for association". This is the bytes containing
the certificate or the hash of the associated certificate (that the certificate or the hash of the associated certificate (that
is, the certificate or the hash of the certificate itself, not of is, the certificate or the hash of the certificate itself, not of
the TLS ASN.1Cert object). the TLS ASN.1Cert object).
Certificate types 1 through 4 explicitly only apply to PKIX-formatted Certificate types 1 through 4 explicitly only apply to PKIX-formatted
certificates. If TLS allows other formats later, or if extensions to certificates. If TLS allows other formats later, or if extensions to
this protocol are made that accept other formats for certificates, this protocol are made that accept other formats for certificates,
those certificates will need certificate types. those certificates will need certificate types.
2.1. Making Certificate Associations 2.3. Making Certificate Associations
Items received in TLSA resource records can be treated like trust A TLS client conforming to this protocol MUST treat the certificate
anchors by the TLS client. The trust anchor MUST NOT be loaded for for association in a TLSA resource record for a domain name as a
longer than the TTL on the TSLA record. trust anchor for that domain name at the specific port number and
transport name that was queried. This trust anchor MUST only be used
for the domain name of the resource record. The trust anchor MUST
NOT be loaded for longer than the TTL on the TSLA record.
The TLS client determines whether or not the certificate offered by The TLS client determines whether or not the certificate offered by
the TLS server matches the certificate association in the TLSA the TLS server matches the trust anchor received in the TLSA resource
resource record. If the certificate from the TLS server matches, the record. If the certificate from the TLS server matches, the TLS
TLS client accepts the certificate association. Each certificate client accepts the certificate association. Each certificate type
type has a different method for determining matching. has a different method for determining matching.
For types 1 and 3, the hash used in the comparison is the hash type For types 1 and 3, the hash used in the comparison is the hash type
from the TLSA data. from the TLSA data.
Types 1 (hash of an end-entity certificate) and 2 (full end-entity Types 1 (hash of an end-entity certificate) and 2 (full end-entity
certificate) are matched against the first certificate offered by the certificate) are matched against the first certificate offered by the
TLS server. With these two types, the trust anchor is used only for TLS server. With these two types, the trust anchor is used only for
exact matching, not for chained validation. For type 1, the exact matching, not for chained validation. For type 1, the
certificate association is valid if the hash of the first certificate certificate association is valid if the hash of the first certificate
offered by the TLS server matches the value from the resource record. offered by the TLS server matches the value from the resource record.
skipping to change at page 5, line 48 skipping to change at page 7, line 22
Type 4 (full certification authority's certificate) is used in Type 4 (full certification authority's certificate) is used in
chaining from the end-entity given in TLS. The certificate chaining from the end-entity given in TLS. The certificate
association is valid if the first certificate in 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. bundle can be validly chained to the trust anchor from the TLSA data.
[[ Need discussion of self-signed certificates being CA certificates. [[ Need discussion of self-signed certificates being CA certificates.
Need to be sure that this discussion uses correct PKIX terminology Need to be sure that this discussion uses correct PKIX terminology
and is carefully explained. ]] and is carefully explained. ]]
2.2. Presentation Format 2.4. Presentation Format
The RDATA of the presentation format of the TLSA resource record The RDATA of the presentation format of the TLSA resource record
consists of two numbers (certificate and hash type) followed by the consists of two numbers (certificate and hash type) followed by the
bytes containing the certificate or the hash of the associated bytes containing the certificate or the hash of the associated
certificate itself, presented in hex. An example of a SHA-256 hash certificate itself, presented in hex. An example of a SHA-256 hash
(type 2) of an end-entity certificate (type 1) would be: (type 2) of an end-entity certificate (type 1) would be:
www.example.com. IN TLSA ( _443._tcp.www.example.com. IN TLSA (
1 2 5c1502a6549c423be0a0aa9d9a16904de5ef0f5c98 1 2 5c1502a6549c423be0a0aa9d9a16904de5ef0f5c98
c735fcca79f09230aa7141 ) c735fcca79f09230aa7141 )
An example of an unhashed (type 0) CA certificate (type 4) would be: An example of an unhashed (type 0) CA certificate (type 4) would be:
www.example.com. IN TLSA ( _443._tcp.www.example.com. IN TLSA (
4 0 308202c5308201ada00302010202090... ) 4 0 308202c5308201ada00302010202090... )
Because the length of hashes and certificates can be quite long, Because the length of hashes and certificates can be quite long,
presentation format explicitly allows line breaks and white space in presentation format explicitly allows line breaks and white space in
the hex values; those characters are removed when converting to the the hex values; those characters are removed when converting to the
wire format. wire format.
2.3. Wire Format 2.5. Wire Format
The wire format is: The wire format is:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 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 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 | Hash type | / | Cert type | Hash type | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
/ / / /
/ Certificate for association / / Certificate for association /
/ / / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The wire format for the RDATA in the first example given above would The wire format for the RDATA in the first example given above would
be: be:
www.example.com. IN TYPE65534 \# 34 ( 01025c1502a6549c423be0a0aa _443._tcp.www.example.com. IN TYPE65534 \# 34 ( 01025c1502a6549c42
9d9a16904de5ef0f5c98c735fcca79f09230aa7141 ) 3be0a0aa9d9a16904de5ef0f5c98c735fcca79f09230aa7141 )
The wire format for the RDATA in the second example given above would The wire format for the RDATA in the second example given above would
be: be:
www.example.com. IN TYPE65534 \# 715 0400308202c5308201ada003020... _443._tcp.www.example.com. IN TYPE65534 \# 715 0400308202c5308201a...
3. Use of TLS Certificate Associations in TLS 3. Use of TLS Certificate Associations in TLS
In order to use one or more TLS certificate associations described in In order to use one or more TLS certificate associations described in
this document obtained from the DNS, an application MUST assure that this document obtained from the DNS, an application MUST assure that
the certificates were obtained using DNS protected by DNSSEC. TLSA the certificates were obtained using DNS protected by DNSSEC. TLSA
records must only be trusted if they were obtained from a trusted records must only be trusted if they were obtained from a trusted
source. This could be a localhost DNS resolver answer with the AD source. This could be a localhost DNS resolver answer with the AD
bit set, an inline validating resolver library primed with the proper bit set, an inline validating resolver library primed with the proper
trust anchors, or obtained from a remote nameserver to which one has trust anchors, or obtained from a remote nameserver to which one has
 End of changes. 14 change blocks. 
21 lines changed or deleted 75 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/