One document matched: draft-ietf-dane-use-cases-05.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-ietf-dane-use-cases-05.txt"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="DANE Use Cases">Use Cases and Requirements for DNS-based
Authentication of Named Entities (DANE)</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author fullname="Richard Barnes" initials="R.L." surname="Barnes">
<organization>BBN Technologies</organization>
<address>
<postal>
<street>9861 Broken Land Parkway</street>
<city>Columbia</city>
<region>MD</region>
<code>21046</code>
<country>US</country>
</postal>
<phone>+1 410 290 6169</phone>
<email>rbarnes@bbn.com</email>
</address>
</author>
<date day="28" month="July" year="2011" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<area>SEC</area>
<workgroup>DANE</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>dns, tls, pkix, dane</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>Many current applications use the certificate-based authentication
features in TLS to allow clients to verify that a connected server
properly represents a desired domain name. Typically, this
authentication has been based on PKIX certificate chains rooted in
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 and
DNSSEC could be used to make assertions that support the TLS
authentication process. The main focus of this document is TLS server
authentication, but it also covers TLS client authentication for
applications where TLS clients are identified by domain names.</t>
</abstract>
</front>
<middle>
<section anchor="intro-sec" title="Introduction">
<t>Transport-Layer Security (TLS) is used as the basis for security
features in many modern Internet application service protocols to
provide secure client-server connections <xref target="RFC5246"></xref>.
It underlies secure HTTP and secure email <xref
target="RFC2818"></xref><xref target="RFC2595"></xref><xref
target="RFC3207"></xref>, and provides hop-by-hop security in real-time
multimedia and instant-messaging protocols <xref
target="RFC3261"></xref><xref target="RFC6120"></xref>.</t>
<t>Application service clients typically establish TLS connections to
application servers identified by DNS domain names. The process of
obtaining this "source" domain is application specific <xref
target="RFC6125"></xref>. The name could be entered by a user or found
through an automated 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 conducts a TLS handshake with the server, during which the
server presents a PKIX certificate <xref target="RFC5280"></xref>. The
TLS layer performs PKIX validation of the certificate, including
verification that the certificate chains to one of the client's trust
anchors. If this validation is successful, then the application layer
determines whether the DNS name for the application service presented in
the certificate matches the source domain name <xref
target="RFC6125"></xref>. Typically, if the name matches, then the
client proceeds with the TLS connection.</t>
<t>The certificate authorities (CAs) that issue PKIX certificates are
asserting bindings between domain names and the public keys they
certify. Application service clients are verifying these bindings and
making authorization decisions -- whether to proceed with connections --
based on them.</t>
<t>Clients thus rely on CAs to correctly assert bindings between public
keys and domain names, in the sense that the holder of the corresponding
private key should be the domain holder. Today, an attacker can
successfully authenticate as a given application service domain if he
can obtain a "mis-issued" ciertificate from one of the widely-used CAs
-- a certificate containing the victim application service's domain name
and a public key whose corresponding private 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., through DNS cache
poisoning of an A or AAAA record), then the attacker can convince the
client that a server of the attacker's choice legitimately represents
the victim's application service.</t>
<t>With the advent of DNSSEC <xref target="RFC4033"></xref>, it is now
possible for DNS name resolution to provide its information securely, in
the sense that clients can verify that DNS information was provided by
the domain holder and not tampered with in transit. The goal of
technologies for DNS-based Authentication of Named Entities (DANE) is to
use the DNS and DNSSEC to provide additional information about the
cryptographic credentials associated with a domain, so that clients can
use this information to increase the level of assurance they receive
from the TLS handshake process. This document 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 mechanism should satisfy.</t>
<t>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.</t>
</section>
<section anchor="def-sec" title="Definitions">
<!--
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
-->
<t>This document also makes use of standard PKIX, DNSSEC, and TLS
terminology. See RFC 5280 <xref target="RFC5280"></xref>, RFC 4033 <xref
target="RFC4033"></xref>, and RFC 5246 <xref target="RFC5246"></xref>,
respectively, for these terms. In addition, terms related to
TLS-protected application services and DNS names are taken from RFC 6125
<xref target="RFC6125"></xref>.</t>
<t>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 this
type may be co-located on a single physical host, using different ports,
and each of these can use different certificates.</t>
</section>
<section anchor="lock-sec" title="Use Cases">
<t>In this section, we describe the major use cases that the DANE
mechanism should support. This list is not intended to represent all
possible ways that the DNS can be used to support TLS authentication.
Rather it represents the specific cases that comprise the initial goals
for DANE.</t>
<t>In the below use cases, we will refer to the following dramatis
personae:<list style="hanging">
<t hangText="Alice:">The operator of a TLS-protected application
service on the host alice.example.com, and administrator of the
corresponding DNS zone.</t>
<t hangText="Bob:">A client connecting to alice.example.com</t>
<t hangText="Charlie:">A well-known CA that issues certificates with
domain names as identifiers</t>
<t hangText="Oscar:">An outsourcing provider that operates
TLS-protected application services on behalf of customers</t>
<t hangText="Trent:">A CA that issues certificates with domain names
as identifiers, but is not generally well-known.</t>
</list></t>
<t>These use cases are framed in terms of adding verification steps to
TLS server identity checking on the part of application service clients.
In application services where the clients are also identified by domain
names (e.g., XMPP server-to-server connections), the same considerations
and use cases are applicable to the application server's checking of
identities in TLS client certificates.</t>
<section anchor="ca-cons" title="CA Constraints">
<t>Alice runs a website on alice.example.com and has obtained a
certificate from the well-known CA Charlie. She is concerned that
other well-known CAs might issue certificates for alice.example.com
without her authorization, which clients would accept. Alice would
like to provide a mechanism for visitors to her site to know that they
should expect alice.example.com to use a certificate issued 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 certificate
chain from the server certificate to Charlie before 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 <xref
target="RFC5246"></xref>).</t>
<t>When Bob connects to alice.example.com, he uses this mechanism to
verify that that the certificate presented by the server was issued
under the proper CA, Charlie. Bob also performs the normal PKIX
validation procedure for this certificate, in particular verifying
that the certificate chains to a trust anchor (possibly Charlie's CA,
if Bob accepts Charlie's CA as a trust anchor).</t>
<t>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 be 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 relying parties. 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 guarantee 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.</t>
<t>In principle, DANE information expressing CA constraints can be
presented with or without DNSSEC protection. Presenting DANE
information without DNSSEC protection does not introduce any new
vulnerabilities, but neither does it add much assurance. Deletion of
records removes the protection provided by this constraint, but the
client is still protected by CA practices (as now). Injected or
modified false records are not useful unless the attacker can also
obtain a certificate for the target domain. Thus, In the worst case,
tampering with these constraints increases the risk of false
authentication to the level that is now standard.</t>
<t>Using DANE information for CA constraints without DNSSEC 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 provide
fake DANE information (without DNSSEC) by simply spoofing the
additional records required to carry the DANE information.</t>
<t>Injected or modified false DANE information of this type 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.</t>
<t>Continuing to require PKIX validation also limits the degree to
which DNS operators (as distinct from the holders of domains) can
interfere with TLS authentication through this mechanism. As above,
even if a DNS operator falsifies DANE records, it cannot masquerade as
the target server unless it can also obtain a certificate for the
target domain.</t>
</section>
<section anchor="cert-cons" title="Service Certificate Constraints">
<t>Alice runs a website on alice.example.com and has obtained a
certificate from the well-known CA Charlie. She is concerned about
additional, unauthorized certificates being issued by Charlie as well
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
specific certificate. In TLS terms, Alice is letting Bob know that
this specific certificate must be the first certificate in the server
Certificate message's certificate_list structure <xref
target="RFC5246"></xref>.</t>
<t>When Bob connects to alice.example.com, he uses this mechanism to
verify that that the certificate presented by the server is the
correct certificate. Bob also performs the normal PKIX validation
procedure for this certificate, in particular verifying that the
certificate chains to a trust anchor.</t>
<t>The security implications for this case are the same as for the "CA
Constraints" case above.</t>
</section>
<section anchor="dom-iss"
title="Trust Anchor Assertion and Domain-Issued Certificates">
<t>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. Alice can generate her own certificates today, making self-signed
certificates and possibly certificates subordinate to those
certificates. When Bob receives such a certificate in a TLS handshake,
however, he doesn't automatically have a way to verify that the issuer
of the certificate is actually Alice, because he doesn't necessarily
possess Alice's corresponding trust anchor. 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.</t>
<t>Alice would thus like to publish information so that visitors to
her site can know that the certificates presented by her application
services are legitimately hers. When Bob connects to
alice.example.com, he uses this information to verify that the
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
as a trust anchor for purposes of validating certificates for
alice.example.com. Alice can additionally recommend that clients
accept only her certificates using the CA constraints described
above.</t>
<t>As in Section <xref target="ca-cons"></xref> above, Alice may wish
to represent this information to potential third-party CAs (Charlie)
as well as to relying parties (Bob). Since publishing a certificate in
a DANE record of this form authorizes the holder of the corresponding
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.</t>
<t>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.</t>
<t>Alice's advertising of trust anchor material in this way does not
guarantee that Bob will accept the advertised trust anchor. For
example, Bob might have out-of-band information (such as a
pre-existing local policy) that indicates that the CA advertised by
Alice (Trent's CA) is not trustworthy, which would lead him to decide
not to accept Trent as a TA, and thus to reject Alice's certificate if
it is issued under Trent's CA.</t>
<t>Providing trust anchor material in this way clearly requires
DNSSEC, since corrupted or injected records could be used by an
attacker to cause clients to trust an attacker's certificate (assuming
that the attacker's certificate is not rejected by some other local
policy). Deleted records will only result in connection failure and
denial of service, although this could result in clients re-connecting
without TLS (a 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).</t>
<t>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 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 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 holder
of the domain, as in DNS hosting/outsourcing arrangements, 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.</t>
<t>It should be noted that DNS operators already have the ability to
obtain certificates for domains under their control, under certain CA
policies. 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 holder.</t>
</section>
<section title="Delegated Services">
<t>In addition to guarding against CA mis-issue, CA constraints and
certificate constraints can also be used to constrain the set of
certificates that can be used by an outsourcing provider. Suppose that
Oscar operates alice.example.com on behalf of Alice. In particular,
Oscar then has de facto control over what certificates to present in
TLS handshakes for alice.example.com. In such cases, there are few
ways that DNS-based information about TLS certificates could be
configured, for example:<list style="numbers">
<t>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
coordination if the addresses and/or the certificates change.</t>
<t>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
pieces under Oscar's control.</t>
<t>Alice can put DANE records into her DNS server, but delegate
the address records to Oscar's DNS server. This means that Alice
can control the usage of certificates but Oscar is free to move
the servers around as needed. The only coordination needed is when
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
pointer).</t>
</list></t>
<t>Which of these deployment patterns is used in a given deployment
will 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 and certificate constraints to control what certificates Oscar
presents for Alice's application services. For instance, Alice might
require Oscar to use certificates under a given set of CAs. This
control, however, requires that Alice update DANE records when Oscar
needs to change certificates. Cases where Oscar controls DANE records
allow Oscar to maintain more autonomy from Alice, but by the same
token, Alice cannot enforce any requirements on the certificates that
Oscar presents in TLS handshakes.</t>
</section>
</section>
<section title="Other Requirements">
<t>In addition to supporting the above use cases, the DANE mechanism
must satisfy several lower-level operational and protocol requirements
and goals.</t>
<t><list style="hanging">
<t hangText="Multiple Ports:">DANE should be able to support
multiple application services with different credentials on the same
named host, distinguished by port number.</t>
<t hangText="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 deployed DANE and DNSSEC like a site that has deployed
neither.</t>
<t hangText="Encapsulation:">If there is DANE information for the
name alice.example.com, it must only affect application services
hosted at alice.example.com.</t>
<t hangText="Predictability:">Client behavior in response to DANE
information must be defined in the DANE specification as precisely
as possible, especially for cases where DANE information might
conflict with PKIX information.</t>
<t hangText="Opportunistic Security">The DANE mechanism must allow a
client 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 specified, regardless of
whether DANE information is present or not.</t>
<t hangText="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 that clients should accept a
particular certificate (Section <xref target="cert-cons"></xref>) as
well as any certificate issued by its own CA (Section <xref
target="dom-iss"></xref>). The precise types of combination allowed
will be defined by the DANE protocol.</t>
<t hangText="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 <xref target="dom-iss"></xref>)
to using DANE to require an external CA (Section <xref
target="ca-cons"></xref>), or vice versa. The DANE mechanism must
also allow roll-over between records of the same-type, e.g., when
changing CAs.</t>
<t hangText="Simple Key Management:">DANE should have a mode in
which the domain holder only needs to maintain a single long-lived
public/private key pair.</t>
<t hangText="Minimal Dependencies:">It should be possible for a site
to deploy DANE without also deploying anything else, except
DNSSEC.</t>
<t hangText="Minimal Options:">Ideally, DANE should have only one
operating mode. Practically, DANE should have as few operating modes
as possible.</t>
<t hangText="Wild Cards:">The mechanism for distributing DANE
information should allow the use of DNS wild card labels (*) for
setting DANE information for all names within a wild card
expansion.</t>
<t hangText="Redirection:">The mechanism for distributing DANE
information should work when the application service name is the
result of following a DNS redirection chain (e.g., via CNAME or
DNAME).</t>
</list></t>
</section>
<section anchor="ack-sec" title="Acknowledgements">
<t>Thanks to Eric Rescorla for the initial formulation of the use cases,
Zack Weinberg and Phillip Hallam-Baker for contributing other
requirements, and the whole DANE working group for helpful comments on
the mailing list.</t>
</section>
<section anchor="iana-sec" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
</section>
<section anchor="sec-cons-sec" title="Security Considerations">
<t>The primary focus of this document is the enhancement of TLS
authentication procedures using the DNS. The general effect of such
mechanisms is to increase the role of DNS operators in authentication
processes, either in place of or in addition to traditional third-party
actors such as commercial certificate authorities. The specific security
implications of the respective use cases are discussed in their
respective sections above.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6125.xml"?>
</references>
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2595.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3207.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6120.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:27:39 |