draft-ietf-dane-protocol-08.txt   draft-ietf-dane-protocol-09.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: January 2, 2012 Kirei AB Expires: January 26, 2012 Kirei AB
July 1, 2011 July 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-08 draft-ietf-dane-protocol-09
Abstract Abstract
TLS and DTLS use PKIX certificates for authenticating the server. TLS and DTLS use PKIX certificates for authenticating the server.
Users want their applications to verify that the certificate provided Users want their applications to verify that the certificate provided
by the TLS server is in fact associated with the domain name they by the TLS server is in fact associated with the domain name they
expect. TLSA provides bindings of keys to domains that are asserted expect. TLSA provides bindings of keys to domains that are asserted
not by external entities, but by the entities that operate the DNS. not by external entities, but by the entities that operate the DNS.
This document describes how to use secure DNS to associate the TLS This document describes how to use secure DNS to associate the TLS
server's certificate with the intended domain name. server's certificate with the intended domain name.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 January 2, 2012. This Internet-Draft will expire on January 26, 2012.
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 2, line 38 skipping to change at page 2, line 38
6. Mandatory-to-Implement Algorithms . . . . . . . . . . . . . . 11 6. Mandatory-to-Implement Algorithms . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7.1. TLSA RRtype . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. TLSA RRtype . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. TLSA Certificate Types . . . . . . . . . . . . . . . . . . 11 7.2. TLSA Certificate Types . . . . . . . . . . . . . . . . . . 11
7.3. TLSA Hash Types . . . . . . . . . . . . . . . . . . . . . 12 7.3. TLSA Hash Types . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Appendix A. TLSA Interactions with Aliasing and Wildcards . . . . 14
A.1. TLSA and CNAME . . . . . . . . . . . . . . . . . . . . . . 15
A.2. TLSA and DNAME . . . . . . . . . . . . . . . . . . . . . . 16
A.3. TLSA and Wildcards . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
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
skipping to change at page 4, line 29 skipping to change at page 4, line 29
the certificate association was retrieved based on a DNS query, the the certificate association was retrieved based on a DNS query, the
domain name in the query is by definition associated with the domain name in the query is by definition associated with the
certificate. certificate.
DNSSEC, which is defined in RFCs 4033, 4034, and 4035 ([RFC4033], DNSSEC, which is defined in RFCs 4033, 4034, and 4035 ([RFC4033],
[RFC4034], and [RFC4035]), uses cryptographic keys and digital [RFC4034], and [RFC4035]), uses cryptographic keys and digital
signatures to provide authentication of DNS data. Information signatures to provide authentication of DNS data. Information
retrieved from the DNS and that is validated using DNSSEC is thereby retrieved from the DNS and that is validated using DNSSEC is thereby
proved to be the authoritative data. The DNSSEC signature MUST be proved to be the authoritative data. The DNSSEC signature MUST be
validated on all responses that use DNSSEC in order to assure the validated on all responses that use DNSSEC in order to assure the
proof of origin of the data. 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.
This document only relates to securely getting the DNS information This document only relates to securely getting the DNS information
for the certificate association using DNSSEC; other secure DNS for the certificate association using DNSSEC; other secure DNS
mechanisms are out of scope. mechanisms are out of scope.
1.3. Terminology 1.3. Terminology
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].
skipping to change at page 11, line 5 skipping to change at page 11, line 5
Combination -- Covered in the TLSA response semantics. Combination -- Covered in the TLSA response semantics.
Roll-over -- Covered by the TTLs on the TLSA records. Roll-over -- Covered by the TTLs on the TLSA records.
Simple Key Management -- Implemented using Certificate Type 3. Simple Key Management -- Implemented using Certificate Type 3.
Minimal Dependencies -- Covered in the TLSA response semantics. Minimal Dependencies -- Covered in the TLSA response semantics.
Minimal Options -- Covered in the TLSA response semantics. Minimal Options -- Covered in the TLSA response semantics.
Wild Cards -- Covered in the TLSA request syntax. Wild Cards -- Covered in the TLSA request syntax; see Appendix A.
Redirection -- Covered in the TLSA request syntax. Redirection -- Covered in the TLSA request syntax; see Appendix A.
6. Mandatory-to-Implement Algorithms 6. Mandatory-to-Implement Algorithms
DNS systems conforming to this specification MUST be able to create DNS systems conforming to this specification MUST be able to create
TLSA records containing certificate types 1 and 2. DNS systems TLSA records containing certificate types 1 and 2. DNS systems
conforming to this specification MUST be able to create TLSA records conforming to this specification MUST be able to create TLSA records
using reference type 0 (no hash used) and reference type 1 (SHA-256), 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 and SHOULD be able to create TLSA records using reference type 2
(SHA-512). (SHA-512).
skipping to change at page 14, line 32 skipping to change at page 14, line 32
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
10.2. Informative References 10.2. Informative References
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC4025] Richardson, M., "A Method for Storing IPsec Keying [RFC4025] Richardson, M., "A Method for Storing IPsec Keying
Material in DNS", RFC 4025, March 2005. Material in DNS", RFC 4025, March 2005.
[RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely [RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely
Publish Secure Shell (SSH) Key Fingerprints", RFC 4255, Publish Secure Shell (SSH) Key Fingerprints", RFC 4255,
January 2006. January 2006.
Appendix A. TLSA Interactions with Aliasing and Wildcards
The TLSA RR is not special in the DNS; it acts exactly like any other
RRtype where the queried name has one or more labels prefixed to the
base name, such as the SRV RRtype [RFC2782]. This sometimes causes
confusion for some developers when using DNS aliasing and wildcards.
A.1. TLSA and CNAME
Using CNAME to alias in DNS only aliases from the exact name given,
not any zones below the given name. For example, assume that a zone
file has only the following:
sub1.example.com. IN CNAME sub2.example.com.
In this case, a request for "bottom.sub1.example.com" would not
return any records because the CNAME given only aliases the name
given. Assume, instead, the zone file has the following:
sub3.example.com. IN CNAME sub4.example.com.
bottom.sub3.example.com. IN CNAME bottom.sub4.example.com.
In this case, a request for bottom.sub3.example.com would in fact
return the CNAME record.
Application implementations and full-service resolvers request DNS
records using libraries that automatically follow CNAME and DNAME
aliasing. This allows hosts to put TLSA records in their own zones
or to use CNAME to do redirection. Thus, any of the following three
examples are acceptable:
; TLSA record for orignial domin has CNAME to target domain
;
sub5.example.com. IN CNAME sub6.example.com.
_443_tcp.sub5.example.com. IN CNAME _443_tcp.sub6.example.com.
sub6.example.com. IN A 10.0.0.0
_443_tcp.sub6.example.com. IN TLSA 1 1 536a570ac49d9ba4...
or
; TLSA record is duplicated in target domain
;
sub5.example.com. IN CNAME sub6.example.com.
_443_tcp.sub5.example.com. IN TLSA 2 0 308202c5308201ab...
sub6.example.com. IN A 10.0.0.0
_443_tcp.sub6.example.com. IN TLSA 2 0 308202c5308201ab...
or
; No TLSA record in target domain
;
sub5.example.com. IN CNAME sub6.example.com.
_443_tcp.sub5.example.com. IN TLSA 2 0 308202c5308201ab...
sub6.example.com. IN A 10.0.0.0
A.2. TLSA and DNAME
Using DNAME records allows a zone owner to alias an entire subtree of
names below the name that has the DNAME. This allows the wholesale
aliasing of prefixed records such as those used by TLSA, SRV, and so
on without aliasing the name itself.
A.3. TLSA and Wildcards
Wildcards are generally not terribly useful for RRtypes that require
prefixing because you can only wildcard at a layer below the host
name. For exaple, if you want to have the same TLSA record for every
port and every protocol for www.example.com, you might have
*._tcp.www.example.com. IN TLSA 1 1 5c1502a6549c423b...
This is possibly useful in some scenarios where the same service is
offered on many ports.
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
Email: jakob@kirei.se Email: jakob@kirei.se
 End of changes. 10 change blocks. 
8 lines changed or deleted 93 lines changed or added

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