draft-ietf-dane-protocol-07.txt   draft-ietf-dane-protocol-08.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: December 5, 2011 Kirei AB Expires: January 2, 2012 Kirei AB
June 3, 2011 July 1, 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-07 draft-ietf-dane-protocol-08
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 December 5, 2011. This Internet-Draft will expire on January 2, 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 20 skipping to change at page 2, line 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Certificate Associations . . . . . . . . . . . . . . . . . 3 1.1. Certificate Associations . . . . . . . . . . . . . . . . . 3
1.2. Securing Certificate Associations . . . . . . . . . . . . 4 1.2. Securing Certificate Associations . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. The TLSA Resource Record . . . . . . . . . . . . . . . . . . . 5 2. The TLSA Resource Record . . . . . . . . . . . . . . . . . . . 5
2.1. TLSA RDATA Wire Format . . . . . . . . . . . . . . . . . . 5 2.1. TLSA RDATA Wire Format . . . . . . . . . . . . . . . . . . 5
2.1.1. The Certificate Type Field . . . . . . . . . . . . . . 5 2.1.1. The Certificate Type Field . . . . . . . . . . . . . . 5
2.1.2. The Reference Type Field . . . . . . . . . . . . . . . 6 2.1.2. The Reference Type Field . . . . . . . . . . . . . . . 6
2.1.3. The Certificate for Association Field . . . . . . . . 6 2.1.3. The Certificate for Association Field . . . . . . . . 6
2.2. TLSA RR Presentation Format . . . . . . . . . . . . . . . 6 2.2. TLSA RR Presentation Format . . . . . . . . . . . . . . . 6
2.3. TLSA RR Examples . . . . . . . . . . . . . . . . . . . . . 7 2.3. TLSA RR Examples . . . . . . . . . . . . . . . . . . . . . 6
3. Domain Names for TLS Certificate Associations . . . . . . . . 7 3. Domain Names for TLS Certificate Associations . . . . . . . . 7
4. Semantics and Features of TLSA Certificate Types . . . . . . . 7 4. Semantics and Features of TLSA Certificate Types . . . . . . . 7
4.1. End Entity Certificate . . . . . . . . . . . . . . . . . . 8 4.1. End Entity Certificate . . . . . . . . . . . . . . . . . . 7
4.2. Certification Authority Certificate . . . . . . . . . . . 8 4.2. Certification Authority Certificate . . . . . . . . . . . 8
4.3. Certificate Public Key . . . . . . . . . . . . . . . . . . 8 4.3. Certificate Public Key . . . . . . . . . . . . . . . . . . 8
4.4. Use of TLS Certificate Associations in TLS . . . . . . . . 9 4.4. Use of TLS Certificate Associations in TLS . . . . . . . . 9
5. TLSA and Use Cases and Requirements . . . . . . . . . . . . . 10 5. TLSA and DANE Use Cases and Requirements . . . . . . . . . . . 10
6. Mandatory-to-Implement Algorithms . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . 11 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
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.
skipping to change at page 3, line 28 skipping to change at page 3, line 28
trusting an external certificate authority (CA). Given that the DNS trusting an external certificate authority (CA). Given that the DNS
administrator for a domain name is authorized to give identifying administrator for a domain name is authorized to give identifying
information about the zone, it makes sense to allow that information about the zone, it makes sense to allow that
administrator to also make an authoritative binding between the administrator to also make an authoritative binding between the
domain name and a certificate that might be used by a host at that domain name and a certificate that might be used by a host at that
domain name. The easiest way to do this is to use the DNS. domain name. The easiest way to do this is to use the DNS.
There are many use cases for such functionality. [DANEUSECASES] There are many use cases for such functionality. [DANEUSECASES]
lists the ones that the protocol in this document is meant to apply lists the ones that the protocol in this document is meant to apply
to. [DANEUSECASES] also lists many requirements, most of which the to. [DANEUSECASES] also lists many requirements, most of which the
protocol in this document is believed to meet. protocol in this document is believed to meet. Section 5 covers the
applicability of this document to the use cases in detail.
This document applies to both TLS [RFC5246] and DTLS [4347bis]. In This document applies to both TLS [RFC5246] and DTLS [RFC4347bis].
order to make the document more readable, it mostly only talks about In order to make the document more readable, it mostly only talks
"TLS", but in all cases, it means "TLS or DTLS". This document only about "TLS", but in all cases, it means "TLS or DTLS". This document
relates to securely associating certificates for TLS and DTLS with only relates to securely associating certificates for TLS and DTLS
host names; other security protocols and other forms of with host names; other security protocols and other forms of
identification of TLS servers (such as IP addresses) are handled in identification of TLS servers (such as IP addresses) are handled in
other documents. For example, keys for IPsec are covered in other documents. For example, keys for IPsec are covered in
[RFC4025] and keys for SSH are covered in [RFC4255]. [RFC4025] and keys for SSH are covered in [RFC4255].
1.1. Certificate Associations 1.1. Certificate Associations
In this document, a certificate association is based on a In this document, a certificate association is based on a
cryptographic hash of a certificate (sometimes called a cryptographic hash of a certificate (sometimes called a
"fingerprint"), a public key, or on the certificate itself. For a "fingerprint"), a public key, or on the certificate itself. For a
fingerprint, a hash is taken of the binary, DER-encoded certificate fingerprint, a hash is taken of the binary, DER-encoded certificate
or public key, and that hash is the certificate association; the type or public key, and that hash is the certificate association; the type
of hash function used can be chosen by the DNS administrator. When of hash function used can be chosen by the DNS administrator. When
using the certificate itself in the certificate association, the using the certificate itself in the certificate association, the
entire certificate in the normal format is used. This document only entire certificate in the normal format is used. This document only
applies to PKIX [RFC5280] certificates. applies to PKIX [RFC5280] certificates, not certificates of other
formats. It also applies to public keys that are extracted from PKIX
certificates, not just full certificates.
Certificate associations are made between a certificate or public key Certificate associations are made between a certificate or public key
and a domain name. Server software that is running TLS that is found and a domain name. Server software that is running TLS that is found
at that domain name would use a certificate that has a certificate at that domain name would use a certificate that has a certificate
association given in the DNS, as described in this document. A DNS association given in the DNS, as described in this document. A DNS
query can return multiple certificate associations, such as in the query can return multiple certificate associations, such as in the
case of different server software on a single host using different case of different server software on a single host using different
certificates, or in the case that a server is changing from one certificates, or in the case that a server is changing from one
certificate to another. certificate to another.
1.2. Securing Certificate Associations 1.2. Securing Certificate Associations
This document defines a secure method to associate the certificate This document defines a secure method to associate the certificate
that is obtained from the TLS server with a domain name using DNS; that is obtained from the TLS server with a domain name using DNS;
the DNS information may need to be be protected by DNSSEC. Because the DNS information may need to be be protected by DNSSEC. Because
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.
[[ IMPORTANT NOTE FOR THIS DRAFT: There is still confusing and likely
wrong wording about DNSSEC. The editors acknowledge that we have not
completely specified where DNSSEC is and is not needed. We solicit
wording that will make this clearer. ]]
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. More detail is given in this document proof of origin of the data.
when DNSSEC is and is not required for securing certificate
associations.
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 9, line 24 skipping to change at page 9, line 22
for that domain name. A TLS client conforming to this protocol for that domain name. A TLS client conforming to this protocol
receiving a certificate for association of type 3 MUST find a receiving a certificate for association of type 3 MUST find a
matching SubjectPublicKeyInfo structure in one of the certificates matching SubjectPublicKeyInfo structure in one of the certificates
offered by the TLS server. offered by the TLS server.
The end entity certificate from TLS, regardless of whether it was The end entity certificate from TLS, regardless of whether it was
matched with a TLSA type 1 certificate or chained to a TLSA type 2 CA matched with a TLSA type 1 certificate or chained to a TLSA type 2 CA
certificate, might have at least one identifier in the subject or certificate, might have at least one identifier in the subject or
subjectAltName field of the matched certificates that matches the subjectAltName field of the matched certificates that matches the
expected identifier for the TLS server. Some specifications for expected identifier for the TLS server. Some specifications for
applications that run under TLS, such as [RFC2818] for HTTP, requires applications that run under TLS, such as [RFC2818] for HTTP, require
the server's certificate have a domain name that matches the host the server's certificate to have a domain name that matches the host
name expected by the client. Further, the TLS session that is to be name expected by the client. Further, the TLS session that is to be
set up MUST be for the specific port number and transport name that set up MUST be for the specific port number and transport name that
was given in the TLSA query. The matching or chaining MUST be done was given in the TLSA query. The matching or chaining MUST be done
within the life of the TTL on the TLSA record. within the life of the TTL on the TLSA record.
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
skipping to change at page 10, line 8 skipping to change at page 10, line 5
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 no match between the usable continues the TLS handshake. If no match between the usable
certificate association(s) and the server's end entity certificate in certificate association(s) and the server's end entity certificate in
TLS is found, the TLS client MUST abort the handshake with an TLS is found, the TLS client MUST abort the handshake with an
"access_denied" error. "access_denied" error.
5. TLSA and 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]. [[ IMPORTANT are matched with various sections of [DANEUSECASES]. [[ IMPORTANT
NOTICE, DANGER OF MOVING PARTS: this draft of the protocol is based NOTICE, DANGER OF MOVING PARTS: this draft of the protocol is based
on the -02 version of [DANEUSECASES]. As that document changes in on the -02 version of [DANEUSECASES]. As that document changes in
the WG and IETF Last Call, this protocol might change as well. ]] the WG and IETF Last Call, this protocol might change as well. ]]
Certificate type 1 (end entity certificate) is used for "certificate The three use cases from section 3 of [DANEUSECASES] are covered in
constraints". Certificate type 2 (CA certificate) is used for "CA this protocol as follows:
constraints". Certificate type 3 (public key structure) is used for
"CA constraints" and "certificate constraints", depending on which
certificate the public key is extracted from. All three types are
also used for "domain-issued certificates if the domain owner creates
its own CA certificate and then issues and end entity certificate
from that CA. Note that [DANEUSECASES] discusses "CA constraints"
and "certificate constraints" in terms of a "well-known CA"; TLSA
extends this in some cases to allow domain-issued (not-well-known)
CAs.
As described in [DANEUSECASES], when TLSA is deployed for CA 3.1 CA Constraints -- Implemented using certificate type 2. A
constraints, DNSSEC is not required. Both type 2 and type 3 can be hashed association is recommended for well-known certification
used for CA constraints, but because type 3 is only used for CA authorities.
constraints in some cases. This can easily be confusing in
deployments, so this particular lack of need for DNSSEC is not
emphasized in the rest of this document.
TLSA allows delegated services. It also supports opportunistic 3.2 Certificate Constraints -- Implemented using certificate type 1.
security and web services if the domain uses a certificate that
chains to a well-known CA that is trusted in the "legacy" TLS 3.3 Domain-Issued Certificates -- Implemented using certificate type
application. It also meets all the requirements listed except for 1 combined with any reference type, or by using certificate type 2
being compatible with DNS wildcards. together with a full certificate association.
The requirements from section 4 of [DANEUSECASES] are covered in this
protocol as follows (note that some of these might be excessively
glib):
Multiple Ports -- Covered in the TLSA request syntax.
No Downgrade -- Covered by DNSSEC itself.
Encapsulation -- Covered in the TLSA response semantics.
Predictability -- Covered by this spec.
Opportunistic Security -- Covered in the TLSA request syntax.
Combination -- Covered in the TLSA response semantics.
Roll-over -- Covered by the TTLs on the TLSA records.
Simple Key Management -- Implemented using Certificate Type 3.
Minimal Dependencies -- Covered in the TLSA response semantics.
Minimal Options -- Covered in the TLSA response semantics.
Wild Cards -- Covered in the TLSA request syntax.
Redirection -- Covered in the TLSA request syntax.
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).
TLS clients conforming to this specification MUST be able to TLS clients conforming to this specification MUST be able to
correctly interpret TLSA records containing certificate types 1 and correctly interpret TLSA records containing certificate types 1, 2
2. TLS clients conforming to this specification MUST be able to and 3. TLS clients conforming to this specification MUST be able to
compare a certificate for association with a certificate from TLS compare a certificate for association with a certificate from TLS
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 make such comparisons with reference type 2 and SHOULD be able to make such comparisons with reference type 2
(SHA-512). (SHA-512).
At the time this is written, it is expected that there will be a new At the time this is written, it is expected that there will be a new
family of hash algorithms called SHA-3 within the next few years. It family of hash algorithms called SHA-3 within the next few years. It
is expected that some of the SHA-3 algorithms will be mandatory is expected that some of the SHA-3 algorithms will be mandatory
and/or recommended for TLSA records after the algorithms are fully and/or recommended for TLSA records after the algorithms are fully
defined. At that time, this specification will be updated. defined. At that time, this specification will be updated.
skipping to change at page 11, line 40 skipping to change at page 12, line 11
This document creates a new registry, "Certificate Types for TLSA This document creates a new registry, "Certificate Types for TLSA
Resource Records". The registry policy is "RFC Required". The Resource Records". The registry policy is "RFC Required". The
initial entries in the registry are: initial entries in the registry are:
Value Short description Reference Value Short description Reference
---------------------------------------------------------- ----------------------------------------------------------
0 Reserved [This] 0 Reserved [This]
1 Certificate to identify an end entity [This] 1 Certificate to identify an end entity [This]
2 CA's certificate [This] 2 CA's certificate [This]
3 Public key as SubjectPublicKeyInfo [This] 3 Public key as SubjectPublicKeyInfo [This]
3-254 Unassigned 4-254 Unassigned
255 Private use 255 Private use
Applications to the registry can request specific values that have Applications to the registry can request specific values that have
yet to be assigned. yet to be assigned.
7.3. TLSA Hash Types 7.3. TLSA Hash Types
This document creates a new registry, "Hash Types for TLSA Resource This document creates a new registry, "Hash Types for TLSA Resource
Records". The registry policy is "Specification Required". The Records". The registry policy is "Specification Required". The
initial entries in the registry are: initial entries in the registry are:
skipping to change at page 12, line 18 skipping to change at page 12, line 36
1 SHA-256 NIST FIPS 180-3 1 SHA-256 NIST FIPS 180-3
2 SHA-512 NIST FIPS 180-3 2 SHA-512 NIST FIPS 180-3
3-254 Unassigned 3-254 Unassigned
255 Private use 255 Private use
Applications to the registry can request specific values that have Applications to the registry can request specific values that have
yet to be assigned. yet to be assigned.
8. Security Considerations 8. Security Considerations
[[ NOTE: Some of the text here is wrong in that DNSSEC does not need
to be used in all cases. This will be much better delineated and
described in a future version of the spec. ]]
The security of the protocols described in this document relies on The security of the protocols described in this document relies on
the security of DNSSEC as used by the client requesting A/AAAA and the security of DNSSEC as used by the client requesting A/AAAA and
TLSA records. TLSA records.
A DNS administrator who goes rogue and changes both the A/AAAA and A DNS administrator who goes rogue and changes both the A/AAAA and
TLSA records for a domain name can cause the user to go to an TLSA records for a domain name can cause the user to go to an
unauthorized server that will appear authorized, unless the client unauthorized server that will appear authorized, unless the client
performs certificate validation and rejects the certificate. That performs certificate validation and rejects the certificate. That
administrator could probably get a certificate issued anyway, so this administrator could probably get a certificate issued anyway, so this
is not an additional threat. is not an additional threat.
skipping to change at page 13, line 28 skipping to change at page 13, line 42
Phill Hallam-Baker, Simon Josefsson, Warren Kumari, Adam Langley, Ben Phill Hallam-Baker, Simon Josefsson, Warren Kumari, Adam Langley, Ben
Laurie, Ilari Liusvaara, Scott Schmit, and Ondrej Sury. Laurie, Ilari Liusvaara, Scott Schmit, and Ondrej Sury.
This document has also been greatly helped by many active This document has also been greatly helped by many active
participants of the DANE Working Group. participants of the DANE Working Group.
10. References 10. References
10.1. Normative References 10.1. Normative References
[4347bis] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security version 1.2", draft-ietf-tls-rfc4347-bis (work in
progress), July 2010.
[DANEUSECASES] [DANEUSECASES]
Barnes, R., "Use Cases and Requirements for DNS-based Barnes, R., "Use Cases and Requirements for DNS-based
Authentication of Named Entities (DANE)", Authentication of Named Entities (DANE)",
draft-ietf-dane-use-cases (work in progress), 2011. draft-ietf-dane-use-cases (work in progress), 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005. RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005. Extensions", RFC 4035, March 2005.
[RFC4347bis]
Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security version 1.2", draft-ietf-tls-rfc4347-bis (work in
progress), July 2010.
[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
 End of changes. 22 change blocks. 
60 lines changed or deleted 69 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/