draft-ietf-dane-use-cases-02.txt   draft-ietf-dane-use-cases-03.txt 
DANE R. Barnes DANE R. Barnes
Internet-Draft BBN Technologies Internet-Draft BBN Technologies
Intended status: Informational April 29, 2011 Intended status: Informational June 12, 2011
Expires: October 31, 2011 Expires: December 14, 2011
Use Cases and Requirements for DNS-based Authentication of Named Use Cases and Requirements for DNS-based Authentication of Named
Entities (DANE) Entities (DANE)
draft-ietf-dane-use-cases-02.txt draft-ietf-dane-use-cases-03.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 31, 2011. This Internet-Draft will expire on December 14, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. CA Constraints . . . . . . . . . . . . . . . . . . . . . . 4 3.1. CA Constraints . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Certificate Constraints . . . . . . . . . . . . . . . . . 5 3.2. Certificate Constraints . . . . . . . . . . . . . . . . . 6
3.3. Domain-Issued Certificates . . . . . . . . . . . . . . . . 6 3.3. Domain-Issued Certificates . . . . . . . . . . . . . . . . 6
3.4. Delegated Services . . . . . . . . . . . . . . . . . . . . 7 3.4. Delegated Services . . . . . . . . . . . . . . . . . . . . 8
3.5. Opportunistic Security . . . . . . . . . . . . . . . . . . 8
3.6. Web Services . . . . . . . . . . . . . . . . . . . . . . . 8
4. Other Requirements . . . . . . . . . . . . . . . . . . . . . . 9 4. Other Requirements . . . . . . . . . . . . . . . . . . . . . . 9
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
Transport-Layer Security or TLS is used as the basis for security Transport-Layer Security (TLS) is used as the basis for security
features in many modern Internet applications [RFC5246]. It features in many modern Internet application service protocols to
underlies secure HTTP and secure email [RFC2818][RFC2595][RFC3207], provide secure client-server connections [RFC5246]. It underlies
and provides hop-by-hop security in real-time multimedia and instant- secure HTTP and secure email [RFC2818][RFC2595][RFC3207], and
provides hop-by-hop security in real-time multimedia and instant-
messaging protocols [RFC3261][RFC6120]. messaging protocols [RFC3261][RFC6120].
One feature that is common to most uses of TLS is the use of Application service clients typically establish TLS connections to
certificates to authenticate domain names for services. The TLS application servers identified by DNS domain names. The process of
client begins the TLS connection process with the goal of connecting obtaining this "source" domain is application specific. The name
to a server with a specific domain name. (The process of obtaining could be entered by a user or found through an automated discovery
this domain name is application-specific. It could be entered by a process such as an SRV or NAPTR record. After obtaining the address
user or found through an automated discovery process, e.g., via an of the server via an A or AAAA DNS record, the client conducts a TLS
SRV or NAPTR record.) After obtaining the address of the server via handshake with the server, during which the server presents a PKIX
an A or AAAA record, the client conducts a TLS handshake with the certificate [RFC5280]. The TLS layer performs PKIX validation of the
server, during which the server presents a PKIX certificate for certificate, including verification that the certificate chains to a
itself [RFC5280]. Based on this certificate, the client decides trust anchor. If this validation is successful, then the application
whether the server properly represents the desired domain name, and layer determines whether the DNS name for the application service
thus whether to proceed with the TLS connection or not. presented in the certificate matches the source domain name
[RFC6125]. Typically, if the name matches, then the client proceeds
with the TLS connection.
In most current applications, this decision process is based on PKIX Thus the certificate authorities (CAs) that issue PKIX certificates
validation and application-specific name matching. The client are asserting bindings between domain names and the public keys they
validates that the certificate chains to a trust anchor [RFC5280], certify. Application service clients are verifying these bindings
and that the desired domain name is contained in the certificate and making authorization decisions -- whether to proceed with
[RFC6125]. Within this framework, bindings between public keys and connections -- based on them.
domain names are asserted by PKIX CAs. Authentication decisions
based on these bindings rely on the authority of these CAs.
The DNS is built to provide information about domain names, and with With the advent of DNSSEC [RFC4033], it is now possible for DNS name
the advent of DNSSEC [RFC1034][RFC4033], it is possible for this resolution to provide its information securely, in the sense that
information to be provided securely, in the sense that clients can clients can verify that DNS information was provided by the domain
verify that DNS information was provided by the domain owner. The holder and not tampered with in transit. The goal of technologies
goal of technologies for DNS-based Authentication of Named Entities for DNS-based Authentication of Named Entities (DANE) is to use the
(DANE) is to use the DNS and DNSSEC to provide additional information DNS and DNSSEC to provide additional information about the
to inform the TLS domain authentication process. This document cryptographic credentials associated with a domain, so that clients
describes a set of use cases that capture specific goals for using can use this information to increase the level of assurance they
the DNS in this way, and a set of requirements that the ultimate DANE receive from the TLS handshake process. This document describes a
mechanism should satisfy. 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
should satisfy.
Finally, it should be noted that although this document will
frequently use HTTPS as an example application service, DANE is
intended to apply equally to all applications that make use of TLS to
connect to application services named 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 RFC
5246 [RFC5246], respectively, for these terms. 5246 [RFC5246], respectively, for these terms. In addition, terms
related to TLS-protected application services and DNS names are 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, using
different ports, and each of these can use different certificates. different ports, and each of these can use different certificates.
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
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-protected service on the host Alice: The operator of a TLS-protected application service on the
alice.example.com, and administrator of the corresponding DNS host 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
Oscar An outsourcing provider that operates TLS-protected services Oscar: An outsourcing provider that operates TLS-protected
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 protections to TLS These use cases are framed in terms of adding verification steps to
server certificates, since the use of these certificates to TLS server identity checking on the part of application service
authenticate server domain names is very common. In applications clients. In application services where the clients are also
where TLS clients are also identified by domain names (e.g., XMPP identified by domain names (e.g., XMPP server-to-server connections),
server-to-server connections), the same considerations and use cases the same considerations and use cases can applied to the application
can also be applied to TLS client 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. In TLS under the CA that she uses (Charlie) and not another CA. That is,
terms, Alice is letting Bob know that Charlie's certificate must Alice is recommending that the client verify that there is a valid
appear somewhere in the server Certificate message's certificate_list certificate chain from the server certificate to Charlie before
structure. accepting the server certificate. (For example, in the TLS
handshake, the server might include Charlie's certificate in the
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 that the certificate presented by the server was issued
under 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 (possibly Charlie's CA,
if Bob accepts Charlie's CA as a trust anchor).
Alice may wish to provide similar information to an external CA
operator Charlie. Prior to issuing a certificate for
alice.example.com to someone claiming to Alice, Charlie needs to
verify that Alice is actually requesting a certificate. Alice could
indicate her preferred CA using DANE to CAs as well as RPs. Charlie
could then check to see whether Alice said that her certificates
should be issued by Charlie or another CA. Note that this check does
not guaranteed that the precise entity requesting a certification
from Charlie actually represents Alice, only that Alice has
authorized Charlie to issue certificates for her domain to properly
authorized individuals.
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 a certificate for the target domain. In the attacker can also obtain a certificate for the target domain. In the
worst case, tampering with these constraints increases the risk of worst case, tampering with these constraints increases the risk of
false authentication to the level that is now standard. false authentication to the level that is now standard.
Nonetheless, using DANE in this way without also using DNSSEC
represents provides a very small incremental security feature. Many
common attacks against TLS connections already require the attacker
to inject false A or AAAA records in order to steer the victim client
to the attacker's server. An attacker that can already inject false
DNS records can also fake DANE information (without DNSSEC) by simply
spoofing the additional records required to carry the DANE
information.
Injected or modified false records can be used for denial of service, Injected or modified false records can be used for denial of service,
even if the attacker does not have a certificate for the target even if the attacker does not have a certificate for the target
domain. If an attacker can modify DNS responses that a target host domain. If an attacker can modify DNS responses that a target host
receives, however, there are already much simpler ways of denying receives, however, there are already much simpler ways of denying
service, such as providing a false A or AAAA record. In this case, 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 DNSSEC is not helpful, since an attacker could still case a denial of
service by blocking all DNS responses for the target domain. 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 (as distinct from the owners 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. 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
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 the site to know that they should expect alice.example.com to present the
specific certificate issued by Charlie. In TLS terms, Alice is specific certificate issued by Charlie. In TLS terms, Alice is
letting Bob know that this specific certificate must be the first letting Bob know that this specific certificate must be the first
certificate in the server Certificate message's certificate_list certificate in the server Certificate message's certificate_list
structure. 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 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.
As in Section 3.1., Alice's assertions about server certificates can The security considerations for this case are the same as for the "CA
be used to constrain the behavior of an outsourcing provider Oscar as Constraints" case above.
well as the CA Charlie and other CAs. Such a certificate constraint
requires Oscar to present the specified certificate to clients and
not another.
The other security considerations for this case are the same as for
the "CA 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 generate and use certificates for her
her website on alice.example.com without involving an external CA at website on alice.example.com without involving an external CA at all.
all. Alice can generate her own certificates today, making self- Alice can generate her own certificates today, making self-signed
signed certificates and possibly certificates subordinate to those certificates and possibly certificates subordinate to those
certificates. When Bob receives such a certificate, however, he certificates. When Bob receives such a certificate in a TLS
doesn't have a way to verify that the issuer of the certificate is handshake, however, he doesn't automatically have a way to verify
actually Alice. This concerns him because an attacker could present that the issuer of the certificate is actually Alice, since because
a different certificate and perform a man in the middle attack. Bob he doesn't necessarily possess Alice's corresponding trust anchor.
would like to protect against this. This concerns him because an attacker could present a different
certificate and perform a man in the middle attack. Bob 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 presented by her application services are
connects to alice.example.com, he uses this mechanism to verify that legitimately hers. When Bob connects to alice.example.com, he uses
the certificate presented by the server was issued by Alice. Since this mechanism to verify that the certificate presented by the server
Bob can bind certificates to Alice in this way, he can use Alice's CA has been issued by Alice. Since Bob can bind certificates to Alice
as a trust anchor for purposes of validating certificates for in this way, he can use Alice's CA as a trust anchor for purposes of
alice.example.com. Alice can additionally recommend that clients validating certificates for alice.example.com. Alice can
accept only her certificates using the CA constraints described additionally recommend that clients accept only her certificates
above. using the CA constraints described above.
This use case is functionally equivalent to the case where Alice As in Section Section 3.1 above, Alice may wish to represent this
doesn't issue her own certificates, but uses a CA Trent that is not information to potential third-party CAs (Charlie) as well as to
well-known. In this case, Alice would be advising Bob that he should relying parties (Bob). Since publishing a certificate in a DANE
treat Trent as a trust anchor for purposes of validating Alice's record of this form authorizes the holder of the corresponding
certificates, rather than a CA operated by Alice herself. private key to represent alice.example.com, a CA that has received a
request to issue a certificate from alice.example.com could use the
DANE information to verify the requestor's authorization to receive a
certificate for that domain. For example, a CA might choose to issue
a certificate for a given domain name and public key only when the
holder of the domain name has provisioned DANE information with a
certificate containing the public key.
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
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
Alice's certificates, rather than a CA operated by Alice herself.
Bob would thus need a way to securely obtain Trent's trust anchor
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 pre-
existing local policy) that indicates that the CA Trent advertised by existing local policy) that indicates that the CA advertised by Alice
Alice is not trustworthy, which would lead him to decide not to (Trent's CA) is not trustworthy, which would lead him to decide not
accept Trent as a TA, and thus to reject Alice's certificate if it is to accept Trent as a TA, and thus to reject Alice's certificate if it
issued under Trent. 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. Deleted records cause clients to trust an attacker's certificate (assuming that the
will only result in connection failure and denial of service, attacker's certificate is not rejected by some other local policy).
although this could result in clients re-connecting without TLS (a
downgrade attack), depending on the application. Therefore, in order Deleted records will only result in connection failure and denial of
for this use case to be safe, applications must forbid clients from service, although this could result in clients re-connecting without
falling back to unsecured channels when records appear to have been TLS (a downgrade attack), depending on the application. Therefore,
deleted (e.g., when a missing record has no NSEC or NSEC3 record). 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 risk is especially important to keep in mind in cases domain. This risk is especially important to keep in mind in cases
where the operator of a DNS zone is a different entity than the owner where the operator of a DNS zone is a different entity than the
of the domain, as in DNS hosting/outsourcing arrangements, since in holder of the domain, as in DNS hosting/outsourcing arrangements,
these cases the DNS operator might be able to make changes to a since in these cases the DNS operator might be able to make changes
domain that are not authorized by the owner of the domain. to a domain that are not authorized by the holder of the domain.
This is not a significant incremental risk, however, relative to the It should be noted that DNS operators already have the ability to
current PKIX-based system. In the current system, CAs need to verify obtain certificates for domains under their control, under certain CA
that an entity requesting a certificate for a domain is actually the policies. In the current system, CAs need to verify that an entity
legitimate holder of that domain. Typically this is done using requesting a certificate for a domain is actually the legitimate
information published about that domain, such as WHOIS email holder of that domain. Typically this is done using information
addresses or special records inserted into a domain. By manipulating published about that domain, such as WHOIS email addresses or special
these values, it is possible for DNS operators to obtain certificates records inserted into a domain. By manipulating these values, it is
from some well-known certificate authorities today without possible for DNS operators to obtain certificates from some well-
authorization from the true domain owner. known certificate authorities today without authorization from the
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 few ways that DNS-based information about TLS certificates
skipping to change at page 8, line 6 skipping to change at page 9, line 6
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 Diane'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 Diane 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 setup (i.e. a CA or an EE certificate pointer). record is set up (i.e. a CA or an EE certificate 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 made. In cases where Alice determine what sort of constraints can be made. In cases where Alice
controls DANE records (1 and 3), she can use CA and certificate controls DANE records (1 and 3), she can use CA and certificate
constraints to control what certificates Oscar presents for Alice's constraints to control what certificates Oscar presents for Alice's
services. For instance, Alice might require Oscar to use application services. For instance, Alice might require Oscar to use
certificates under a given set of CAs. This control, however, certificates under a given set of CAs. This control, however,
requires that Alice update DANE records when Oscar needs to change requires that Alice update DANE records when Oscar needs to change
certificates. Cases where Oscar controls DANE records allow Oscar to certificates. Cases where Oscar controls DANE records allow Oscar to
maintain more autonomy from Alice, but by the same token, Alice maintain more autonomy from Alice, but by the same token, Alice
cannot make any requirements on the certificates that Oscar uses. cannot enforce any requirements on the certificates that Oscar
presents in TLS handshakes.
3.5. Opportunistic Security
Alice would like to to publish a web site so that Bob will always
have the benefit of the best security his client is capable of,
without resulting in a negative user experience when using a legacy
browser. For example, suppose that Bob uses two browsers on
different machines, one is a legacy browser that does not support
DANE and cannot be updated, the other is a browser that has full
support for DANE. In this case, the legacy browser should continue
to work as before, while the new browser should be able to discover
DANE support. In general, the DANE mechanism must allow a clients to
determine whether DANE security is available for a site.
3.6. Web Services
A web service is an HTTP-based Internet protocol designed to support
direct machine-to-machine communication without the intervention of a
human operator or other form of supervisor. Since web services are
application protocols, the one aspect of Internet architecture that
is essential as far as a Web Service is concerned is that the DNS be
used as the naming system for service discovery. Web Services
typically evolve over time. A service provider must frequently
support legacy clients alongside new and in many cases multiple
versions of each protocol. Discovering the certificates or keys to
be used to secure the connection to the Web service represents merely
one aspect of the more general problem of Web Service property
discovery.
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 application
with different credentials on the same named host, distinguished services with different credentials on the same named host,
by port number. distinguished by port number.
No Downgrade: An attacker who can tamper with DNS responses must not No Downgrade: An attacker who can tamper with DNS responses must not
be able to make a DANE-compliant client treat a site that has be able to make a DANE-compliant client treat a site that has
deployed DANE and DNSSEC like a site that has deployed neither. deployed DANE and DNSSEC like a site that has deployed neither.
Encapsulation: If there is a DANE information for the name Encapsulation: If there is DANE information for the name
alice.example.com, it must only affect services hosted at alice.example.com, it must only affect application services hosted
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 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 especially for cases where DANE information might conflict with
PKIX information. PKIX information.
Opportunistic Security The DANE mechanism must allow a clients to
determine whether DANE information is available for a site, so
that a client can provide the highest level of security possible
for a given application service. Clients that do not support DANE
should continue to work as if DANE information were not present.
Combination: The DANE mechanism must allow multiple DANE statements
of the above forms to be combined. For example, a domain holder
should be able to specify its own CA (Section Section 3.3) and
require that no other be used (Section Section 3.1).
Roll-over: The DANE mechanism must allow a site to transition from
using one DANE mechanism to another. For example, a domain holder
should be able to migrate from using DANE to assert a domain
issued certificate (Section Section 3.3) to using DANE to require
an external CA (Section Section 3.1), or vice versa. The DANE
mechanism must also allow roll-over between records of the same-
type, e.g., when 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
owner 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 and CNAME: The mechanism for distributing DANE Wild Cards: The mechanism for distributing DANE information should
information should be compatible with the use of DNS wild cards allow the use of DNS wild card labels (*) for setting DANE
and CNAME records for setting default properties for domains and information for all names within a wild card expansion.
redirecting services.
Redirection: The mechanism for distributing DANE information should
work when the application service name is the result of following
a DNS redirection time (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. IANA Considerations
skipping to change at page 10, line 23 skipping to change at page 11, line 15
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 8. References
8.1. Normative References 8.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[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. 42 change blocks. 
170 lines changed or deleted 208 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/