draft-ietf-dane-use-cases-05.txt   rfc6394.txt 
DANE R. Barnes Internet Engineering Task Force (IETF) R. Barnes
Internet-Draft BBN Technologies Request for Comments: 6394 BBN Technologies
Intended status: Informational July 28, 2011 Category: Informational October 2011
Expires: January 29, 2012 ISSN: 2070-1721
Use Cases and Requirements for DNS-based Authentication of Named Use Cases and Requirements for DNS-Based Authentication
Entities (DANE) of Named Entities (DANE)
draft-ietf-dane-use-cases-05.txt
Abstract Abstract
Many current applications use the certificate-based authentication Many current applications use the certificate-based authentication
features in TLS to allow clients to verify that a connected server features in Transport Layer Security (TLS) to allow clients to verify
properly represents a desired domain name. Typically, this that a connected server properly represents a desired domain name.
authentication has been based on PKIX certificate chains rooted in Typically, this authentication has been based on PKIX certificate
well-known CAs, but additional information can be provided via the chains rooted in well-known certificate authorities (CAs), but
DNS itself. This document describes a set of use cases in which the additional information can be provided via the DNS itself. This
DNS and DNSSEC could be used to make assertions that support the TLS document describes a set of use cases in which the DNS and DNS
authentication process. The main focus of this document is TLS Security Extensions (DNSSEC) could be used to make assertions that
server authentication, but it also covers TLS client authentication support the TLS authentication process. The main focus of this
for applications where TLS clients are identified by domain names. document is TLS server authentication, but it also covers TLS client
authentication for applications where TLS clients are identified by
Status of this Memo domain names.
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on January 29, 2012. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6394.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions .....................................................4
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Use Cases .......................................................4
3.1. CA Constraints . . . . . . . . . . . . . . . . . . . . . . 5 3.1. CA Constraints .............................................5
3.2. Service Certificate Constraints . . . . . . . . . . . . . 6 3.2. Service Certificate Constraints ............................6
3.3. Trust Anchor Assertion and Domain-Issued Certificates . . 7 3.3. Trust Anchor Assertion and Domain-Issued Certificates ......7
3.4. Delegated Services . . . . . . . . . . . . . . . . . . . . 9 3.4. Delegated Services .........................................9
4. Other Requirements . . . . . . . . . . . . . . . . . . . . . . 9 4. Other Requirements .............................................10
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 5. Acknowledgements ...............................................11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations ........................................11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. References .....................................................11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References ......................................11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 7.2. Informative References ....................................12
8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
Transport-Layer Security (TLS) is used as the basis for security Transport Layer Security (TLS) is used as the basis for security
features in many modern Internet application service protocols to features in many modern Internet application service protocols to
provide secure client-server connections [RFC5246]. It underlies provide secure client-server connections [RFC5246]. It underlies
secure HTTP and secure email [RFC2818][RFC2595][RFC3207], and secure HTTP and secure email [RFC2818] [RFC2595] [RFC3207], and
provides hop-by-hop security in real-time multimedia and instant- provides hop-by-hop security in real-time multimedia and instant-
messaging protocols [RFC3261][RFC6120]. messaging protocols [RFC3261] [RFC6120].
Application service clients typically establish TLS connections to Application service clients typically establish TLS connections to
application servers identified by DNS domain names. The process of application servers identified by DNS domain names. The process of
obtaining this "source" domain is application specific [RFC6125]. obtaining this "source" domain is application specific [RFC6125].
The name could be entered by a user or found through an automated The name could be entered by a user or found through an automated
discovery process such as an SRV or NAPTR record. After obtaining discovery process such as an SRV or NAPTR record. After obtaining
the address of the server via an A or AAAA DNS record, the client the address of the server via an A or AAAA DNS record, the client
conducts a TLS handshake with the server, during which the server conducts a TLS handshake with the server, during which the server
presents a PKIX certificate [RFC5280]. The TLS layer performs PKIX presents a PKIX certificate [RFC5280]. The TLS layer performs PKIX
validation of the certificate, including verification that the validation of the certificate, including verification that the
skipping to change at page 3, line 39 skipping to change at page 3, line 21
The certificate authorities (CAs) that issue PKIX certificates are The certificate authorities (CAs) that issue PKIX certificates are
asserting bindings between domain names and the public keys they asserting bindings between domain names and the public keys they
certify. Application service clients are verifying these bindings certify. Application service clients are verifying these bindings
and making authorization decisions -- whether to proceed with and making authorization decisions -- whether to proceed with
connections -- based on them. connections -- based on them.
Clients thus rely on CAs to correctly assert bindings between public Clients thus rely on CAs to correctly assert bindings between public
keys and domain names, in the sense that the holder of the keys and domain names, in the sense that the holder of the
corresponding private key should be the domain holder. Today, an corresponding private key should be the domain holder. Today, an
attacker can successfully authenticate as a given application service attacker can successfully authenticate as a given application service
domain if he can obtain a "mis-issued" ciertificate from one of the domain if he can obtain a "mis-issued" certificate from one of the
widely-used CAs -- a certificate containing the victim application widely used CAs -- a certificate containing the victim application
service's domain name and a public key whose corresponding private service's domain name and a public key whose corresponding private
key is held by the attacker. If the attacker can additionally insert key is held by the attacker. If the attacker can additionally insert
himself as a man in the middle between an client and server (e.g., himself as a "man in the middle" between a client and server (e.g.,
through DNS cache poisoning of an A or AAAA record), then the through DNS cache poisoning of an A or AAAA record), then the
attacker can convince the client that a server of the attacker's attacker can convince the client that a server of the attacker's
choice legitimately represents the victim's application service. choice legitimately represents the victim's application service.
With the advent of DNSSEC [RFC4033], it is now possible for DNS name With the advent of DNSSEC [RFC4033], it is now possible for DNS name
resolution to provide its information securely, in the sense that resolution to provide its information securely, in the sense that
clients can verify that DNS information was provided by the domain clients can verify that DNS information was provided by the domain
holder and not tampered with in transit. The goal of technologies operator and not tampered with in transit. The goal of technologies
for DNS-based Authentication of Named Entities (DANE) is to use the for DNS-based Authentication of Named Entities (DANE) is to use the
DNS and DNSSEC to provide additional information about the DNS and DNSSEC to provide additional information about the
cryptographic credentials associated with a domain, so that clients cryptographic credentials associated with a domain, so that clients
can use this information to increase the level of assurance they can use this information to increase the level of assurance they
receive from the TLS handshake process. This document describes a receive from the TLS handshake process. This document describes a
set of use cases that capture specific goals for using the DNS in set of use cases that capture specific goals for using the DNS in
this way, and a set of requirements that the ultimate DANE mechanism this way, and a set of requirements that the ultimate DANE mechanism
should satisfy. should satisfy.
Finally, it should be noted that although this document will Finally, it should be noted that although this document will
frequently use HTTPS as an example application service, DANE is frequently use HTTPS as an example application service, DANE is
intended to apply equally to all applications that make use of TLS to intended to apply equally to all applications that make use of TLS to
connect to application services named by domain names. connect to application services identified by domain names.
2. Definitions 2. Definitions
This document also makes use of standard PKIX, DNSSEC, and TLS This document also makes use of standard PKIX, DNSSEC, and TLS
terminology. See RFC 5280 [RFC5280], RFC 4033 [RFC4033], and RFC terminology. See RFC 5280 [RFC5280], RFC 4033 [RFC4033], and
5246 [RFC5246], respectively, for these terms. In addition, terms RFC 5246 [RFC5246], respectively, for these terms. In addition,
related to TLS-protected application services and DNS names are taken terms related to TLS-protected application services and DNS names are
from RFC 6125 [RFC6125]. taken from RFC 6125 [RFC6125].
Note in particular that the term "server" in this document refers to Note in particular that the term "server" in this document refers to
the server role in TLS, rather than to a host. Multiple servers of the server role in TLS, rather than to a host. Multiple servers of
this type may be co-located on a single physical host, using this type may be co-located on a single physical host, often using
different ports, and each of these can use different certificates. different ports, and each of these can use different certificates.
This document refers several times to the notion of a "domain
holder". This term is understood to mean the entity that is
authorized to control the contents of a particular zone. For
example, the registrants of 2nd- or 3rd-level domains are the holders
of those domains. The holder of a particular domain is not
necessarily the entity that operates the zone.
It should be noted that the presence of a valid DNSSEC signature in a
DNS reply does not necessarily imply that the records protected by
that signature were authorized by the domain holder. The distinction
between the holder of a domain and the operator of the corresponding
zone has several security implications, which are discussed in the
individual use cases below.
3. Use Cases 3. Use Cases
In this section, we describe the major use cases that the DANE In this section, we describe the major use cases that the DANE
mechanism should support. This list is not intended to represent all mechanism should support. This list is not intended to represent all
possible ways that the DNS can be used to support TLS authentication. possible ways that the DNS can be used to support TLS authentication.
Rather it represents the specific cases that comprise the initial Rather, it represents the specific cases that comprise the initial
goals for DANE. goals for DANE.
In the below use cases, we will refer to the following dramatis In the use cases below, we will refer to the following dramatis
personae: personae:
Alice: The operator of a TLS-protected application service on the Alice: The operator of a TLS-protected application service on the
host alice.example.com, and administrator of the corresponding DNS host alice.example.com, and administrator of the corresponding
zone. DNS zone.
Bob: A client connecting to alice.example.com.
Bob: A client connecting to alice.example.com
Charlie: A well-known CA that issues certificates with domain names Charlie: A well-known CA that issues certificates with domain names
as identifiers as identifiers.
Oscar: An outsourcing provider that operates TLS-protected Oscar: An outsourcing provider that operates TLS-protected
application services on behalf of customers application services on behalf of customers.
Trent: A CA that issues certificates with domain names as Trent: A CA that issues certificates with domain names as
identifiers, but is not generally well-known. identifiers, but is not generally well-known.
These use cases are framed in terms of adding verification steps to These use cases are framed in terms of adding verification steps to
TLS server identity checking on the part of application service TLS server identity checking on the part of application service
clients. In application services where the clients are also clients. In application services where the clients are also
identified by domain names (e.g., XMPP server-to-server connections), identified by domain names (e.g., Extensible Messaging and Presence
the same considerations and use cases are applicable to the Protocol (XMPP) server-to-server connections), the same
application server's checking of identities in TLS client considerations and use cases are applicable to the application
certificates. server's checking of identities in TLS client certificates.
3.1. CA Constraints 3.1. CA Constraints
Alice runs a website on alice.example.com and has obtained a Alice runs a website on alice.example.com and has obtained a
certificate from the well-known CA Charlie. She is concerned that certificate from the well-known CA Charlie. She is concerned that
other well-known CAs might issue certificates for alice.example.com other well-known CAs might issue certificates for alice.example.com
without her authorization, which clients would accept. Alice would without her authorization, which clients would accept. Alice would
like to provide a mechanism for visitors to her site to know that like to provide a mechanism for visitors to her site to know that
they should expect alice.example.com to use a certificate issued they should expect alice.example.com to use a certificate issued
under the CA that she uses (Charlie) and not another CA. That is, under the CA that she uses (Charlie) and not another CA. That is,
Alice is recommending that the client verify that there is a valid Alice is recommending that the client verify that there is a valid
certificate chain from the server certificate to Charlie before certificate chain from the server certificate to Charlie before
accepting the server certificate. (For example, in the TLS accepting the server certificate. (For example, in the TLS
handshake, the server might include Charlie's certificate in the handshake, the server might include Charlie's certificate in the
server Certificate message's certificate_list structure [RFC5246]). server Certificate message's certificate_list structure [RFC5246]).
When Bob connects to alice.example.com, he uses this mechanism to When Bob connects to alice.example.com, he uses this mechanism to
verify that that the certificate presented by the server was issued verify that the certificate presented by the server was issued under
under the proper CA, Charlie. Bob also performs the normal PKIX the proper CA, Charlie. Bob also performs the normal PKIX validation
validation procedure for this certificate, in particular verifying procedure for this certificate, in particular verifying that the
that the certificate chains to a trust anchor (possibly Charlie's CA, certificate chains to a trust anchor (possibly Charlie's CA, if Bob
if Bob accepts Charlie's CA as a trust anchor). accepts Charlie's CA as a trust anchor).
Alice may wish to provide similar information to an external CA Alice may wish to provide similar information to an external CA
operator Charlie. Prior to issuing a certificate for operator, Charlie. Prior to issuing a certificate for
alice.example.com to someone claiming to be Alice, Charlie needs to alice.example.com to someone claiming to be Alice, Charlie needs to
verify that Alice is actually requesting a certificate. Alice could verify that Alice is actually requesting a certificate. Alice could
indicate her preferred CA using DANE to CAs as well as relying indicate her preferred CA using DANE to CAs as well as relying
parties. Charlie could then check to see whether Alice said that her parties. Charlie could then check to see whether Alice said that her
certificates should be issued by Charlie or another CA. Note that certificates should be issued by Charlie or another CA. Note that
this check does not guarantee that the precise entity requesting a this check does not guarantee that the precise entity requesting a
certification from Charlie actually represents Alice, only that Alice certification from Charlie actually represents Alice -- only that
has authorized Charlie to issue certificates for her domain to Alice has authorized Charlie to issue certificates for her domain to
properly authorized individuals. properly authorized individuals.
In principle, DANE information expressing CA constraints can be In principle, DANE information expressing CA constraints can be
presented with or without DNSSEC protection. Presenting DANE presented with or without DNSSEC protection. Presenting DANE
information without DNSSEC protection does not introduce any new information without DNSSEC protection does not introduce any new
vulnerabilities, but neither does it add much assurance. Deletion of vulnerabilities, but neither does it add much assurance. Deletion of
records removes the protection provided by this constraint, but the records removes the protection provided by this constraint, but the
client is still protected by CA practices (as now). Injected or client is still protected by CA practices (as now). Injected or
modified false records are not useful unless the attacker can also modified false records are not useful unless the attacker can also
obtain a certificate for the target domain. Thus, In the worst case, obtain a certificate for the target domain. Thus, in the worst case,
tampering with these constraints increases the risk of false tampering with these constraints increases the risk of false
authentication to the level that is now standard. authentication to the level that is now standard.
Using DANE information for CA constraints without DNSSEC provides a Using DANE information for CA constraints without DNSSEC provides a
very small incremental security feature. Many common attacks against very small incremental security feature. Many common attacks against
TLS connections already require the attacker to inject false A or TLS connections already require the attacker to inject false A or
AAAA records in order to steer the victim client to the attacker's AAAA records in order to steer the victim client to the attacker's
server. An attacker that can already inject false DNS records can server. An attacker that can already inject false DNS records can
also provide fake DANE information (without DNSSEC) by simply also provide fake DANE information (without DNSSEC) by simply
spoofing the additional records required to carry the DANE spoofing the additional records required to carry the DANE
information. information.
Injected or modified false DANE information of this type can be used Injected or modified false DANE information of this type can be used
for denial of service, even if the attacker does not have a for denial of service, even if the attacker does not have a
certificate for the target domain. If an attacker can modify DNS certificate for the target domain. If an attacker can modify DNS
responses that a target host receives, however, there are already responses that a target host receives, however, there are already
much simpler ways of denying service, such as providing a false A or much simpler ways of denying service, such as providing a false A or
AAAA record. In this case, DNSSEC is not helpful, since an attacker AAAA record. In this case, DNSSEC is not helpful, since an attacker
could still case a denial of service by blocking all DNS responses could still cause a denial of service by blocking all DNS responses
for the target domain. for the target domain.
Continuing to require PKIX validation also limits the degree to which Continuing to require PKIX validation also limits the degree to which
DNS operators (as distinct from the holders of domains) can interfere DNS operators (as distinct from the holders of domains) can interfere
with TLS authentication through this mechanism. As above, even if a with TLS authentication through this mechanism. As above, even if a
DNS operator falsifies DANE records, it cannot masquerade as the DNS operator falsifies DANE records, it cannot masquerade as the
target server unless it can also obtain a certificate for the target target server unless it can also obtain a certificate for the target
domain. domain.
3.2. Service Certificate Constraints 3.2. Service Certificate Constraints
skipping to change at page 7, line 7 skipping to change at page 7, line 6
Alice runs a website on alice.example.com and has obtained a Alice runs a website on alice.example.com and has obtained a
certificate from the well-known CA Charlie. She is concerned about certificate from the well-known CA Charlie. She is concerned about
additional, unauthorized certificates being issued by Charlie as well additional, unauthorized certificates being issued by Charlie as well
as by other CAs. She would like to provide a way for visitors to her as by other CAs. She would like to provide a way for visitors to her
site to know that they should expect alice.example.com to present a site to know that they should expect alice.example.com to present a
specific certificate. In TLS terms, Alice is letting Bob know that specific certificate. In TLS terms, Alice is letting Bob know that
this specific certificate must be the first certificate in the server this specific certificate must be the first certificate in the server
Certificate message's certificate_list structure [RFC5246]. Certificate message's certificate_list structure [RFC5246].
When Bob connects to alice.example.com, he uses this mechanism to When Bob connects to alice.example.com, he uses this mechanism to
verify that that the certificate presented by the server is the verify that the certificate presented by the server is the correct
correct certificate. Bob also performs the normal PKIX validation certificate. Bob also performs the normal PKIX validation procedure
procedure for this certificate, in particular verifying that the for this certificate, in particular verifying that the certificate
certificate chains to a trust anchor. chains to a trust anchor.
The security implications for this case are the same as for the "CA The security implications for this case are the same as for the "CA
Constraints" case above. Constraints" case above.
3.3. Trust Anchor Assertion and Domain-Issued Certificates 3.3. Trust Anchor Assertion and Domain-Issued Certificates
Alice would like to be able to generate and use certificates for her Alice would like to be able to generate and use certificates for her
website on alice.example.com without involving an external CA at all. website on alice.example.com without involving an external CA at all.
Alice can generate her own certificates today, making self-signed Alice can generate her own certificates today, making self-signed
certificates and possibly certificates subordinate to those certificates and possibly certificates subordinate to those
certificates. When Bob receives such a certificate in a TLS certificates. When Bob receives such a certificate in a TLS
handshake, however, he doesn't automatically have a way to verify handshake, however, he doesn't automatically have a way to verify
that the issuer of the certificate is actually Alice, because he that the issuer of the certificate is actually Alice, because he
doesn't necessarily possess Alice's corresponding trust anchor. This doesn't necessarily possess Alice's corresponding trust anchor. This
concerns him because an attacker could present a different concerns him because an attacker could present a different
certificate and perform a man in the middle attack. Bob would like certificate and perform a man-in-the-middle attack. Bob would like
to protect against this. to protect against this.
Alice would thus like to publish information so that visitors to her Alice would thus like to publish information so that visitors to her
site can know that the certificates presented by her application site can know that the certificates presented by her application
services are legitimately hers. When Bob connects to services are legitimately hers. When Bob connects to
alice.example.com, he uses this information to verify that the alice.example.com, he uses this information to verify that the
certificate presented by the server has been issued by Alice. Since certificate presented by the server has been issued by Alice. Since
Bob can bind certificates to Alice in this way, he can use Alice's CA Bob can bind certificates to Alice in this way, he can use Alice's CA
as a trust anchor for purposes of validating certificates for as a trust anchor for purposes of validating certificates for
alice.example.com. Alice can additionally recommend that clients alice.example.com. Alice can additionally recommend that clients
accept only her certificates using the CA constraints described accept only her certificates using the CA constraints described
above. above.
As in Section Section 3.1 above, Alice may wish to represent this As in Section 3.1 above, Alice may wish to represent this information
information to potential third-party CAs (Charlie) as well as to to potential third-party CAs (Charlie) as well as to relying parties
relying parties (Bob). Since publishing a certificate in a DANE (Bob). Since publishing a certificate in a DANE record of this form
record of this form authorizes the holder of the corresponding authorizes the holder of the corresponding private key to represent
private key to represent alice.example.com, a CA that has received a alice.example.com, a CA that has received a request to issue a
request to issue a certificate from alice.example.com could use the certificate from alice.example.com could use the DANE information to
DANE information to verify the requestor's authorization to receive a verify the requestor's authorization to receive a certificate for
certificate for that domain. For example, a CA might choose to issue that domain. For example, a CA might choose to issue a certificate
a certificate for a given domain name and public key only when the for a given domain name and public key only when the holder of the
holder of the domain name has provisioned DANE information with a domain name has provisioned DANE information with a certificate
certificate containing the public key. containing the public key.
Note that this use case is functionally equivalent to the case where Note that this use case is functionally equivalent to the case where
Alice doesn't issue her own certificates, but uses Trent's CA, which Alice doesn't issue her own certificates, but uses Trent's CA, which
is not well-known. In this case, Alice would be advising Bob that he is not well-known. In this case, Alice would be advising Bob that he
should treat Trent as a trust anchor for purposes of validating should treat Trent as a trust anchor for purposes of validating
Alice's certificates, rather than a CA operated by Alice herself. Alice's certificates, rather than a CA operated by Alice herself.
Bob would thus need a way to securely obtain Trent's trust anchor Bob would thus need a way to securely obtain Trent's trust anchor
information, namely through DANE information. information, namely through DANE information.
Alice's advertising of trust anchor material in this way does not Alice's advertising of trust anchor material in this way does not
guarantee that Bob will accept the advertised trust anchor. For guarantee that Bob will accept the advertised trust anchor. For
example, Bob might have out-of-band information (such as a pre- example, Bob might have out-of-band information (such as a
existing local policy) that indicates that the CA advertised by Alice pre-existing local policy) that indicates that the CA advertised by
(Trent's CA) is not trustworthy, which would lead him to decide not Alice (Trent's CA) is not trustworthy, which would lead him to decide
to accept Trent as a TA, and thus to reject Alice's certificate if it not to accept Trent as a trust anchor, and thus to reject Alice's
is issued under Trent's CA. certificate if it is issued under Trent's CA.
Providing trust anchor material in this way clearly requires DNSSEC, Providing trust anchor material in this way clearly requires DNSSEC,
since corrupted or injected records could be used by an attacker to since corrupted or injected records could be used by an attacker to
cause clients to trust an attacker's certificate (assuming that the cause clients to trust an attacker's certificate (assuming that the
attacker's certificate is not rejected by some other local policy). attacker's certificate is not rejected by some other local policy).
Deleted records will only result in connection failure and denial of Deleted records will only result in connection failure and denial of
service, although this could result in clients re-connecting without service, although this could result in clients re-connecting without
TLS (a downgrade attack), depending on the application. Therefore, TLS (a downgrade attack), depending on the application. Therefore,
in order for this use case to be safe, applications must forbid in order for this use case to be safe, applications must forbid
clients from falling back to unsecured channels when records appear clients from falling back to unsecured channels when records appear
to have been deleted (e.g., when a missing record has no NSEC or to have been deleted (e.g., when a missing record has no NSEC or
NSEC3 record). NSEC3 record).
By the same token, this use case puts the most power in the hands of By the same token, this use case puts the most power in the hands of
DNS operators. Since the operator of the appropriate DNS zone has de DNS operators. Since the operator of the appropriate DNS zone has
facto control over the content and signing of the zone, he can create de facto control over the content and signing of the zone, he can
false DANE records that bind a malicious party's certificate to a create false DANE records that bind a malicious party's certificate
domain. This risk is especially important to keep in mind in cases to a domain. This risk is especially important to keep in mind in
where the operator of a DNS zone is a different entity than the cases where the operator of a DNS zone is a different entity than the
holder of the domain, as in DNS hosting/outsourcing arrangements, holder of the domain, as in DNS hosting/outsourcing arrangements,
since in these cases the DNS operator might be able to make changes since in these cases the DNS operator might be able to make changes
to a domain that are not authorized by the holder of the domain. to a domain that are not authorized by the holder of the domain.
It should be noted that DNS operators already have the ability to It should be noted that DNS operators already have the ability to
obtain certificates for domains under their control, under certain CA obtain certificates for domains under their control, under certain CA
policies. In the current system, CAs need to verify that an entity policies. In the current system, CAs need to verify that an entity
requesting a certificate for a domain is actually the legitimate requesting a certificate for a domain is actually the legitimate
holder of that domain. Typically this is done using information holder of that domain. Typically, this is done using information
published about that domain, such as WHOIS email addresses or special published about that domain, such as WHOIS email addresses or special
records inserted into a domain. By manipulating these values, it is records inserted into a domain. By manipulating these values, it is
possible for DNS operators to obtain certificates from some well- possible for DNS operators to obtain certificates from some well-
known certificate authorities today without authorization from the known certificate authorities today without authorization from the
true domain holder. true domain holder.
3.4. Delegated Services 3.4. Delegated Services
In addition to guarding against CA mis-issue, CA constraints and In addition to guarding against CA mis-issue, CA constraints and
certificate constraints can also be used to constrain the set of certificate constraints can also be used to constrain the set of
certificates that can be used by an outsourcing provider. Suppose certificates that can be used by an outsourcing provider. Suppose
that Oscar operates alice.example.com on behalf of Alice. In that Oscar operates alice.example.com on behalf of Alice. In
particular, Oscar then has de facto control over what certificates to particular, Oscar then has de facto control over what certificates to
present in TLS handshakes for alice.example.com. In such cases, present in TLS handshakes for alice.example.com. In such cases,
there are few ways that DNS-based information about TLS certificates there are a few ways that DNS-based information about TLS
could be configured, for example: certificates could be configured; for example:
1. Alice has the A/AAAA records in her DNS and can sign them along 1. Alice has the A/AAAA records in her DNS and can sign them along
with the DANE record, but Oscar and Alice now need to have tight with the DANE record, but Oscar and Alice now need to have tight
coordination if the addresses and/or the certificates change. coordination if the addresses and/or the certificates change.
2. Alice refers to Oscar's DNS by delegating a sub-domain name to 2. Alice refers to Oscar's DNS by delegating a sub-domain name to
Oscar, and has no control over the A/AAAA, DANE or any other Oscar, and has no control over the A/AAAA, DANE, or any other
pieces under Oscar's control. pieces under Oscar's control.
3. Alice can put DANE records into her DNS server, but delegate the 3. Alice can put DANE records into her DNS server but delegate the
address records to Oscar's DNS server. This means that Alice can address records to Oscar's DNS server. This means that Alice can
control the usage of certificates but Oscar is free to move the control the usage of certificates, but Oscar is free to move the
servers around as needed. The only coordination needed is when servers around as needed. The only coordination needed is when
the certificates change, and then it would depend on how the DANE the certificates change, and then it would depend on how the DANE
record is set up (i.e. a CA or an end entity certificate record is set up (i.e., a CA or an end-entity certificate
pointer). pointer).
Which of these deployment patterns is used in a given deployment will Which of these deployment patterns is used in a given deployment will
determine what sort of constraints can be expressed by which actors. determine what sort of constraints can be expressed by which actors.
In cases where Alice controls DANE records (1 and 3), she can use CA In cases where Alice controls DANE records (1 and 3), she can use CA
and certificate constraints to control what certificates Oscar and certificate constraints to control what certificates Oscar
presents for Alice's application services. For instance, Alice might presents for Alice's application services. For instance, Alice might
require Oscar to use certificates under a given set of CAs. This require Oscar to use certificates under a given set of CAs. This
control, however, requires that Alice update DANE records when Oscar control, however, requires that Alice update DANE records when Oscar
needs to change certificates. Cases where Oscar controls DANE needs to change certificates. Cases where Oscar controls DANE
skipping to change at page 10, line 22 skipping to change at page 10, line 28
Encapsulation: If there is DANE information for the name Encapsulation: If there is DANE information for the name
alice.example.com, it must only affect application services hosted alice.example.com, it must only affect application services hosted
at alice.example.com. at alice.example.com.
Predictability: Client behavior in response to DANE information must Predictability: Client behavior in response to DANE information must
be defined in the DANE specification as precisely as possible, be defined in the DANE specification as precisely as possible,
especially for cases where DANE information might conflict with especially for cases where DANE information might conflict with
PKIX information. PKIX information.
Opportunistic Security The DANE mechanism must allow a client to Opportunistic Security: The DANE mechanism must allow a client to
determine whether DANE information is available for a site, so determine whether DANE information is available for a site, so
that a client can provide the highest level of security possible that a client can provide the highest level of security possible
for a given application service. Clients that do not support DANE for a given application service. Clients that do not support DANE
should continue to work as specified, regardless of whether DANE should continue to work as specified, regardless of whether DANE
information is present or not. information is present or not.
Combination: The DANE mechanism must allow multiple DANE statements Combination: The DANE mechanism must allow multiple DANE statements
of the above forms to be combined. For example, a domain holder of the above forms to be combined. For example, a domain holder
should be able to specify that clients should accept a particular should be able to specify that clients should accept a particular
certificate (Section Section 3.2) as well as any certificate certificate (Section 3.2) as well as any certificate issued by its
issued by its own CA (Section Section 3.3). The precise types of own CA (Section 3.3). The precise types of combination allowed
combination allowed will be defined by the DANE protocol. will be defined by the DANE protocol.
Roll-over: The DANE mechanism must allow a site to transition from Roll-over: The DANE mechanism must allow a site to transition from
using one DANE mechanism to another. For example, a domain holder using one DANE mechanism to another. For example, a domain holder
should be able to migrate from using DANE to assert a domain should be able to migrate from using DANE to assert a domain-
issued certificate (Section Section 3.3) to using DANE to require issued certificate (Section 3.3) to using DANE to require an
an external CA (Section Section 3.1), or vice versa. The DANE external CA (Section 3.1), or vice versa. The DANE mechanism must
mechanism must also allow roll-over between records of the same- also allow roll-over between records of the same type, e.g., when
type, e.g., when changing CAs. changing CAs.
Simple Key Management: DANE should have a mode in which the domain Simple Key Management: DANE should have a mode in which the domain
holder only needs to maintain a single long-lived public/private holder only needs to maintain a single long-lived public/private
key pair. key pair.
Minimal Dependencies: It should be possible for a site to deploy Minimal Dependencies: It should be possible for a site to deploy
DANE without also deploying anything else, except DNSSEC. DANE without also deploying anything else, except DNSSEC.
Minimal Options: Ideally, DANE should have only one operating mode. Minimal Options: Ideally, DANE should have only one operating mode.
Practically, DANE should have as few operating modes as possible. Practically, DANE should have as few operating modes as possible.
Wild Cards: The mechanism for distributing DANE information should Wildcards: The mechanism for distributing DANE information should
allow the use of DNS wild card labels (*) for setting DANE allow the use of DNS wildcard labels (*) for setting DANE
information for all names within a wild card expansion. information for all names within a wildcard expansion.
Redirection: The mechanism for distributing DANE information should Redirection: The mechanism for distributing DANE information should
work when the application service name is the result of following work when the application service name is the result of following
a DNS redirection chain (e.g., via CNAME or DNAME). a DNS redirection chain (e.g., via CNAME or DNAME).
5. Acknowledgements 5. Acknowledgements
Thanks to Eric Rescorla for the initial formulation of the use cases, Thanks to Eric Rescorla for the initial formulation of the use cases,
Zack Weinberg and Phillip Hallam-Baker for contributing other Zack Weinberg and Phillip Hallam-Baker for contributing other
requirements, and the whole DANE working group for helpful comments requirements, and the whole DANE working group for helpful comments
on the mailing list. on the mailing list.
6. IANA Considerations 6. Security Considerations
This document makes no request of IANA.
7. Security Considerations
The primary focus of this document is the enhancement of TLS The primary focus of this document is the enhancement of TLS
authentication procedures using the DNS. The general effect of such authentication procedures using the DNS. The general effect of such
mechanisms is to increase the role of DNS operators in authentication mechanisms is to increase the role of DNS operators in authentication
processes, either in place of or in addition to traditional third- processes, either in place of or in addition to traditional third-
party actors such as commercial certificate authorities. The party actors such as commercial certificate authorities. The
specific security implications of the respective use cases are specific security implications of the respective use cases are
discussed in their respective sections above. discussed in their respective sections above.
8. References 7. References
8.1. Normative References 7.1. Normative References
[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.
[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.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011. Security (TLS)", RFC 6125, March 2011.
8.2. Informative References 7.2. Informative References
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP",
RFC 2595, June 1999. RFC 2595, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, February 2002. Transport Layer Security", RFC 3207, February 2002.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
skipping to change at page 12, line 41 skipping to change at page 12, line 38
Author's Address Author's Address
Richard Barnes Richard Barnes
BBN Technologies BBN Technologies
9861 Broken Land Parkway 9861 Broken Land Parkway
Columbia, MD 21046 Columbia, MD 21046
US US
Phone: +1 410 290 6169 Phone: +1 410 290 6169
Email: rbarnes@bbn.com EMail: rbarnes@bbn.com
 End of changes. 50 change blocks. 
131 lines changed or deleted 140 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/