< draft-hoffman-keys-linkage-from-dns-01.txt   draft-hoffman-keys-linkage-from-dns-02.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: February 25, 2011 Kirei AB Expires: March 19, 2011 Kirei AB
W. Kumari W. Kumari
A. Langley A. Langley
Google Google
August 24, 2010 September 15, 2010
Using Secure DNS to Associate Certificates with Domain Names For TLS Using Secure DNS to Associate Certificates with Domain Names For TLS
draft-hoffman-keys-linkage-from-dns-01 draft-hoffman-keys-linkage-from-dns-02
Abstract Abstract
TLS and DTLS uses certificates for authenticating the server. Users TLS and DTLS uses 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 certificate authority to have made expect. Instead of trusting a certificate 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 42 skipping to change at page 1, line 42
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 February 25, 2011. This Internet-Draft will expire on March 19, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 3, line 26 skipping to change at page 3, line 26
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
This document is being discussed on the "keyassure" mailing list; see This document is being discussed on the "keyassure" mailing list; see
<https://www.ietf.org/mailman/listinfo/keyassure>. <https://www.ietf.org/mailman/listinfo/keyassure>.
2. Getting TLS Certificate Associations from the DNS with the CERT RR 2. Getting TLS Certificate Associations from the DNS with the CERT RR
This section describes the TLSFP Certificate Type of the CERT RR.
The CERT RR [RFC4398] allows expansion by defining new certificate The CERT RR [RFC4398] allows expansion by defining new certificate
types. The new TLSFP certificate type is defined here. A query on a types. This document describes two new Certificate Types, TLSFP and
domain name for the CERT RR can return one or more records of the TLSRQ. A query on a domain name for the CERT RR can return one or
type CERT, and zero or more of those CERT responses can be of type more records of the type CERT, and zero or more of those CERT
TLSFP. responses can be of type TLSFP and TLSRQ.
o The TLSFP certificate type is TBD. 2.1. The TLSFP Certificate Type
o The key tag and algorithm fields are both set to zero. This section describes the TLSFP certificate type of the CERT RR.
The TLSFP certificate type is TBD1. The key tag and algorithm fields
are both set to zero.
The format of the TLSFP certificate is a binary record, which MUST be The format of the TLSFP certificate is a binary record, which MUST be
in the order defined here, is: in the order defined here, is:
o A one-octet value, called "hash type", specifying the type of hash o A one-octet value, called "hash type", specifying the type of hash
algorithm used for the certificate association. This value has algorithm used for the certificate association. This value has
the same values as those of the DS RR, as defined in [RFC4034] and the same values as those of the DS RR, as defined in the IANA
its successors. registry titled "Delegation Signer (DS) Resource Record (RR) Type
Digest Algorithms"
(<http://www.iana.org/assignments/ds-rr-types>).
o A one-octet value, called "validation preference", specifying the o A one-octet value, called "validation preference", specifying the
preferences for further validation of the certificate in TLS. A preferences for further validation of the certificate in TLS. A
certificate association that contains a validation preference certificate association that contains a validation preference
whose value is 1 indicates that the TLS administrator believes whose value is 1 indicates that the TLS administrator believes
that it is sufficient to match the certificate association with that it is sufficient to match the certificate association with
the hash of certificate received in the TLS negotiation, and that the hash of certificate received in the TLS negotiation, and that
no further certificate validation is necessary. A certificate no further certificate validation is necessary. A certificate
association that contains a validation preference whose value is 0 association that contains a validation preference whose value is 0
indicates that the TLS administrator believes that it is not indicates that the TLS administrator believes that it is not
sufficient to match the certificate association with the hash of sufficient to match the certificate association with the hash of
certificate received in the TLS negotiation, and that normal certificate received in the TLS negotiation, and that normal
certificate validation is necessary. Note that the validation certificate validation is necessary. Note that the validation
preference is an advisory, and it is not mandatory for a TLS preference is an advisory, and it is not mandatory for a TLS
client to follow the advice. client to follow the advice.
o A variable-length set of bytes containing the hash of the o A variable-length set of bytes containing the hash of the
associated certificate. associated certificate (that is, of the certificate itself, not
the TLS ASN.1Cert object).
An example of a fingerprint for a single certificate:
www.example.com. IN CERT
TLSFP 0 0 AQDne3GdTpxjwLCgMzvgpBiOSQthjg==
An example of a fingerprint of a certificate that is found by its
hash value:
e77b719d4e9c63c0b0a0333be0a4188e490b618e.www.example.com. IN CERT
TLSFP 0 0 AQDne3GdTpxjwLCgMzvgpBiOSQthjg==
2.2. The TLSRQ Certificate Type
This section describes the TLSRQ certificate type of the CERT RR. If
a domain has many certificates associated with it, the number of
TLSFP CERT RRs may become impractical. In this case, a TLSRQ
certificate type may be used.
The semantics of the TLSRQ certificate type are that the requesting
party should send another query for the CERT RR that is formed by
prepending a label to the host name that is the hex of the SHA-1 hash
value taken over the certificate (not the TLS ASN.1Cert object). If
that certificate is a valid certificate that would have been returned
in a TLSFP certificate type, requesting it with this encoded hash
prepended to the host name will yield a TLSFP certificate type.
There is no security problem with using SHA-1 even if the SHA-1 hash
function continues to weaken because the hash is simply used to
differentiate the various certificates used by the server.
Note that the TLSRQ certificate type can only be used if the
requesting party knows the hash of the certificate that is being used
by the TLS server. This usually means that the request will be sent
by the application acting as the TLS client after it has received the
TLS server's Certificate message that contains the server's
certificate. Such a request can slow down the TLS handshake
processing, but is required in the case where different hosts with
different certificates respond on the same domain name.
The typical scenario would look like the following:
1. The application client that is about to use TLS sends a CERT
query for www.example.com.
2. The name server responds with a CERT record that has a TLSRQ
certificate type.
3. The application client starts the TLS handshake, and receives a
Certificate message from the server.
4. The application client takes the SHA-1 hash of the certificate,
encodes that value as hex. For this example, assume that encoded
value is "e77b719d4e9c63c0b0a0333be0a4188e490b618e".
5. The application client sends a CERT query for
e77b719d4e9c63c0b0a0333be0a4188e490b618e.www.example.com. It
receives a response with a TLSFP certificate type.
6. The application uses the information in the TLSFP certificate
type and associates it with www.example.com.
The TLSRQ certificate type has a certificate body with a single octet
of 0. The TLSFP certificate type is TBD2.
For example: For example:
www.example.com. IN CERT TLSFP 0 0 ( AQGa+FZd8sAeS03ca8xDigDQ www.example.com. IN CERT TLSRQ 0 0 AA=
ePgJnQvgMe/kKyf8rzluiQ== )
3. Use of TLS Certificate Associations from the DNS in TLS 3. Use of TLS Certificate Associations from the DNS in TLS
In order to use one or more TLS certificate associations obtained In order to use one or more TLS certificate associations obtained
from the DNS, an application MUST assure that the certificates were from the DNS, an application MUST assure that the certificates were
obtained using DNS protected by DNSSEC. There may be other methods obtained using DNS protected by DNSSEC. There may be other methods
to securely obtain certificates in DNS, but those methods are not to securely obtain certificates in DNS, but those methods are not
covered by this document. covered by this document.
An application that requests TLS certificate associations using the
method described in the previous section obtains zero or more
certificate associations. If the application receives zero
certificate associations, it process TLS in the normal fashion.
If a certificate association contains a hash type that is not If a certificate association contains a hash type that is not
understood by the TLS client, that certificate association MUST be understood by the TLS client, that certificate association MUST be
completely ignored. completely ignored.
An application that requests TLS certificate associations using the
method described in the previous section obtains zero or more usable
certificate associations. If the application receives zero usable
certificate associations, it process TLS in the normal fashion.
If a match between the certificate association(s) and the server's If a match between the certificate association(s) and the server's
end entity certificate in TLS is not found, the TLS client MUST abort end entity certificate in TLS is not found, the TLS client MUST abort
the handshake with an "access_denied" error. the handshake with an "access_denied" error.
If the TLS server authenticates itself with a self-signed If the TLS server authenticates itself with a self-signed
certificate, it SHOULD be sure that the validation preference in the certificate, it SHOULD be sure that the validation preference in the
CERT RR is set to 1. If the TLS server administrator believes that CERT RR is set to 1. If the TLS server administrator believes that
there is information in its certificate that is relevant to the TLS there is information in its certificate that is relevant to the TLS
client other than the public key (such as a extended value (EV) client other than the public key (such as a extended value (EV)
name), it SHOULD be sure that the validation preference in the CERT name), it SHOULD be sure that the validation preference in the CERT
RR is set to 0. RR is set to 0.
4. IANA Considerations 4. IANA Considerations
This document requests that IANA allocates one certificate type from This document requests that IANA allocates two certificate types from
the CERT RR certificate type registry. The type is to be allocated the CERT RR certificate type registry
from the 'IETF Consensus' range. (<http://www.iana.org/assignments/cert-rr-types>). The types are to
be allocated from the 'IETF Consensus' range.
Decimal type: TBD
Type: TLSFP Decimal type: TBD1
Type: TLSFP
Meaning: TLS certificate associations
Meaning: TLS Certificate Associations Decimal type: TBD2
Type: TLSRQ
Meaning: Client should request TLS certificate associations
retrieved using hashes
5. Security Considerations 5. Security Considerations
[[ TBD. This section will need to describe, at least, the "attack" The security of the protocols described in this document relies on
where a DNS administrator goes rogue and changes both the A and CERT the security of DNSSEC as used by the client requesting A and CERT
records for a domain name. Also will discuss the need for secure records.
DNS. ]]
A DNS administrator who goes rogue and changes both the A and CERT
records for a domain name can cause the user to go to an unauthorized
server that will appear authorized.
The SHA-1 hash used in the queries after the TLSRQ certificate type
is only used to differentiate certificates. If there is a collision
between the SHA-1 hashes of two certificates used by the servers that
are at the host name, there is no problem because both of those
certificates will have the same association to the domain name.
6. Acknowledgements 6. Acknowledgements
Many of the ideas in this document have been discussed over many Many of the ideas in this document have been discussed over many
years. More recently, the ideas have been discussed by the authors years. More recently, the ideas have been discussed by the authors
and others in a more focused fashion. In particular, some of the and others in a more focused fashion. In particular, some of the
ideas here originated with Paul Vixie, Dan Kaminsky, Jeff Hodges, ideas here originated with Paul Vixie, Dan Kaminsky, Jeff Hodges,
Simon Josefsson, among others. Simon Josefsson, Phill Hallam-Baker, among others.
7. References 7. References
7.1. Normative References 7.1. Normative References
[4347bis] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [4347bis] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security version 1.2", draft-ietf-tls-rfc4347-bis (work in Security version 1.2", draft-ietf-tls-rfc4347-bis (work in
progress), July 2010. progress), July 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 8, line 15 skipping to change at page 9, line 47
Got rid of the specification for ports within a single domain name. Got rid of the specification for ports within a single domain name.
Made the hash type one octet and used the DS registry instead of Made the hash type one octet and used the DS registry instead of
defining our own. defining our own.
Added "Necessarily" chosen in the title of Appendix A to show that we Added "Necessarily" chosen in the title of Appendix A to show that we
might (continue to) change our minds after discussion. might (continue to) change our minds after discussion.
Added Simon Josefsson to the acknowledgements. Added Simon Josefsson to the acknowledgements.
Appendix C. Changes between -01 and -02
Added the TLSRQ certificate type and its semantics.
Pointed to the IANA registry for DS hash types.
Added Phill Hallam-Baker to the acknowledgements.
Authors' Addresses Authors' Addresses
Paul Hoffman Paul Hoffman
VPN Consortium VPN Consortium
Email: paul.hoffman@vpnc.org Email: paul.hoffman@vpnc.org
Jakob Schlyter Jakob Schlyter
Kirei AB Kirei AB
 End of changes. 19 change blocks. 
33 lines changed or deleted 120 lines changed or added

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