draft-ietf-dane-protocol-02.txt   draft-ietf-dane-protocol-03.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 19, 2011 Kirei AB Expires: July 29, 2011 Kirei AB
January 15, 2011 January 25, 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-02 draft-ietf-dane-protocol-03
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 19, 2011. This Internet-Draft will expire on July 29, 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
skipping to change at page 5, line 7 skipping to change at page 5, line 7
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.1. Making Certificate Associations
Items received in TLSA resource records can be treated like trust
anchors by the TLS client. 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 certificate association in the TLSA
resource record. If the certificate from the TLS server matches, the resource record. If the certificate from the TLS server matches, the
TLS client accepts the certificate association. Each certificate TLS client accepts the certificate association. Each certificate
type has a different method for determining matching. type 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. For type 1, the certificate association is valid if the TLS server. With these two types, the trust anchor is used only for
hash of the first certificate offered by the TLS server matches the exact matching, not for chained validation. For type 1, the
value from the resource record. For type 2, the certificate certificate association is valid if the hash of the first certificate
association is valid if the certificate in the TLSA data matches to offered by the TLS server matches the value from the resource record.
the first certificate offered by TLS. For type 2, the certificate association is valid if the certificate
in the TLSA data matches to the first certificate offered by TLS.
Type 3 (hash of certification authority's certificate) can be used in Type 3 (hash of certification authority's certificate) can be used in
one of two ways. If the hash of any certificate past the first in one of two ways. If the hash of any certificate past the first in
the certificate bundle from TLS matches the value from the TLSA data, the certificate bundle from TLS matches the trust anchor from the
and the chain in the certificate bundle is valid up to that TLSA data, and the chain in the certificate bundle is valid up to
certificate, then the certificate association is valid. Alternately, that TLSA trust anchor, then the certificate association is valid.
if the first certificate offered chains to a trust anchor, and the Alternately, if the first certificate offered chains to an existing
hash of that trust anchor matches the value from the TLSA data trust anchor in the TLS client's trust anchor repositor, and the hash
(assuming that the trust anchor is kept in certificate format), then of that trust anchor matches the value from the TLSA data, then the
the certificate association is valid. certificate association is valid.
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 certificate from the TLSA data bundle can be validly chained to the trust anchor from the TLSA data.
(assuming that the trust anchor is kept in certificate format).
[[ 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.2. 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
skipping to change at page 7, line 23 skipping to change at page 7, line 26
certificate associations. If the application receives zero usable certificate associations. If the application receives zero usable
certificate associations, it processes TLS in the normal fashion. certificate associations, it processes TLS in the normal fashion.
If a match between one of the certificate association(s) and the If a match between one of the certificate association(s) and the
server's end entity certificate in TLS is found, the TLS client server's end entity certificate in TLS is found, the TLS client
continues the TLS handshake. If a match between the certificate continues the TLS handshake. If a match between the certificate
association(s) and the server's end entity certificate in TLS is not association(s) and the server's end entity certificate in TLS is not
found, the TLS client MUST abort the handshake with an found, the TLS client MUST abort the handshake with an
"access_denied" error. "access_denied" error.
3.1. Certificate Validation by TLS Clients When Using Certificate
Associations
TLS client policy is deliberately not prescribed by this
specification. A client MAY choose to trust a DNSSEC-secured
certificate association, depending on its local policy.
[[ The preceding paragraph is probably wrong in the sense that it
means that we now have no conformance requirements. There is
probably no reason to even use this protocol unless you are going to
fully trust the results. The one exception that has been discussed
is that you might want to use the TLSA data as a "second positive
opinion", such as in a GUI or in logging. Both of those seem fairly
useless in the case of DNS resolution. Thus, the above paragraph may
be changed by the WG in a future version of this draft. ]]
3.1.1. Use of Self-Signed Certificates
One expected use case for this protocol is that some TLS servers will
begin to use self-signed certificates in association with certificate
associations. A TLS client that is using this protocol needs to
treat self-signed certificates as special, and thus SHOULD NOT
attempt certificate validation on them. (An exception to this rule
would be clients that keep self-signed end entity certificates in its
trust anchor store.)
3.1.2. Ignorning Host Names in Self-Signed Certificates
All data in a self-signed certificate other than the key itself can
be ignored as untrusted unless a client validates the self-signed
certificate to a trust anchor that is identical to the certificate.
That means that the host name given in the self-signed certificate is
meaningless, and that the only way to associate the public key in the
certificate with the domain name is through the certificate
association made in the DNS.
If a TLS client fully trusts the association between a domain name
and the certificate that was provided by the DNS, then that client
MUST ignore the domain name that is given in the self-signed
certificate. That is, the certificate might contain a domain name
that is different than the one that was used to get the TLSA data,
but if the client is trusting the TLSA data, it doesn't matter what
domain name is used in the certificate. An expected use case for
this protocol is to allow someone who controls the private key on a
certificate to use that certificate for multiple TLS servers. These
servers might be on a single computer that has many domain names
(such as a computer that is both a web host and a mail host, and is
known by both "www.example.com" and "smtp.example.com"), or they
might be on different computers (such as multiple computers that all
respond IP addresses reachable as "www.example.com").
[[ Add more about virtual hosting and SNI TLS extension. ]]
3.1.3. Use of Local Trust Anchors
Another expected use case for this protocol is that some TLS servers
will use certificates that chain to a trust anchor that might not be
one that is trusted by the TLS client, such as a local certification
authority (CA) that is administered by the organization that runs the
TLS server; this is a likely use for certificate types 3 and 4.
Because of this, a TLS client that is using this protocol that
performs certificate validation on server certificates MAY have a
method to communicate with the user that differentiates between
validation failures that occur on certificates that have had secure
certificate associations and those that have not. If it does not
have such a method of communication, the failure to validate SHOULD
cause the same error as for any other certificate validation.
3.1.4. Use of Additional Certificate Data
Some TLS clients extract data from the certificate other than the key
to show to the user; for example, most modern web browsers have the
ability to show an extended validation (EV) name that is embedded in
a certificate. Because this data comes from a trusted third party
and not the TLS server itself, TLS clients that extract additional
information from TLS server certificates MUST validate those
certificates in the normal fashion.
4. IANA Considerations 4. IANA Considerations
4.1. TLSA RRtype 4.1. TLSA RRtype
This document uses a new DNS RRType, TLSA, whose value is TBD. A This document uses a new DNS RRType, TLSA, whose value is TBD. A
separate request for the RRType will be submitted to the expert separate request for the RRType will be submitted to the expert
reviewer, and future versions of this document will have that value reviewer, and future versions of this document will have that value
instead of TBD. instead of TBD.
4.2. TLSA Certificate Types 4.2. TLSA Certificate Types
 End of changes. 8 change blocks. 
96 lines changed or deleted 22 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/