draft-ietf-dane-use-cases-00.txt   draft-ietf-dane-use-cases-01.txt 
DANE R. Barnes DANE R. Barnes
Internet-Draft BBN Technologies Internet-Draft BBN Technologies
Intended status: Informational April 19, 2011 Intended status: Informational April 22, 2011
Expires: October 21, 2011 Expires: October 24, 2011
Use Cases and Requirements for DNS-based Authentication of Named Use Cases and Requirements for DNS-based Authentication of Named
Entities Entities (DANE)
draft-ietf-dane-use-cases-00.txt draft-ietf-dane-use-cases-01.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 TLS to allow clients to verify that a connected server
properly represents a desired domain name. Traditionally, this properly represents a desired domain name. Traditionally, this
authentication has been based on PKIX trust hierarchies, rooted in authentication has been based on PKIX trust hierarchies, rooted in
well-known CAs, but additional information can be provided via the well-known CAs, but additional information can be provided via the
DNS itself. This document describes a set of use cases in which the DNS itself. This document describes a set of use cases in which the
DNS and DNSSEC could be used to make assertions that support the TLS DNS and DNSSEC could be used to make assertions that support the TLS
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 October 21, 2011. This Internet-Draft will expire on October 24, 2011.
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. CA Constraints . . . . . . . . . . . . . . . . . . . . . . 4 3.1. CA Constraints . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Certificate Constraints . . . . . . . . . . . . . . . . . . 5 3.2. Certificate Constraints . . . . . . . . . . . . . . . . . . 5
3.3. Domain-Issued Certificates . . . . . . . . . . . . . . . . 5 3.3. Domain-Issued Certificates . . . . . . . . . . . . . . . . 5
4. Other Requirements . . . . . . . . . . . . . . . . . . . . . . 6 4. Other Requirements . . . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
Transport-Layer Security or TLS is used as the basis for security Transport-Layer Security or TLS is used as the basis for security
features in many modern Internet applications [RFC5246]. It is used features in many modern Internet applications [RFC5246]. It
as the basis for secure HTTP and secure email underlies secure HTTP and secure email [RFC2818][RFC2595][RFC3207],
[RFC2818][RFC2595][RFC3207], and provides hop-by-hop security in and provides hop-by-hop security in real-time multimedia and instant-
real-time multimedia and instant-messaging protocols messaging protocols [RFC3261][RFC6120].
[RFC3261][RFC6120].
One feature that is common to most uses of TLS is the use of One feature that is common to most uses of TLS is the use of
certificates to authenticate domain names for services. The TLS certificates to authenticate domain names for services. The TLS
client begins the TLS connection process with the goal of connecting client begins the TLS connection process with the goal of connecting
to a server with a specific domain name. After locating the server to a server with a specific domain name. After locating the server
via an A or AAAA record, the client conducts a TLS handshake with the via an A or AAAA record, the client conducts a TLS handshake with the
server, during which the server presents a PKIX certificate for server, during which the server presents a PKIX certificate for
itself [RFC5280]. Based on this certificate, the client decides itself [RFC5280]. Based on this certificate, the client decides
whether the server properly represents the desired domain name, and whether the server properly represents the desired domain name, and
thus whether to proceed with the TLS connection or not. thus whether to proceed with the TLS connection or not.
skipping to change at page 3, line 34 skipping to change at page 3, line 33
In most current applications, this decision process is based on PKIX In most current applications, this decision process is based on PKIX
validation and name matching. The client validates that the validation and name matching. The client validates that the
certificate chains to a trust anchor [RFC5280], and that the desired certificate chains to a trust anchor [RFC5280], and that the desired
domain name is contained in the certificate [RFC6125]. Within this domain name is contained in the certificate [RFC6125]. Within this
framework, bindings between public keys and domain names are asserted framework, bindings between public keys and domain names are asserted
by PKIX CAs. Authentication decisions based on these bindings rely by PKIX CAs. Authentication decisions based on these bindings rely
on the authority of these CAs. on the authority of these CAs.
The DNS is built to provide information about domain names, and with The DNS is built to provide information about domain names, and with
the advent of DNSSEC [RFC1034][RFC4033], it is possible for this the advent of DNSSEC [RFC1034][RFC4033], it is possible for this
information to be provided securely (in the sense that clients can information to be provided securely, in the sense that clients can
verify that DNS information was provided by the domain owner). One verify that DNS information was provided by the domain owner. The
of the goals of the current DANE working group is to develop goal of technologies for DNS-based Authentication of Named Entities
technologies for using the DNS to provide additional information to (DANE) is to use the DNS and DNSSEC to provide additional information
inform the TLS domain authentication process. This document to inform the TLS domain authentication process. This document
describes a set of use cases that capture specific goals for using describes a set of use cases that capture specific goals for using
the DNS in this way, and a set of requirements that the ultimate DANE the DNS in this way, and a set of requirements that the ultimate DANE
mechanism should satisfy. mechanism should satisfy.
2. Definitions 2. Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
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 RFC
5246 [RFC5246], respectively, for these terms. 5246 [RFC5246], respectively, for these terms.
3. Use Cases 3. Use Cases
In this section, we describe the two 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
goal for DANE. goal for DANE.
In the below use cases, we will refer to the following dramatis In the below use cases, we will refer to the following dramatis
personae: personae:
Alice The operator of a TLS-based service on the host Alice The operator of a TLS-protected service on the host
alice.example.com, and administrator of the corresponding DNS alice.example.com, and administrator of the corresponding DNS
zone. 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
These use cases are framed in terms of adding protections to TLS
server certificates, since the use of these certificates to
authenticate server domain names is very common. In applications
where TLS clients are also identified by domain names (e.g., XMPP
server-to-server connections), the same considerations and use cases
can also be applied to 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 about certificate from the well-known CA Charlie. She is concerned that
mis-issued certificates and would like to provide a mechanism for other well-known CAs might issue certificates for alice.example.com
visitors to her site to know that they should expect without her authorization, which clients would accept. Alice would
alice.example.com to use a certificate issued by the CA that she uses like to provide a mechanism for visitors to her site to know that
(Charlie) and not another CA. they should expect alice.example.com to use a certificate issued
under the CA that she uses (Charlie) and not another CA.
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 that the certificate presented by the server was issued
by the proper CA, Charlie. Bob also performs the normal PKIX under the proper CA, Charlie. Bob also performs the normal PKIX
validation procedure for this certificate, in particular verifying validation procedure for this certificate, in particular verifying
that the certificate chains to a trust anchor. that the certificate chains to a trust anchor.
Because these constraints do not increase the scope of PKIX-based Because these constraints do not increase the scope of PKIX-based
assertions about domains, there is not a strict requirement for assertions about domains, there is not a strict requirement for
DNSSEC. Deletion of records removes the protection provided by this DNSSEC. Deletion of records removes the protection provided by this
constraint, but the client is still protected by CA practices (as constraint, but the client is still protected by CA practices (as
now). Injected or modified false records are not useful unless the now). Injected or modified false records are not useful unless the
attacker can also obtain an unauthorized certificate. In the worst attacker can also obtain a certificate for the target domain. In the
case, tampering with these constraints degrades security to the level worst case, tampering with these constraints increases the risk of
that is now standard. false authentication to the level that is now standard.
Injected or modified false records can be used for denial of service,
even if the attacker does not have a certificate for the target
domain. If an attacker can modify DNS responses that a target host
receives, however, there are already 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 could still case a denial of
service by blocking all DNS responses 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 can interfere with TLS authentication through this DNS operators (as distinct from the owners of domains) can interfere
mechanism. As above, even if a DNS operator falsifies DANE records, with TLS authentication through this mechanism. As above, even if a
it cannot masquerade as the target server unless it can also obtain DNS operator falsifies DANE records, it cannot masquerade as the
an unauthorized certificate. target server unless it can also obtain a certificate for the target
domain.
3.2. Certificate Constraints 3.2. Certificate 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 about certificate from the well-known CA Charlie. She is concerned about
certificates being issued by Charlie as well as other CAs. She would additional, unauthorized certificates being issued by Charlie as well
like to provide a way for visitors to her site to know that they as by other CAs. She would like to provide a way for visitors to her
should expect alice.example.com to present the specific certificate site to know that they should expect alice.example.com to present the
issued by Charlie. specific certificate issued by Charlie.
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 that the certificate presented by the server is the
correct certificate. Bob also performs the normal PKIX validation correct certificate. Bob also performs the normal PKIX validation
procedure for this certificate, in particular verifying that the procedure for this certificate, in particular verifying that the
certificate chains to a trust anchor. certificate chains to a trust anchor.
The security considerations for this case are the same as for the "CA The security considerations for this case are the same as for the "CA
Constraints" case above. Constraints" case above.
3.3. Domain-Issued Certificates 3.3. Domain-Issued Certificates
Alice would like to be able to use generate and use certificates for Alice would like to be able to use generate and use certificates for
her website on alice.example.com without involving an external CA at her website on alice.example.com without involving an external CA at
all. Alice can generate her own certificates today, making self- all. Alice can generate her own certificates today, making self-
signed certificates and possibly certificates subordinate to those signed certificates and possibly certificates subordinate to those
certificates. When Bob receives such a certificate, however, he certificates. When Bob receives such a certificate, however, he
doesn't have a way to verify that the issuer of the certificate is doesn't have a way to verify that the issuer of the certificate is
actually Alice. This concerns him as an attacker could present a actually Alice. This concerns him because an attacker could present
different certificate and perform a man in the middle attack. Bob a different certificate and perform a man in the middle attack. Bob
would like to protect against this. would like to protect against this.
Alice would thus like to have a mechanism for visitors to her site to Alice would thus like to have a mechanism for visitors to her site to
know that the certificates she issues are actually hers. When Bob know that the certificates she issues are actually hers. When Bob
connects to alice.example.com, he uses this mechanism to verify that connects to alice.example.com, he uses this mechanism to verify that
the certificate presented by the server was issued by Alice. Since the certificate presented by the server was 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.
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. Deleted records cause clients to trust an attacker's certificate. Deleted records
will only result in connection failure and denial of service, will only result in connection failure and denial of service,
although this could result on a bid-down to an unsecured protocol, although this could result in clients re-connecting without TLS (a
depending on the application. downgrade attack), depending on the application. Therefore, in order
for this use case to be safe, applications must forbid clients from
falling back to unsecured channels when records appear to have been
deleted (e.g., when a missing record has no NSEC or 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 de
facto control over the content and signing of the zone, he can create facto control over the content and signing of the zone, he can create
false DANE records that bind a malicious party's certificate to a false DANE records that bind a malicious party's certificate to a
domain. This is not a significant incremental risk relative to the domain. This risk is especially important to keep in mind in cases
current PKIX-based system, however, since it is possible for domain where the operator of a DNS zone is a different entity than the owner
operators to obtain certificates for domains under some well-known of the domain, as in DNS hosting/outsourcing arrangements, since in
certificate authorities today. these cases the DNS operator might be able to make changes to a
domain that are not authorized by the owner of the domain.
This is not a significant incremental risk, however, relative to the
current PKIX-based system. In the current system, CAs need to verify
that an entity requesting a certificate for a domain is actually the
legitimate holder of that domain. Typically this is done using
information published about that domain, such as WHOIS email
addresses or special records inserted into a domain. By manipulating
these values, it is possible for DNS operators to obtain certificates
from some well-known certificate authorities today without
authorization from the true domain owner.
4. Other Requirements 4. Other Requirements
In addition to supporting the above use cases, the DANE mechanism In addition to supporting the above use cases, the DANE mechanism
must satisfy several lower-level operational and protocol must satisfy several lower-level operational and protocol
requirements and goals. requirements and goals.
Multiple Ports: DANE should be able to support multiple services Multiple Ports: DANE should be able to support multiple services
with different credentials on the same named host, distinguished with different credentials on the same named host, distinguished
by port number. by port number.
Simple Key Management: DANE must have a mode in which the domain No Downgrade: An attacker who can tamper with DNS responses must not
owner only needs to maintain a single long-lived public/private be able to make a DANE-compliant client treat a site that has
key pair. deployed DANE and DNSSEC like a site that has deployed neither.
Hard Failure: Clients must be required to refuse to proceed with a
connection to a site if DANE indicates a security error.
Encapsulation: If there is a DANE record for the name Encapsulation: If there is a DANE information for the name
alice.example.com, it must only affect services hosted at alice.example.com, it must only affect services hosted at
alice.example.com. alice.example.com.
Predictability: Client behavior in response to DANE records must be Predictability: Client behavior in response to DANE information must
spelled out in the DANE specification as precisely as possible. be spelled out in the DANE specification as precisely as possible,
especially for cases where DANE information might conflict with
PKIX information.
Simple Key Management: DANE should have a mode in which the domain
owner only needs to maintain a single long-lived public/private
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 and CNAME: The mechanism for DANE record distribution Wild Cards and CNAME: The mechanism for distributing DANE
should be compatible with the use of DNS wild cards and CNAME information should be compatible with the use of DNS wild cards
records for setting default properties for domains and redirecting and CNAME records for setting default properties for domains and
services. redirecting services.
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. IANA Considerations
skipping to change at page 7, line 33 skipping to change at page 8, line 22
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 8. References
8.1. Normative References 8.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
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.
[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
 End of changes. 25 change blocks. 
67 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/