Use Cases and Requirements for DNS-based Authentication of Named Entities
draft-ietf-dane-use-cases-00.txt

Abstract

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.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on October 22, 2011.

Copyright Notice

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Definitions
• 3. Use Cases
• 3.1. CA Constraints
• 3.2. Certificate Constraints
• 3.3. Domain-Issued Certificates
• 4. Other Requirements
• 5. Acknowledgements
• 6. IANA Considerations
• 7. Security Considerations
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Author's Address

1. Introduction

Transport-Layer Security or TLS is used as the basis for security features in many modern Internet applications [RFC5246]. It is used as the basis for secure HTTP and secure email [RFC2818][RFC2595][RFC3207], and provides hop-by-hop security in real-time multimedia and instant-messaging protocols [RFC3261][RFC6120].

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 [RFC5280]. 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.

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 [RFC5280], and that the desired domain name is contained in the certificate [RFC6125]. 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.

The DNS is built to provide information about domain names, and with the advent of DNSSEC [RFC1034][RFC4033], 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). One of the goals of the current DANE working group is to develop technologies for using the DNS 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.

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 terminology. See RFC 5280 [RFC5280], RFC 4033 [RFC4033], and RFC 5246 [RFC5246], respectively, for these terms.

3. Use Cases

In this section, we describe the two 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.

In the below use cases, we will refer to the following dramatis personae:

Alice

The operator of a TLS-based service on the host alice.example.com, and administrator of the corresponding DNS zone.

Bob

A client connecting to alice.example.com

Charlie

A well-known CA that issues certificates with domain names as identifiers

3.1. CA Constraints

Alice runs a website on alice.example.com and has obtained a certificate from the well-known CA Charlie. She is concerned about mis-issued certificates and 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 by the CA that she uses (Charlie) and not another CA.

When Bob connects to alice.example.com, he uses this mechanism to verify that that the certificate presented by the server was issued by 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.

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 an unauthorized certificate. In the worst case, tampering with these constraints degrades security to the level that is now standard.

Continuing to require PKIX validation also limits the degree to which DNS operators 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 an unauthorized certificate.

3.2. Certificate Constraints

Alice runs a website on alice.example.com and has obtained a certificate from the well-known CA Charlie. She is concerned about certificates being issued by Charlie as well as 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.

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.

The security considerations for this case are the same as for the "CA Constraints" case above.

3.3. Domain-Issued Certificates

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 as 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 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.

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 on a bid-down to an unsecured protocol, depending on the application.

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 is not a significant incremental risk relative to the current PKIX-based system, however, since it is possible for domain operators to obtain certificates for domains under some well-known certificate authorities today.

4. Other Requirements

In addition to supporting the above use cases, the DANE mechanism must satisfy several lower-level operational and protocol requirements and goals.

Multiple Ports:

DANE should be able to support multiple services with different credentials on the same named host, distinguished by port number.

Simple Key Management:

DANE must have a mode in which the domain owner only needs to maintain a single long-lived public/private key pair.

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 alice.example.com, it must only affect services hosted at alice.example.com.

Predictability:

Client behavior in response to DANE records must be spelled out in the DANE specification as precisely as possible.

Minimal Dependencies:

It should be possible for a site to deploy DANE without also deploying anything else, except DNSSEC.

Minimal Options:

Ideally, DANE should have only one operating mode. Practically, DANE should have as few operating modes as possible.

Wild Cards and CNAME:

The mechanism for DANE record distribution should be compatible with the use of DNS wild cards and CNAME records for setting default properties for domains and redirecting services.

5. Acknowledgements

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.

6. IANA Considerations

This document makes no request of IANA.

7. Security Considerations

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.

8. References

8.1. Normative References

8.2. Informative References

Author's Address