One document matched: draft-ietf-dane-use-cases-01.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-01.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 month="April" 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. Traditionally, this
authentication has been based on PKIX trust hierarchies, 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.</t>
</abstract>
</front>
<middle>
<section anchor="intro-sec" title="Introduction">
<t>Transport-Layer Security or TLS is used as the basis for security
features in many modern Internet applications <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>One feature that is common to most uses of TLS is the use of
certificates to authenticate domain names for services. The TLS client
begins the TLS connection process with the goal of connecting 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 server,
during which the server presents a PKIX certificate for itself <xref
target="RFC5280"></xref>. Based on this certificate, the client decides
whether the server properly represents the desired domain name, and thus
whether to proceed with the TLS connection or not.</t>
<t>In most current applications, this decision process is based on PKIX
validation and name matching. The client validates that the certificate
chains to a trust anchor <xref target="RFC5280"></xref>, and that the
desired domain name is contained in the certificate <xref
target="RFC6125"></xref>. Within this framework, bindings between public
keys and domain names are asserted by PKIX CAs. Authentication decisions
based on these bindings rely on the authority of these CAs.</t>
<t>The DNS is built to provide information about domain names, and with
the advent of DNSSEC <xref target="RFC1034"></xref><xref
target="RFC4033"></xref>, it is possible for this information to be
provided securely, in the sense that clients can verify that DNS
information was provided by the domain owner. The goal of technologies
for DNS-based Authentication of Named Entities (DANE) is to use the DNS
and DNSSEC to provide additional information to inform the TLS domain
authentication 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>
</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.</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 goal
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 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>
</list></t>
<t>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.</t>
<section 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.</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.</t>
<t>Because these constraints do not increase the scope of PKIX-based
assertions about domains, there is not a strict requirement for
DNSSEC. 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. In the
worst case, tampering with these constraints increases the risk of
false authentication to the level that is now standard.</t>
<t>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.</t>
<t>Continuing to require PKIX validation also limits the degree to
which DNS operators (as distinct from the owners 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 title="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 the
specific certificate issued by Charlie.</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 considerations for this case are the same as for the
"CA Constraints" case above.</t>
</section>
<section title="Domain-Issued Certificates">
<t>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 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, however, he
doesn't have a way to verify that the issuer of the certificate is
actually Alice. 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 have a mechanism for visitors to her site
to know that the certificates she issues are actually hers. When Bob
connects to alice.example.com, he uses this mechanism to verify that
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 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>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. 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 owner
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 owner of the domain.</t>
<t>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.</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 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 a DANE information for the
name alice.example.com, it must only affect services hosted at
alice.example.com.</t>
<t hangText="Predictability:">Client behavior in response to DANE
information must be spelled out in the DANE specification as
precisely as possible, especially for cases where DANE information
might conflict with PKIX information.</t>
<t hangText="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.</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 and CNAME:">The mechanism for distributing
DANE information should be compatible with the use of DNS wild cards
and CNAME records for setting default properties for domains and
redirecting services.</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.1034.xml"?>
<!-- <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?> -->
<?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"?>
</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"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6125.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:27:01 |