draft-ietf-dane-protocol-11.txt   draft-ietf-dane-protocol-12.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: March 10, 2012 Kirei AB Expires: March 30, 2012 Kirei AB
September 7, 2011 September 27, 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-11 draft-ietf-dane-protocol-12
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 March 10, 2012. This Internet-Draft will expire on March 30, 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 42 skipping to change at page 2, line 42
7.2. TLSA Usages . . . . . . . . . . . . . . . . . . . . . . . 11 7.2. TLSA Usages . . . . . . . . . . . . . . . . . . . . . . . 11
7.3. TLSA Selectors . . . . . . . . . . . . . . . . . . . . . . 11 7.3. TLSA Selectors . . . . . . . . . . . . . . . . . . . . . . 11
7.4. TLSA Matching Types . . . . . . . . . . . . . . . . . . . 12 7.4. TLSA Matching 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
Appendix A. Operational Considerations for Deploying TLSA Appendix A. Operational Considerations for Deploying TLSA
Records . . . . . . . . . . . . . . . . . . . . . . . 14 Records . . . . . . . . . . . . . . . . . . . . . . . 14
A.1. Provisioning TLSA Records with Aliases . . . . . . . . . . 15 A.1. Provisioning TLSA Records with Aliases . . . . . . . . . . 14
A.1.1. Provisioning TLSA Records with CNAME Records . . . . . 15 A.1.1. Provisioning TLSA Records with CNAME Records . . . . . 15
A.1.2. Provisioning TLSA Records with DNAME Records . . . . . 16 A.1.2. Provisioning TLSA Records with DNAME Records . . . . . 16
A.1.3. Provisioning TLSA Records with Wildcards . . . . . . . 17 A.1.3. Provisioning TLSA Records with Wildcards . . . . . . . 16
A.2. Provisioning Using NS Records . . . . . . . . . . . . . . 17 A.2. Provisioning Using NS Records . . . . . . . . . . . . . . 17
A.3. Securing the Last Hop . . . . . . . . . . . . . . . . . . 17 A.3. Securing the Last Hop . . . . . . . . . . . . . . . . . . 17
A.4. Handling Certificate Rollover . . . . . . . . . . . . . . 17 A.4. Handling Certificate Rollover . . . . . . . . . . . . . . 17
Appendix B. Pseudocode for Using TLSA . . . . . . . . . . . . . . 17 Appendix B. Pseudocode for Using TLSA . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
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
skipping to change at page 9, line 26 skipping to change at page 9, line 26
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 name server to which one has trust anchors, or obtained from a remote name server to which one has
a secured channel of communication. a secured channel of communication.
If a certificate association contains a certificate usage, selector, If a certificate association contains a certificate usage, selector,
or matching type that is not understood by the TLS client, that or matching type that is not understood by the TLS client, that
certificate association MUST be marked as unusable. If the certificate association MUST be marked as unusable. If the
comparison data for a certificate is malformed, the certificate comparison data for a certificate is malformed, the certificate
association MUST be marked as unusable. association MUST be marked as unusable.
An application that requests TLS certificate associations using the An application that complies with this document first requests TLSA
method described in this document obtains zero or more usable records in order to make certificate associations. If that
certificate associations. If the application receives zero usable application receives zero usable certificate associations, it
certificate associations, it processes TLS in the normal fashion. processes TLS in the normal fashion; otherwise, that application
attempts to match each certificate association with the TLS server's
On the first match between one of the certificate association(s) and end entity certificate. If such a match is found, that application
the server's end entity certificate in TLS is found, the TLS client continues the TLS handshake and ignores any remaining certificate
continues the TLS handshake, ignoring remaining certificate associations; otherwise, that application MUST abort the TLS
associations. If no match between the usable certificate handshake with an "access_denied" error.
association(s) and the server's end entity certificate in TLS is
found, the TLS client MUST abort the handshake with an
"access_denied" error.
5. TLSA and DANE Use Cases and Requirements 5. TLSA and DANE Use Cases and Requirements
The different types of certificates for association defined in TLSA The different types of certificates for association defined in TLSA
are matched with various sections of [DANEUSECASES]. The three use are matched with various sections of [DANEUSECASES]. The three use
cases from section 3 of [DANEUSECASES] are covered in this protocol cases from section 3 of [DANEUSECASES] are covered in this protocol
as follows: as follows:
3.1 CA Constraints -- Implemented using certificate usage 0. 3.1 CA Constraints -- Implemented using certificate usage 0.
skipping to change at page 17, line 32 skipping to change at page 17, line 20
A.3. Securing the Last Hop A.3. Securing the Last Hop
[[ Need to add text here about the various ways that a client who is [[ Need to add text here about the various ways that a client who is
pulling in TLSA records can be sure that they are protected by pulling in TLSA records can be sure that they are protected by
DNSSEC. ]] DNSSEC. ]]
A.4. Handling Certificate Rollover A.4. Handling Certificate Rollover
[[ Need to add text here about how to handle a change in certificate. [[ Need to add text here about how to handle a change in certificate.
It would cover using two TLSA records at the same time, the TTL on It would cover using two TLSA records at the same time, the TTL on
the RRset, and coordinating that with the use of the certs in the TLS the RRset, and coordinating that with the use of the certificates in
server. ]] the TLS server. ]]
Appendix B. Pseudocode for Using TLSA Appendix B. Pseudocode for Using TLSA
[[ IMPORTANT NOTE FOR THE DANE WG: Please review this new appendix [[ IMPORTANT NOTE FOR THE DANE WG: Please review this new appendix
carefully. If you find differences between what is here and what is carefully. If you find differences between what is here and what is
in the rest of the draft, by all means please send it to the WG in the rest of the draft, by all means please send it to the WG
mailing list. The ensuing discussion will hopefully help everyone. mailing list. The ensuing discussion will hopefully help everyone.
]] ]]
This appendix describes the interactions given earlier in this This appendix describes the interactions given earlier in this
 End of changes. 7 change blocks. 
20 lines changed or deleted 17 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/