< draft-ietf-dane-ops-06.txt   draft-ietf-dane-ops-07.txt >
DANE V. Dukhovni DANE V. Dukhovni
Internet-Draft Unaffiliated Internet-Draft Unaffiliated
Intended status: Standards Track W. Hardaker Intended status: Standards Track W. Hardaker
Expires: February 18, 2015 Parsons Expires: April 29, 2015 Parsons
August 17, 2014 October 26, 2014
Updates to and Operational Guidance for the DANE Protocol Updates to and Operational Guidance for the DANE Protocol
draft-ietf-dane-ops-06 draft-ietf-dane-ops-07
Abstract Abstract
This memo clarifies and updates the DANE TLSA protocol based on This memo clarifies and updates the DNS-Based Authentication of Named
implementation experience since the publication of the original DANE Entities (DANE) TLSA specification based on subsequent implementation
specification in [RFC6698]. It also contains guidance for DANE experience. It also contains guidance for implementers, operators
implementers and operators. and protocol developers who want to make use of DANE records.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 February 18, 2015. This Internet-Draft will expire on April 29, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 2, line 12 skipping to change at page 2, line 12
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. DANE TLSA Record Overview . . . . . . . . . . . . . . . . . . 4 2. DANE TLSA Record Overview . . . . . . . . . . . . . . . . . . 4
2.1. Example TLSA record . . . . . . . . . . . . . . . . . . . 6 2.1. Example TLSA record . . . . . . . . . . . . . . . . . . . 6
3. DANE TLS Requirements . . . . . . . . . . . . . . . . . . . . 6 3. DANE TLS Requirements . . . . . . . . . . . . . . . . . . . . 6
4. Certificate-Usage-Specific DANE Updates and Guidelines . . . 7 4. DANE Certificate-Usage Selection Guidelines . . . . . . . . . 7
4.1. Certificate Usage DANE-EE(3) . . . . . . . . . . . . . . 7 4.1. Opportunistic Security and PKIX usages . . . . . . . . . 7
4.2. Certificate Usage DANE-TA(2) . . . . . . . . . . . . . . 8 4.2. Interaction with Certificate Transparency . . . . . . . . 7
4.3. Certificate Usage PKIX-EE(1) . . . . . . . . . . . . . . 11 4.3. Transitioning between PKIX-TA/EE and DANE-TA/EE . . . . . 8
4.4. Certificate Usage PKIX-TA(0) . . . . . . . . . . . . . . 12 5. Certificate-Usage Specific DANE Updates and Guidelines . . . 8
4.5. Opportunistic Security and PKIX usages . . . . . . . . . 12 5.1. Certificate Usage DANE-EE(3) . . . . . . . . . . . . . . 8
5. Service Provider and TLSA Publisher Synchronization . . . . . 13 5.2. Certificate Usage DANE-TA(2) . . . . . . . . . . . . . . 10
6. TLSA Base Domain and CNAMEs . . . . . . . . . . . . . . . . . 15 5.3. Certificate Usage PKIX-EE(1) . . . . . . . . . . . . . . 13
7. TLSA Publisher Requirements . . . . . . . . . . . . . . . . . 16 5.4. Certificate Usage PKIX-TA(0) . . . . . . . . . . . . . . 13
7.1. Key rollover with fixed TLSA Parameters . . . . . . . . . 17 6. Service Provider and TLSA Publisher Synchronization . . . . . 14
7.2. Switching to DANE-TA from DANE-EE . . . . . . . . . . . . 18 7. TLSA Base Domain and CNAMEs . . . . . . . . . . . . . . . . . 16
7.3. Switching to New TLSA Parameters . . . . . . . . . . . . 18 8. TLSA Publisher Requirements . . . . . . . . . . . . . . . . . 17
7.4. TLSA Publisher Requirements Summary . . . . . . . . . . . 19 8.1. Key rollover with fixed TLSA Parameters . . . . . . . . . 18
8. Digest Algorithm Agility . . . . . . . . . . . . . . . . . . 19 8.2. Switching to DANE-TA from DANE-EE . . . . . . . . . . . . 19
9. General DANE Guidelines . . . . . . . . . . . . . . . . . . . 20 8.3. Switching to New TLSA Parameters . . . . . . . . . . . . 19
9.1. DANE DNS Record Size Guidelines . . . . . . . . . . . . . 21 8.4. TLSA Publisher Requirements Summary . . . . . . . . . . . 20
9.2. Certificate Name Check Conventions . . . . . . . . . . . 21 9. Digest Algorithm Agility . . . . . . . . . . . . . . . . . . 20
9.3. Design Considerations for Protocols Using DANE . . . . . 23 10. General DANE Guidelines . . . . . . . . . . . . . . . . . . . 21
10. Interaction with Certificate Transparency . . . . . . . . . . 23 10.1. DANE DNS Record Size Guidelines . . . . . . . . . . . . 22
10.2. Certificate Name Check Conventions . . . . . . . . . . . 22
10.3. Design Considerations for Protocols Using DANE . . . . . 24
11. Note on DNSSEC Security . . . . . . . . . . . . . . . . . . . 24 11. Note on DNSSEC Security . . . . . . . . . . . . . . . . . . . 24
12. Summary of Updates to RFC6698 . . . . . . . . . . . . . . . . 25 12. Summary of Updates to RFC6698 . . . . . . . . . . . . . . . . 25
13. Security Considerations . . . . . . . . . . . . . . . . . . . 26 13. Operational Considerations . . . . . . . . . . . . . . . . . 26
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 14. Security Considerations . . . . . . . . . . . . . . . . . . . 26
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
16.1. Normative References . . . . . . . . . . . . . . . . . . 27 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
16.2. Informative References . . . . . . . . . . . . . . . . . 28 17.1. Normative References . . . . . . . . . . . . . . . . . . 27
17.2. Informative References . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
[RFC6698] specifies a new DNS resource record "TLSA" that associates The DANE TLSA specification ([RFC6698]) introduces the DNS "TLSA"
a public certificate or public key of a trusted leaf or issuing resource record type. TLSA records associate a certificate or a
authority with the corresponding TLS transport endpoint. These DANE public key of an end-entity or a trusted issuing authority with the
TLSA records, when validated by DNSSEC, can be used to augment or corresponding TLS transport endpoint. DNSSEC validated DANE TLSA
replace the trust model of the existing public Certification records can be used to augment or replace the use of trusted public
Authority (CA) Public Key Infrastructure (PKI). Certification Authorities (CAs).
[RFC6698] defines three TLSA record fields with respectively 4, 2 and [RFC6698] defines three TLSA record fields with respectively 4, 2 and
3 currently specified values. These yield 24 distinct combinations 3 currently specified values. These yield 24 distinct combinations
of TLSA record types. This many options have lead to implementation of TLSA record types. This memo will recommend a smaller set of
and operational complexity. This memo will recommend best-practice best-practice combinations of these fields to simplify protocol
choices to help simplify implementation and deployment given these design, implementation and deployment.
plethora of choices.
Implementation complexity also arises from the fact that the TLS Implementation complexity also arises from the fact that the TLS
transport endpoint is often specified indirectly via Service Records transport endpoint is often specified indirectly via Service Records
(SRV), Mail Exchange (MX) records, CNAME records or other mechanisms (SRV), Mail Exchange (MX) records, CNAME records or other mechanisms
that map an abstract service domain to a concrete server domain. that map an abstract service domain to a concrete server domain.
With service indirection there are multiple potential places for With service indirection there are multiple potential places for
clients to find the relevant TLSA records. Service indirection is clients to find the relevant TLSA records. Service indirection is
often used to implement "virtual hosting", where a single Service often used to implement "virtual hosting", where a single Service
Provider transport endpoint simultaneously supports multiple hosted Provider transport endpoint simultaneously supports multiple hosted
domain names. With services that employ TLS, such hosting domain names. With services that employ TLS, such hosting
arrangements may require the Service Provider to deploy multiple arrangements may require the Service Provider to deploy multiple
pairs of private keys and certificates with TLS clients signaling the pairs of private keys and certificates. The TLS clients, then,
desired domain via the Server Name Indication (SNI) extension signal the desired domain to the TLSA server via the Server Name
([RFC6066], section 3). This memo provides operational guidelines Indication (SNI) extension ([RFC6066], section 3). This memo
intended to maximize interoperability between DANE TLS clients and provides operational guidelines intended to maximize interoperability
servers. between DANE TLS clients and servers.
In the context of this memo, channel security is assumed to be In the context of this memo, channel security is assumed to be
provided by TLS or DTLS. The Transport Layer Security (TLS) provided by TLS or DTLS. The Transport Layer Security (TLS)
[RFC5246] and Datagram Transport Layer Security (DTLS) [RFC6347] [RFC5246] and Datagram Transport Layer Security (DTLS) [RFC6347]
protocols provide secured TCP and UDP communication over IP. By protocols provide secured TCP and UDP communication, respectively,
convention, "TLS" will be used throughout this document and, unless over IP. By convention, "TLS" will be used throughout this document
otherwise specified, the text applies equally well to the DTLS and, unless otherwise specified, the text applies equally well to the
protocol. Used without authentication, TLS provides protection only DTLS over UDP protocol. Used without authentication, TLS provides
against eavesdropping through its use of encryption. With protection only against eavesdropping through its use of encryption.
authentication, TLS also provides integrity protection and With authentication, TLS also provides integrity protection and
authentication, which protect the transport against man-in-the-middle authentication, which protects the transport against man-in-the-
(MITM) attacks. middle (MITM) attacks.
Other related documents that build on [RFC6698] are Other related documents that build on [RFC6698] are
[I-D.ietf-dane-srv] and [I-D.ietf-dane-smtp-with-dane]. In [I-D.ietf-dane-srv] and [I-D.ietf-dane-smtp-with-dane].
Section 12 we summarize the updates this document makes to [RFC6698].
In Section 12 we summarize the normative updates this document makes
to [RFC6698].
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
The following terms are used throughout this document: The following terms are used throughout this document:
Service Provider: A company or organization that offers to host a Service Provider: A company or organization that offers to host a
service on behalf of a Customer Domain. The original domain name service on behalf of the owner of a Customer Domain. The original
associated with the service often remains under the control of the domain name associated with the service often remains under the
customer. Connecting applications may be directed to the Service control of the customer. Connecting applications may be directed
Provider via a redirection resource record. Example redirection to the Service Provider via a redirection resource record.
records include MX, SRV, and CNAME. The Service Provider Example redirection records include MX, SRV, and CNAME. The
frequently provides services for many customers and must carefully Service Provider frequently provides services for many customers
manage any TLS credentials offered to connecting applications to and must carefully manage any TLS credentials offered to
ensure name matching is handled easily by the applications. connecting applications to ensure name matching is handled easily
by the applications.
Customer Domain: As described above, a client may be interacting Customer Domain: As described above, a TLS client may be interacting
with a service that is hosted by a third party. We will refer to with a service that is hosted by a third party. We will refer to
the domain name used to locate the service prior to any the domain name used to locate the service (prior to any
redirection, as the "Customer Domain". redirection) as the "Customer Domain".
TLSA Publisher: The entity responsible for publishing a TLSA record TLSA Publisher: The entity responsible for publishing a TLSA record
within a DNS zone. This zone will be assumed DNSSEC-signed and within a DNS zone. This zone will be assumed DNSSEC-signed and
validatable to a trust anchor, unless otherwise specified. If the validatable to a trust anchor, unless otherwise specified. If the
Customer Domain is not outsourcing their DNS service, the TLSA Customer Domain is not outsourcing their DNS service, the TLSA
Publisher will be the customer themselves. Otherwise, the TLSA Publisher will be the customer themselves. Otherwise, the TLSA
Publisher is sometimes the operator of the outsourced DNS service. Publisher may be the operator of the outsourced DNS service.
public key: The term "public key" is short-hand for the public key: The term "public key" is short-hand for the
subjectPublicKeyInfo component of a PKIX [RFC5280] certificate. subjectPublicKeyInfo component of a PKIX [RFC5280] certificate.
SNI: The "Server Name Indication" (SNI) TLS protocol extension SNI: The "Server Name Indication" (SNI) TLS protocol extension
allows a TLS client to request a connection to a particular allows a TLS client to request a connection to a particular
service name of a TLS server ([RFC6066], section 3). Without this service name of a TLS server ([RFC6066], section 3). Without this
TLS extension, a TLS server has no choice but to offer a PKIX TLS extension, a TLS server has no choice but to offer a PKIX
certificate with a default list of server names, making it certificate with a default list of server names, making it
difficult to host multiple Customer Domains at the same IP- difficult to host multiple Customer Domains at the same IP-
skipping to change at page 5, line 4 skipping to change at page 4, line 50
TLSA parameters: In [RFC6698] the TLSA record is defined to consist TLSA parameters: In [RFC6698] the TLSA record is defined to consist
of four fields. The first three of these are numeric parameters of four fields. The first three of these are numeric parameters
that specify the meaning of the data in fourth and final field. that specify the meaning of the data in fourth and final field.
To avoid language contortions when we need to distinguish between To avoid language contortions when we need to distinguish between
the first three fields that together define a TLSA record "type" the first three fields that together define a TLSA record "type"
and the fourth that provides a data value of that type, we will and the fourth that provides a data value of that type, we will
call the first three fields "TLSA parameters", or sometimes just call the first three fields "TLSA parameters", or sometimes just
"parameters" when obvious from context. "parameters" when obvious from context.
2. DANE TLSA Record Overview 2. DANE TLSA Record Overview
DANE TLSA [RFC6698] specifies a protocol for publishing TLS server DANE TLSA [RFC6698] specifies a protocol for publishing TLS server
certificate associations via DNSSEC [RFC4033] [RFC4034] [RFC4035]. certificate associations via DNSSEC [RFC4033] [RFC4034] [RFC4035].
The DANE TLSA specification defines multiple TLSA RR types via The DANE TLSA specification defines multiple TLSA RR types via
combinations of numeric values of the first three fields of the TLSA combinations of numeric values of the first three fields of the TLSA
record (i.e. the "TLSA parameters"). The numeric values of these record (i.e. the "TLSA parameters"). The numeric values of these
parameters were later given symbolic names in [RFC7218]. These parameters were later given symbolic names in [RFC7218]. These
parameters are: parameters are:
The Certificate Usage field: Section 2.1.1 of [RFC6698] specifies 4 The Certificate Usage field: Section 2.1.1 of [RFC6698] specifies 4
values: PKIX-TA(0), PKIX-EE(1), DANE-TA(2), and DANE-EE(3). There values: PKIX-TA(0), PKIX-EE(1), DANE-TA(2), and DANE-EE(3). There
is an additional private-use value: PrivCert(255). All other is an additional private-use value: PrivCert(255), which, given
values are reserved for use by future specifications. its private scope, shall not be considered further in this
document. All other values are reserved for use by future
specifications.
The selector field: Section 2.1.2 of [RFC6698] specifies 2 values: The selector field: Section 2.1.2 of [RFC6698] specifies 2 values:
Cert(0), SPKI(1). There is an additional private-use value: Cert(0), SPKI(1). There is an additional private-use value:
PrivSel(255). All other values are reserved for use by future PrivSel(255). All other values are reserved for use by future
specifications. specifications.
The matching type field: Section 2.1.3 of [RFC6698] specifies 3 The matching type field: Section 2.1.3 of [RFC6698] specifies 3
values: Full(0), SHA2-256(1), SHA2-512(2). There is an additional values: Full(0), SHA2-256(1), SHA2-512(2). There is an additional
private-use value: PrivMatch(255). All other values are reserved private-use value: PrivMatch(255). All other values are reserved
for use by future specifications. for use by future specifications.
skipping to change at page 5, line 43 skipping to change at page 5, line 44
o When the low bit is set (PKIX-EE(1) and DANE-EE(3)) the TLSA o When the low bit is set (PKIX-EE(1) and DANE-EE(3)) the TLSA
record matches an EE certificate (also commonly referred to as a record matches an EE certificate (also commonly referred to as a
leaf or server certificate.) leaf or server certificate.)
o When the low bit is not set (PKIX-TA(0) and DANE-TA(2)) the TLSA o When the low bit is not set (PKIX-TA(0) and DANE-TA(2)) the TLSA
record matches a trust anchor (a Certification Authority) that record matches a trust anchor (a Certification Authority) that
issued one of the certificates in the server certificate chain. issued one of the certificates in the server certificate chain.
o When the high bit is set (DANE-TA(2) and DANE-EE(3)), the server o When the high bit is set (DANE-TA(2) and DANE-EE(3)), the server
certificate chain is domain-issued and may be verified without certificate chain is domain-issued and may be verified without
reference to any pre-existing public certification authority PKI. reference to any pre-configured Certification Authority trust
Trust is entirely placed on the content of the TLSA records anchor. Trust is based solely on the content of the TLSA records
obtained via DNSSEC. obtained via DNSSEC.
o When the high bit is not set (PKIX-TA(0) and PKIX-EE(1)), the TLSA o When the high bit is not set (PKIX-TA(0) and PKIX-EE(1)), the TLSA
record publishes a server policy stating that its certificate record publishes a server policy stating that its certificate
chain must pass PKIX validation [RFC5280] and the DANE TLSA record chain must pass PKIX validation [RFC5280] and the DANE TLSA record
is used to signal an additional requirement that the PKIX is used to signal an additional requirement that the PKIX
validated server certificate chain also contains the referenced CA validated server certificate chain also contains the referenced CA
or EE certificate. or EE certificate.
The selector field specifies whether the TLSA RR matches the whole The selector field specifies whether the TLSA RR matches the whole
skipping to change at page 6, line 27 skipping to change at page 6, line 27
The matching type field specifies how the TLSA RR Certificate The matching type field specifies how the TLSA RR Certificate
Association Data field is to be compared with the certificate or Association Data field is to be compared with the certificate or
public key. A value of Full(0) means an exact match: the full DER public key. A value of Full(0) means an exact match: the full DER
encoding of the certificate or public key is given in the TLSA RR. A encoding of the certificate or public key is given in the TLSA RR. A
value of SHA2-256(1) means that the association data matches the value of SHA2-256(1) means that the association data matches the
SHA2-256 digest of the certificate or public key, and likewise SHA2-256 digest of the certificate or public key, and likewise
SHA2-512(2) means a SHA2-512 digest is used. Of the two digest SHA2-512(2) means a SHA2-512 digest is used. Of the two digest
algorithms, for now only SHA2-256(1) is mandatory to implement. algorithms, for now only SHA2-256(1) is mandatory to implement.
Clients SHOULD implement SHA2-512(2), but servers SHOULD NOT Clients SHOULD implement SHA2-512(2), but servers SHOULD NOT
exclusively publish SHA2-512(2) digests. The digest algorithm exclusively publish SHA2-512(2) digests. The digest algorithm
agility protocol defined in Section 8 SHOULD be used by clients to agility protocol defined in Section 9 SHOULD be used by clients to
decide how to process TLSA RRsets that employ multiple digest decide how to process TLSA RRsets that employ multiple digest
algorithms. Server operators MUST publish TLSA RRsets that are algorithms. Server operators MUST publish TLSA RRsets that are
compatible with digest algorithm agility. compatible with digest algorithm agility.
2.1. Example TLSA record 2.1. Example TLSA record
In the example TLSA record below: In the example TLSA record below:
_25._tcp.mail.example.com. IN TLSA PKIX-TA Cert SHA2-256 ( _25._tcp.mail.example.com. IN TLSA PKIX-TA Cert SHA2-256 (
E8B54E0B4BAA815B06D3462D65FBC7C0 E8B54E0B4BAA815B06D3462D65FBC7C0
skipping to change at page 7, line 5 skipping to change at page 7, line 5
digest of the server certificate. digest of the server certificate.
3. DANE TLS Requirements 3. DANE TLS Requirements
[RFC6698] does not discuss what versions of TLS are required when [RFC6698] does not discuss what versions of TLS are required when
using DANE records. This document specifies that TLS clients that using DANE records. This document specifies that TLS clients that
support DANE/TLSA MUST support at least TLS 1.0 and SHOULD support support DANE/TLSA MUST support at least TLS 1.0 and SHOULD support
TLS 1.2. TLS clients and servers using DANE SHOULD support the TLS 1.2. TLS clients and servers using DANE SHOULD support the
"Server Name Indication" (SNI) extension of TLS. "Server Name Indication" (SNI) extension of TLS.
4. Certificate-Usage-Specific DANE Updates and Guidelines 4. DANE Certificate-Usage Selection Guidelines
As mentioned in Section 2, the TLSA certificate usage field takes one
of four possible values. With PKIX-TA(0) and PKIX-EE(1), the
validation of peer certificate chains requires additional pre-
configured CA trust anchors that are mutually trusted by the
operators of the TLS server and client. With DANE-TA(2) and DANE-
EE(3), no pre-configured CA trust anchors are required and the
published DANE TLSA records are sufficient to verify the peer's
certificate chain.
Protocol designers should carefully consider which set of DANE
certificate usages to support. Simultaneous support for all four
usages is NOT RECOMMENDED for DANE clients. Protocol designers
should either use the PKIX-TA(0) and PKIX-EE(1) certificate usages,
or use the DANE-TA(2) and DANE-EE(3) usages. If all four usages are
deployed together, an attacker capable of compromising the integrity
of DNSSEC needs only to replace server's TLSA RRset with one that
lists suitable DANE-EE(3) or DANE-TA(2) records, effectively
bypassing the PKIX required checks.. In other words, when all four
usages are supported, PKIX-TA(2) and PKIX-EE(1) offer only illusory
incremental security.
This document recommends that clients should generally support just
the DANE-TA(2) and DANE-EE(3) certificate usages. With DANE-TA(2)
and DANE-EE(3) clients don't need to track a large changing list of
X.509 trust-anchors. Supporting PKIX-TA(0) or PKIX-EE(1) decreases
the operational reliability of DANE-based authentication.
The DNSSEC TLSA records for servers MAY include both sets of usages
if the server needs to support a mixture of clients; some supporting
one pair of usages and some the other.
4.1. Opportunistic Security and PKIX usages
When the client's protocol design is based on Opportunistic Security
(OS, [I-D.dukhovni-opportunistic-security]), and the use of
authentication is based on the presence of server TLSA records, it is
especially important to avoid the PKIX-EE(1) and PKIX-TA(0)
certificate usages. Since the presence and data integrity of TLSA
records relies on DNSSEC, PKIX-TA(0) and PKIX-EE(1) TLSA records do
not provide additional security. With the PKIX-TA(0) and PKIX-EE(1)
usages offering no more security, but being more prone to failure,
they are a poor fit for opportunistic security and SHOULD NOT be used
in that context.
4.2. Interaction with Certificate Transparency
Certificate Transparency (CT) [RFC6962] defines an experimental
approach to mitigate the risk of rogue or compromised public CAs
issuing unauthorized certificates. This section clarifies the
interaction of CT and DANE.
When a server is authenticated via a DANE TLSA RR with TLSA
Certificate Usage DANE-EE(3), the domain owner has directly specified
the certificate associated with the given service without reference
to any public certification authority. Therefore, when a TLS client
authenticates the TLS server via a TLSA record with usage DANE-EE(3),
CT checks SHOULD NOT be performed. Publication of the server
certificate or public key (digest) in a TLSA record in a DNSSEC
signed zone by the domain owner assures the TLS client that the
certificate is not an unauthorized certificate issued by a rogue CA
without the domain owner's consent.
When a server is authenticated via a DANE TLSA record with TLSA usage
DANE-TA(2) and the server certificate does not chain to a known
public root CA, CT cannot apply (CT logs only accept chains that
start with a known, public root). Since TLSA Certificate Usage DANE-
TA(2) is generally intended to support non-public trust anchors, TLS
clients SHOULD NOT perform CT checks with usage DANE-TA(2).
4.3. Transitioning between PKIX-TA/EE and DANE-TA/EE
The choice of preferred certificate usages may need to change as a
protocol evolves. When transitioning between PKIX-TA/PKIX-EE and
DANE-TA/DANE-EE, clients begin to enable support for the new
certificate usage values. If the new preferred certificate usages
are PKIX-TA/EE this requires installing and managing the appropriate
set of CA trust anchors. During this time servers will publish both
types of TLSA records. At some later time when the vast majority of
servers have published the new preferred TLSA records, clients can
stop supporting the legacy certificate usages. Similarly, servers
can stop publishing legacy TLSA records once the vast majority of
clients support the new certificate usages.
5. Certificate-Usage Specific DANE Updates and Guidelines
The four Certificate Usage values from the TLSA record, DANE-EE(3), The four Certificate Usage values from the TLSA record, DANE-EE(3),
DANE-TA(2), PKIX-EE(1) and PKIX-TA(0), are discussed below. DANE-TA(2), PKIX-EE(1) and PKIX-TA(0), are discussed below.
4.1. Certificate Usage DANE-EE(3) 5.1. Certificate Usage DANE-EE(3)
In this section the meaning of DANE-EE(3) is updated from [RFC6698] In this section the meaning of DANE-EE(3) is updated from [RFC6698]
to specify that peer identity matching and that validity interval to specify that peer identity matching and that validity interval
compliance is based solely on the TLSA RRset properties. We also compliance is based solely on the TLSA RRset properties. We also
extend [RFC6698] to cover the use of DANE authentication of raw extend [RFC6698] to cover the use of DANE authentication of raw
public keys [I-D.ietf-tls-oob-pubkey] via TLSA records with public keys [I-D.ietf-tls-oob-pubkey] via TLSA records with
Certificate Usage DANE-EE(3) and selector SPKI(1). Certificate Usage DANE-EE(3) and selector SPKI(1).
Authentication via certificate usage DANE-EE(3) TLSA records involves Authentication via certificate usage DANE-EE(3) TLSA records involves
simply checking that the server's leaf certificate matches the TLSA simply checking that the server's leaf certificate matches the TLSA
skipping to change at page 8, line 16 skipping to change at page 10, line 5
with the same key. This TLSA record type easily supports hosting with the same key. This TLSA record type easily supports hosting
arrangements with a single certificate matching all hosted domains. arrangements with a single certificate matching all hosted domains.
It is also the easiest to implement correctly in the client. It is also the easiest to implement correctly in the client.
Another advantage of "DANE-EE(3) SPKI(1)" (with any suitable matching Another advantage of "DANE-EE(3) SPKI(1)" (with any suitable matching
type) TLSA records is that they are compatible with the raw public type) TLSA records is that they are compatible with the raw public
key TLS extension specified in [I-D.ietf-tls-oob-pubkey]. DANE key TLS extension specified in [I-D.ietf-tls-oob-pubkey]. DANE
clients that support this extension can use the TLSA record to clients that support this extension can use the TLSA record to
authenticate servers that negotiate the use of raw public keys in authenticate servers that negotiate the use of raw public keys in
place of X.509 certificate chains. Provided the server adheres to place of X.509 certificate chains. Provided the server adheres to
the requirements of Section 7, the fact that raw public keys are not the requirements of Section 8, the fact that raw public keys are not
compatible with any other TLSA record types will not get in the way compatible with any other TLSA record types will not get in the way
of successful authentication. Clients that employ DANE to of successful authentication. Clients that employ DANE to
authenticate the peer server SHOULD NOT negotiate the use of raw authenticate the peer server SHOULD NOT negotiate the use of raw
public keys unless the server's TLSA RRset includes compatible TLSA public keys unless the server's TLSA RRset includes compatible TLSA
records. records.
While it is, in principle, also possible to authenticate raw public While it is, in principle, also possible to authenticate raw public
keys via "DANE-EE(3) Cert(0) Full(0)" records by extracting the keys via "DANE-EE(3) Cert(0) Full(0)" records by extracting the
public key from the certificate in DNS, this is in conflict with the public key from the certificate in DNS, this is in conflict with the
indicated selector and requires extra logic on clients that not all indicated selector and requires extra logic on clients that not all
implementations are expected to provide. Servers SHOULD NOT rely on implementations are expected to provide. Servers SHOULD NOT rely on
"DANE-EE(3) Cert(0) Full(0)" TLSA records to publish authentication "DANE-EE(3) Cert(0) Full(0)" TLSA records to publish authentication
data for raw public keys. data for raw public keys.
4.2. Certificate Usage DANE-TA(2) 5.2. Certificate Usage DANE-TA(2)
This section updates [RFC6698] by specifying a new operational This section updates [RFC6698] by specifying a new operational
requirement for servers publishing TLSA records with a usage of DANE- requirement for servers publishing TLSA records with a usage of DANE-
TA(2): such servers MUST include the trust-anchor certificate in TA(2): such servers MUST include the trust-anchor certificate in
their TLS server certificate message. their TLS server certificate message.
Some domains may prefer to avoid the operational complexity of Some domains may prefer to avoid the operational complexity of
publishing unique TLSA RRs for each TLS service. If the domain publishing unique TLSA RRs for each TLS service. If the domain
employs a common issuing Certification Authority to create employs a common issuing Certification Authority to create
certificates for multiple TLS services, it may be simpler to publish certificates for multiple TLS services, it may be simpler to publish
skipping to change at page 9, line 16 skipping to change at page 10, line 48
www2.example.com. IN A 192.0.2.2 www2.example.com. IN A 192.0.2.2
_443._tcp.www1.example.com. IN CNAME tlsa201._dane.example.com. _443._tcp.www1.example.com. IN CNAME tlsa201._dane.example.com.
_443._tcp.www2.example.com. IN CNAME tlsa201._dane.example.com. _443._tcp.www2.example.com. IN CNAME tlsa201._dane.example.com.
tlsa201._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c14... tlsa201._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c14...
With usage DANE-TA(2) the server certificates will need to have names With usage DANE-TA(2) the server certificates will need to have names
that match one of the client's reference identifiers (see [RFC6125]). that match one of the client's reference identifiers (see [RFC6125]).
The server SHOULD employ SNI to select the appropriate certificate to The server SHOULD employ SNI to select the appropriate certificate to
present to the client. present to the client.
4.2.1. Recommended record combinations 5.2.1. Recommended record combinations
TLSA records with selector Full(0) are NOT RECOMMENDED. While these TLSA records with matching type Full(0) are NOT RECOMMENDED. While
potentially obviate the need to transmit the TA certificate in the these potentially obviate the need to transmit the TA certificate in
TLS server certificate message, client implementations may not be the TLS server certificate message, client implementations may not be
able to augment the server certificate chain with the data obtained able to augment the server certificate chain with the data obtained
from DNS, especially when the TLSA record supplies a bare key from DNS, especially when the TLSA record supplies a bare key
(selector SPKI(1)). Since the server will need to transmit the TA (selector SPKI(1)). Since the server will need to transmit the TA
certificate in any case, server operators SHOULD publish TLSA records certificate in any case, server operators SHOULD publish TLSA records
with a selector other than Full(0) and avoid potential DNS with a matching type other than Full(0) and avoid potential DNS
interoperability issues with large TLSA records containing full interoperability issues with large TLSA records containing full
certificates or keys (see Section 9.1.1). certificates or keys (see Section 10.1.1).
TLSA Publishers employing DANE-TA(2) records SHOULD publish records TLSA Publishers employing DANE-TA(2) records SHOULD publish records
with a selector of Cert(0). Such TLSA records are associated with with a selector of Cert(0). Such TLSA records are associated with
the whole trust anchor certificate, not just with the trust anchor the whole trust anchor certificate, not just with the trust anchor
public key. In particular, the client SHOULD then apply any relevant public key. In particular, the client SHOULD then apply any relevant
constraints from the trust anchor certificate, such as, for example, constraints from the trust anchor certificate, such as, for example,
path length constraints. path length constraints.
While a selector of SPKI(1) may also be employed, the resulting TLSA While a selector of SPKI(1) may also be employed, the resulting TLSA
record will not specify the full trust anchor certificate content, record will not specify the full trust anchor certificate content,
and elements of the trust anchor certificate other than the public and elements of the trust anchor certificate other than the public
key become mutable. This may, for example, enable a subsidiary CA to key become mutable. This may, for example, enable a subsidiary CA to
issue a chain that violates the trust anchor's path length or name issue a chain that violates the trust anchor's path length or name
constraints. constraints.
4.2.2. Trust anchor digests and server certificate chain 5.2.2. Trust anchor digests and server certificate chain
With DANE-TA(2) (these TLSA records are expected to match the digest With DANE-TA(2) (these TLSA records are expected to match the digest
of a TA certificate or public key), a complication arises when the TA of a TA certificate or public key), a complication arises when the TA
certificate is omitted from the server's certificate chain, perhaps certificate is omitted from the server's certificate chain, perhaps
on the basis of Section 7.4.2 of [RFC5246]: on the basis of Section 7.4.2 of [RFC5246]:
The sender's certificate MUST come first in the list. Each The sender's certificate MUST come first in the list. Each
following certificate MUST directly certify the one preceding following certificate MUST directly certify the one preceding
it. Because certificate validation requires that root keys be it. Because certificate validation requires that root keys be
distributed independently, the self-signed certificate that distributed independently, the self-signed certificate that
skipping to change at page 10, line 32 skipping to change at page 12, line 13
to authenticate the server. to authenticate the server.
TLSA Publishers that publish TLSA Certificate Usage DANE-TA(2) TLSA Publishers that publish TLSA Certificate Usage DANE-TA(2)
associations with a selector of SPKI(1) or using a digest-based associations with a selector of SPKI(1) or using a digest-based
matching type (not Full(0)) MUST ensure that the corresponding server matching type (not Full(0)) MUST ensure that the corresponding server
is configured to also include the trust anchor certificate in its TLS is configured to also include the trust anchor certificate in its TLS
handshake certificate chain, even if that certificate is a self- handshake certificate chain, even if that certificate is a self-
signed root CA and would have been optional in the context of the signed root CA and would have been optional in the context of the
existing public CA PKI. existing public CA PKI.
4.2.3. Trust anchor public keys 5.2.3. Trust anchor public keys
TLSA records with TLSA Certificate Usage DANE-TA(2), selector SPKI(1) TLSA records with TLSA Certificate Usage DANE-TA(2), selector SPKI(1)
and a matching type of Full(0) will publish the full public key of a and a matching type of Full(0) will publish the full public key of a
trust anchor via DNS. In section 6.1.1 of [RFC5280] the definition trust anchor via DNS. In section 6.1.1 of [RFC5280] the definition
of a trust anchor consists of the following four parts: of a trust anchor consists of the following four parts:
1. the trusted issuer name, 1. the trusted issuer name,
2. the trusted public key algorithm, 2. the trusted public key algorithm,
skipping to change at page 11, line 32 skipping to change at page 13, line 13
TA certificate in their certificate chain. TA certificate in their certificate chain.
If none of the server's certificate chain elements match a public key If none of the server's certificate chain elements match a public key
specified in a TLSA record, and at least one "DANE-TA(2) SPKI(1) specified in a TLSA record, and at least one "DANE-TA(2) SPKI(1)
Full(0)" TLSA record is available, clients are encouraged to check Full(0)" TLSA record is available, clients are encouraged to check
whether the topmost certificate in the chain is signed by the whether the topmost certificate in the chain is signed by the
provided public key and has not expired, and in that case consider provided public key and has not expired, and in that case consider
the server authenticated, provided the rest of the chain passes the server authenticated, provided the rest of the chain passes
validation including leaf certificate name checks. validation including leaf certificate name checks.
4.3. Certificate Usage PKIX-EE(1) 5.3. Certificate Usage PKIX-EE(1)
This Certificate Usage is similar to DANE-EE(3), but in addition PKIX This Certificate Usage is similar to DANE-EE(3), but in addition PKIX
verification is required. Therefore, name checks, certificate verification is required. Therefore, name checks, certificate
expiration, etc., apply as they would without DANE. When, for a expiration, etc., apply as they would without DANE.
given application protocol, DANE clients support both DANE-EE(3) and
PKIX-EE(1) usages, it should be noted that an attacker who can
compromise DNSSEC can replace these with usage DANE-EE(3) or DANE-
TA(2) TLSA records of their choosing, and thus bypass any PKIX
verification requirements.
Therefore, except when applications support only the PKIX Certificate
Usages (0 and 1), this Certificate Usage offers only illusory
incremental security over usage DANE-EE(3). It provides lower
operational reliability than DANE-EE(3) since some clients may not be
configured with the required root CA, the server's chain may be
incomplete or name checks may fail. PKIX-EE(1) also requires more
complex coordination between the Customer Domain and the Service
Provider in hosting arrangements. This certificate usage is NOT
RECOMMENDED.
4.4. Certificate Usage PKIX-TA(0) 5.4. Certificate Usage PKIX-TA(0)
This section updates [RFC6698] by specifying new client This section updates [RFC6698] by specifying new client
implementation requirements. Clients that trust intermediate implementation requirements. Clients that trust intermediate
certificates MUST be prepared to construct longer PKIX chains than certificates MUST be prepared to construct longer PKIX chains than
would be required for PKIX alone. would be required for PKIX alone.
TLSA Certificate Usage PKIX-TA(0) allows a domain to publish TLSA Certificate Usage PKIX-TA(0) allows a domain to publish
constraints on the set of PKIX certification authorities trusted to constraints on the set of PKIX certification authorities trusted to
issue certificates for its TLS servers. This TLSA record matches issue certificates for its TLS servers. This TLSA record matches
PKIX-verified trust chains which contain an issuer certificate (root PKIX-verified trust chains which contain an issuer certificate (root
or intermediate) that matches its association data field (typically a or intermediate) that matches its association data field (typically a
certificate or digest). certificate or digest).
As with PKIX-EE(1) case, an attacker who can compromise DNSSEC can PKIX-TA(0) also requires more complex coordination between the
replace these with usage DANE-EE(3) or DANE-TA(2) TLSA records of his Customer Domain and the Service Provider in hosting arrangements.
choosing and thus bypass the PKIX verification requirements. Thus, this certificate usage is NOT RECOMMENDED when the Service
Therefore, except when applications support only the PKIX Certificate Provider is not also the TLSA Publisher.
Usages (0 and 1), this Certificate Usage offers only illusory
incremental security over usage DANE-TA(2). It provides lower
operational reliability than DANE-TA(2) since some clients may not be
configured with the required root CA. PKIX-TA(0) also requires more
complex coordination between the Customer Domain and the Service
Provider in hosting arrangements. This certificate usage is NOT
RECOMMENDED.
TLSA Publishers who publish TLSA records for a particular public root TLSA Publishers who publish TLSA records for a particular public root
CA, will expect that clients will then only accept chains anchored at CA, will expect that clients will only accept chains anchored at that
that root. It is possible, however, that the client's trusted root. It is possible, however, that the client's trusted certificate
certificate store includes some intermediate CAs, either with or store includes some intermediate CAs, either with or without the
without the corresponding root CA. When a client constructs a trust corresponding root CA. When a client constructs a trust chain
chain leading from a trusted intermediate CA to the server leaf leading from a trusted intermediate CA to the server leaf
certificate, such a "truncated" chain might not contain the trusted certificate, such a "truncated" chain might not contain the trusted
root published in the server's TLSA record. root published in the server's TLSA record.
If the omitted root is also trusted, the client may erroneously If the omitted root is also trusted, the client may erroneously
reject the server chain if it fails to determine that the shorter reject the server chain if it fails to determine that the shorter
chain it constructed extends to a longer trusted chain that matches chain it constructed extends to a longer trusted chain that matches
the TLSA record. Thus, when matching a usage PKIX-TA(0) TLSA record, the TLSA record. Thus, when matching a usage PKIX-TA(0) TLSA record,
a client SHOULD NOT always stop extending the chain when the first a client SHOULD NOT always stop extending the chain when the first
locally trusted certificate is found. If no TLSA records have locally trusted certificate is found. If no TLSA records have
matched any of the elements of the chain, and the trusted certificate matched any of the elements of the chain, and the trusted certificate
found is not self-issued, the client MUST attempt to build a longer found is not self-issued, the client MUST attempt to build a longer
chain in the hope that a certificate closer to the root may in fact chain in the hope that a certificate closer to the root may in fact
match the server's TLSA record. match the server's TLSA record.
4.5. Opportunistic Security and PKIX usages 6. Service Provider and TLSA Publisher Synchronization
When the client's protocol design is based on Opportunistic Security
(OS, [I-D.dukhovni-opportunistic-security]), and authentication is
opportunistically employed based on the presence of server TLSA
records, it is especially important to avoid the PKIX-EE(1) and PKIX-
TA(0) certificate usages. This is because the client has no way to
know in advance that it and the server both trust the requisite root
CA. Use of authentication in OS needs to be employed only when the
client can be confident of success, absent an attack, or an
operational error on the server side.
5. Service Provider and TLSA Publisher Synchronization
Complications arise when the TLSA Publisher is not the same entity as Complications arise when the TLSA Publisher is not the same entity as
the Service Provider. In this situation, the TLSA Publisher and the the Service Provider. In this situation, the TLSA Publisher and the
Service Provider must cooperate to ensure that TLSA records published Service Provider must cooperate to ensure that TLSA records published
by the TLSA Publisher don't fall out of sync with the server by the TLSA Publisher don't fall out of sync with the server
certificate used by the Service Provider. certificate used by the Service Provider.
Whenever possible, the TLSA Publisher and the Service Provider should Whenever possible, the TLSA Publisher and the Service Provider should
be the same entity. Otherwise, changes in the service certificate be the same entity. Otherwise, changes in the service certificate
chain must be carefully coordinated between the parties involved. chain must be carefully coordinated between the parties involved.
skipping to change at page 13, line 43 skipping to change at page 14, line 38
it is possible to employ CNAME records to delegate the content of the it is possible to employ CNAME records to delegate the content of the
TLSA RRset to a domain operated by the Service Provider. Certificate TLSA RRset to a domain operated by the Service Provider. Certificate
name checks generally constrain the applicability of TLSA CNAMEs name checks generally constrain the applicability of TLSA CNAMEs
across organizational boundaries to Certificate Usages DANE-EE(3) and across organizational boundaries to Certificate Usages DANE-EE(3) and
DANE-TA(2): DANE-TA(2):
Certificate Usage DANE-EE(3): In this case the Service Provider can Certificate Usage DANE-EE(3): In this case the Service Provider can
publish a single TLSA RRset that matches the server certificate or publish a single TLSA RRset that matches the server certificate or
public key digest. The same RRset works for all Customer Domains public key digest. The same RRset works for all Customer Domains
because name checks do not apply with DANE-EE(3) TLSA records (see because name checks do not apply with DANE-EE(3) TLSA records (see
Section 4.1). A Customer Domain can create a CNAME record Section 5.1). A Customer Domain can create a CNAME record
pointing to the TLSA RRset published by the Service Provider. pointing to the TLSA RRset published by the Service Provider.
Certificate Usage DANE-TA(2): When the Service Provider operates a Certificate Usage DANE-TA(2): When the Service Provider operates a
private certification authority, the Service Provider is free to private certification authority, the Service Provider is free to
issue a certificate bearing any customer's domain name. Without issue a certificate bearing any customer's domain name. Without
DANE, such a certificate would not pass trust verification, but DANE, such a certificate would not pass trust verification, but
with DANE, the customer's TLSA RRset that is aliased to the with DANE, the customer's TLSA RRset that is aliased to the
provider's TLSA RRset can delegate authority to the provider's CA provider's TLSA RRset can delegate authority to the provider's CA
for the corresponding service. The Service Provider can generate for the corresponding service. The Service Provider can generate
appropriate certificates for each customer and use the SNI appropriate certificates for each customer and use the SNI
information provided by clients to select the right certificate information provided by clients to select the right certificate
chain to present to each client. chain to present to each client.
Below are example DNS records (assumed "secure" and shown without the Below are example DNS records (assumed "secure" and shown without the
associated DNSSEC information, such as record signatures) that associated DNSSEC information, such as record signatures) that
illustrate both of of the above models in the case of an HTTPS illustrate both of of the above models in the case of an HTTPS
service whose clients all support DANE TLS. These examples work even service whose clients all support DANE TLS. These examples work even
with clients that don't "chase" CNAMEs when constructing the TLSA with clients that don't "chase" CNAMEs when constructing the TLSA
base domain (see Section 6 below). base domain (see Section 7 below).
; The hosted web service is redirected via a CNAME alias. ; The hosted web service is redirected via a CNAME alias.
; The associated TLSA RRset is also redirected via a CNAME alias. ; The associated TLSA RRset is also redirected via a CNAME alias.
; ;
; A single certificate at the provider works for all Customer ; A single certificate at the provider works for all Customer
; Domains due to the use of the DANE-EE(3) Certificate Usage. ; Domains due to the use of the DANE-EE(3) Certificate Usage.
; ;
www1.example.com. IN CNAME w1.example.net. www1.example.com. IN CNAME w1.example.net.
_443._tcp.www1.example.com. IN CNAME _443._tcp.w1.example.net. _443._tcp.www1.example.com. IN CNAME _443._tcp.w1.example.net.
_443._tcp.w1.example.net. IN TLSA DANE-EE SPKI SHA2-256 ( _443._tcp.w1.example.net. IN TLSA DANE-EE SPKI SHA2-256 (
skipping to change at page 15, line 25 skipping to change at page 16, line 25
If redirection to the Service Provider's domain (via MX or SRV If redirection to the Service Provider's domain (via MX or SRV
records or any similar mechanism) is not possible, and aliasing of records or any similar mechanism) is not possible, and aliasing of
the TLSA record is not an option, then more complex coordination the TLSA record is not an option, then more complex coordination
between the Customer Domain and Service Provider will be required. between the Customer Domain and Service Provider will be required.
Either the Customer Domain periodically provides private keys and a Either the Customer Domain periodically provides private keys and a
corresponding certificate chain to the Provider (after making corresponding certificate chain to the Provider (after making
appropriate changes in its TLSA records), or the Service Provider appropriate changes in its TLSA records), or the Service Provider
periodically generates the keys and certificates and must wait for periodically generates the keys and certificates and must wait for
matching TLSA records to be published by its Customer Domains before matching TLSA records to be published by its Customer Domains before
deploying newly generated keys and certificate chains. In Section 6 deploying newly generated keys and certificate chains. In Section 7
below, we describe an approach that employs CNAME "chasing" to avoid below, we describe an approach that employs CNAME "chasing" to avoid
the difficulties of coordinating key management across organization the difficulties of coordinating key management across organization
boundaries. boundaries.
For further information about combining DANE and SRV, please see For further information about combining DANE and SRV, please see
[I-D.ietf-dane-srv]. [I-D.ietf-dane-srv].
6. TLSA Base Domain and CNAMEs 7. TLSA Base Domain and CNAMEs
When the application protocol does not support service location When the application protocol does not support service location
indirection via MX, SRV or similar DNS records, the service may be indirection via MX, SRV or similar DNS records, the service may be
redirected via a CNAME. A CNAME is a more blunt instrument for this redirected via a CNAME. A CNAME is a more blunt instrument for this
purpose, since unlike an MX or SRV record, it remaps the entire purpose, since unlike an MX or SRV record, it remaps the entire
origin domain to the target domain for all protocols. origin domain to the target domain for all protocols.
The complexity of coordinating key management is largely eliminated The complexity of coordinating key management is largely eliminated
when DANE TLSA records are found in the Service Provider's domain, as when DANE TLSA records are found in the Service Provider's domain, as
discussed in Section 5. Therefore, DANE TLS clients connecting to a discussed in Section 6. Therefore, DANE TLS clients connecting to a
server whose domain name is a CNAME alias SHOULD follow the CNAME server whose domain name is a CNAME alias SHOULD follow the CNAME
hop-by-hop to its ultimate target host (noting at each step whether hop-by-hop to its ultimate target host (noting at each step whether
the CNAME is DNSSEC-validated). If at each stage of CNAME expansion the CNAME is DNSSEC-validated). If at each stage of CNAME expansion
the DNSSEC validation status is "secure", the final target name the DNSSEC validation status is "secure", the final target name
SHOULD be the preferred base domain for TLSA lookups. SHOULD be the preferred base domain for TLSA lookups.
Implementations failing to find a TLSA record using a base name of Implementations failing to find a TLSA record using a base name of
the final target of a CNAME expansion SHOULD issue a TLSA query using the final target of a CNAME expansion SHOULD issue a TLSA query using
the original destination name. That is, the preferred TLSA base the original destination name. That is, the preferred TLSA base
domain should be derived from the fully expanded name, and failing domain should be derived from the fully expanded name, and failing
skipping to change at page 16, line 23 skipping to change at page 17, line 23
or restrictions when following CNAME expansions. or restrictions when following CNAME expansions.
Though CNAMEs are illegal on the right hand side of most indirection Though CNAMEs are illegal on the right hand side of most indirection
records, such as MX and SRV records, they are supported by some records, such as MX and SRV records, they are supported by some
implementations. For example, if the MX or SRV host is a CNAME implementations. For example, if the MX or SRV host is a CNAME
alias, some implementations may "chase" the CNAME. If they do, they alias, some implementations may "chase" the CNAME. If they do, they
SHOULD use the target hostname as the preferred TLSA base domain as SHOULD use the target hostname as the preferred TLSA base domain as
described above (and if the TLSA records are found there, use the described above (and if the TLSA records are found there, use the
CNAME expanded domain also in SNI and certificate name checks). CNAME expanded domain also in SNI and certificate name checks).
7. TLSA Publisher Requirements 8. TLSA Publisher Requirements
This section updates [RFC6698] by specifying a requirement on the This section updates [RFC6698] by specifying a requirement on the
TLSA Publisher to ensure that each combination of Certificate Usage, TLSA Publisher to ensure that each combination of Certificate Usage,
selector and matching type in the server's TLSA RRset MUST include at selector and matching type in the server's TLSA RRset MUST include at
least one record that matches the server's current certificate chain. least one record that matches the server's current certificate chain.
TLSA records that match recently retired or yet to be deployed TLSA records that match recently retired or yet to be deployed
certificate chains will be present during key rollover. Such past or certificate chains will be present during key rollover. Such past or
future records must never be the only records published for any given future records must never be the only records published for any given
combination of usage, selector and matching type. We describe a TLSA combination of usage, selector and matching type. We describe a TLSA
record update algorithm that ensures this requirement is met. record update algorithm that ensures this requirement is met.
skipping to change at page 17, line 15 skipping to change at page 18, line 15
A consequence of the above uncertainty as to which TLSA parameters A consequence of the above uncertainty as to which TLSA parameters
are supported by any given client is that servers need to ensure that are supported by any given client is that servers need to ensure that
each and every parameter combination that appears in the TLSA RRset each and every parameter combination that appears in the TLSA RRset
is, on its own, sufficient to match the server's current certificate is, on its own, sufficient to match the server's current certificate
chain. In particular, when deploying new keys or new parameter chain. In particular, when deploying new keys or new parameter
combinations some care is required to not generate parameter combinations some care is required to not generate parameter
combinations that only match past or future certificate chains (or combinations that only match past or future certificate chains (or
raw public keys). The rest of this section explains how to update raw public keys). The rest of this section explains how to update
the TLSA RRset in a manner that ensures the above requirement is met. the TLSA RRset in a manner that ensures the above requirement is met.
7.1. Key rollover with fixed TLSA Parameters 8.1. Key rollover with fixed TLSA Parameters
The simplest case is key rollover while retaining the same set of The simplest case is key rollover while retaining the same set of
published parameter combinations. In this case, TLSA records published parameter combinations. In this case, TLSA records
matching the existing server certificate chain (or raw public keys) matching the existing server certificate chain (or raw public keys)
are first augmented with corresponding records matching the future are first augmented with corresponding records matching the future
keys, at least two TTLs or longer before the the new chain is keys, at least two TTLs or longer before the the new chain is
deployed. This allows the obsolete RRset to age out of client caches deployed. This allows the obsolete RRset to age out of client caches
before the new chain is used in TLS handshakes. Once sufficient time before the new chain is used in TLS handshakes. Once sufficient time
has elapsed and all clients performing DNS lookups are retrieving the has elapsed and all clients performing DNS lookups are retrieving the
updated TLSA records, the server administrator may deploy the new updated TLSA records, the server administrator may deploy the new
skipping to change at page 18, line 13 skipping to change at page 19, line 13
only then deploy new keys if desired: only then deploy new keys if desired:
; Initial TLSA RRset ; Initial TLSA RRset
; ;
_443._tcp.www.example.org. IN TLSA 1 1 1 01d09d19c2139a46... _443._tcp.www.example.org. IN TLSA 1 1 1 01d09d19c2139a46...
; New TLSA RRset, same key re-published as DANE-EE(3) ; New TLSA RRset, same key re-published as DANE-EE(3)
; ;
_443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
7.2. Switching to DANE-TA from DANE-EE 8.2. Switching to DANE-TA from DANE-EE
A more complex involves switching to a trust-anchor or PKIX usage A more complex involves switching to a trust-anchor or PKIX usage
from a chain that is either self-signed, or issued by a private CA from a chain that is either self-signed, or issued by a private CA
and thus not compatible with PKIX. Here the process is to first add and thus not compatible with PKIX. Here the process is to first add
TLSA records matching the future chain that is issued by the desired TLSA records matching the future chain that is issued by the desired
future CA (private or PKIX), but initially with the same parameters future CA (private or PKIX), but initially with the same parameters
as the legacy chain. Then, after deploying the new keys, switch to as the legacy chain. Then, after deploying the new keys, switch to
the new TLSA parameter combination. the new TLSA parameter combination.
; The initial TLSA RRset ; The initial TLSA RRset
skipping to change at page 18, line 40 skipping to change at page 19, line 40
; ;
_443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
_443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b... _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
; The final TLSA RRset after the key change. Now that the old ; The final TLSA RRset after the key change. Now that the old
; self-signed EE keys are not an impediment, specify the issuing ; self-signed EE keys are not an impediment, specify the issuing
; TA of the new keys. ; TA of the new keys.
; ;
_443._tcp.www.example.org. IN TLSA 2 0 1 c57bce38455d9e3d... _443._tcp.www.example.org. IN TLSA 2 0 1 c57bce38455d9e3d...
7.3. Switching to New TLSA Parameters 8.3. Switching to New TLSA Parameters
When employing a new digest algorithm in the TLSA RRset, for When employing a new digest algorithm in the TLSA RRset, for
compatibility with digest agility specified in Section 8 below, compatibility with digest agility specified in Section 9 below,
administrators should publish the new digest algorithm with each administrators should publish the new digest algorithm with each
combinations of Certificate Usage and selector for each associated combinations of Certificate Usage and selector for each associated
key or chain used with any other digest algorithm. When removing an key or chain used with any other digest algorithm. When removing an
algorithm, remove it entirely. Each digest algorithm employed should algorithm, remove it entirely. Each digest algorithm employed should
match the same set of chains (or raw public keys). match the same set of chains (or raw public keys).
; The initial TLSA RRset with EE SHA2-256 associations for two keys. ; The initial TLSA RRset with EE SHA2-256 associations for two keys.
; ;
_443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
_443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b... _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
; The new TLSA RRset also with SHA2-512 associations for each key ; The new TLSA RRset also with SHA2-512 associations for each key
; ;
_443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46... _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
_443._tcp.www.example.org. IN TLSA 3 1 2 d9947c35089310bc... _443._tcp.www.example.org. IN TLSA 3 1 2 d9947c35089310bc...
_443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b... _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
_443._tcp.www.example.org. IN TLSA 3 1 2 89a7486a4b6ae714... _443._tcp.www.example.org. IN TLSA 3 1 2 89a7486a4b6ae714...
7.4. TLSA Publisher Requirements Summary 8.4. TLSA Publisher Requirements Summary
In summary, server operators updating TLSA records should make one In summary, server operators updating TLSA records should make one
change at a time. The individual safe changes are: change at a time. The individual safe changes are:
o Pre-publish new certificate associations that employ the same TLSA o Pre-publish new certificate associations that employ the same TLSA
parameters (usage, selector and matching type) as existing TLSA parameters (usage, selector and matching type) as existing TLSA
records, but match certificate chains that will be deployed in the records, but match certificate chains that will be deployed in the
near future. Wait for stale TLSA RRsets to expire from DNS caches near future. Wait for stale TLSA RRsets to expire from DNS caches
before configuring servers to use the new certificate chain. before configuring servers to use the new certificate chain.
skipping to change at page 19, line 45 skipping to change at page 20, line 45
The above steps are intended to ensure that at all times and for each The above steps are intended to ensure that at all times and for each
combination of usage, selector and matching type at least one TLSA combination of usage, selector and matching type at least one TLSA
record corresponds to the server's current certificate chain. No record corresponds to the server's current certificate chain. No
combination of Certificate Usage, selector and matching type in a combination of Certificate Usage, selector and matching type in a
server's TLSA RRset should ever match only some combination of future server's TLSA RRset should ever match only some combination of future
or past certificate chains. As a result, no matter what combinations or past certificate chains. As a result, no matter what combinations
of usage, selector and matching type may be supported by a given of usage, selector and matching type may be supported by a given
client, they will be sufficient to authenticate the server. client, they will be sufficient to authenticate the server.
8. Digest Algorithm Agility 9. Digest Algorithm Agility
While [RFC6698] specifies multiple digest algorithms, it does not While [RFC6698] specifies multiple digest algorithms, it does not
specify a protocol by which the TLS client and TLSA record publisher specify a protocol by which the TLS client and TLSA record publisher
can agree on the strongest shared algorithm. Such a protocol would can agree on the strongest shared algorithm. Such a protocol would
allow the client and server to avoid exposure to any deprecated allow the client and server to avoid exposure to any deprecated
weaker algorithms that are published for compatibility with less weaker algorithms that are published for compatibility with less
capable clients, but should be ignored when possible. We specify capable clients, but should be ignored when possible. We specify
such a protocol below. such a protocol below.
Suppose that a DANE TLS client authenticating a TLS server considers Suppose that a DANE TLS client authenticating a TLS server considers
digest algorithm "BetterAlg" stronger than digest algorithm digest algorithm "BetterAlg" stronger than digest algorithm
"WorseAlg". Suppose further that a server's TLSA RRset contains some "WorseAlg". Suppose further that a server's TLSA RRset contains some
records with "BetterAlg" as the digest algorithm. Suppose also that records with "BetterAlg" as the digest algorithm. Suppose also that
the server adheres to the requirements of Section 7 and ensures that the server adheres to the requirements of Section 8 and ensures that
each combination of TLSA parameters contains at least one record that each combination of TLSA parameters contains at least one record that
matches the server's current certificate chain (or raw public keys). matches the server's current certificate chain (or raw public keys).
Under the above assumptions the client can safely ignore TLSA records Under the above assumptions the client can safely ignore TLSA records
with the weaker algorithm "WorseAlg", because it suffices to only with the weaker algorithm "WorseAlg", because it suffices to only
check the records with the stronger algorithm "BetterAlg". check the records with the stronger algorithm "BetterAlg".
To make digest algorithm agility possible, all published TLSA RRsets To make digest algorithm agility possible, all published TLSA RRsets
for use with DANE TLS MUST conform to the requirements of Section 7. for use with DANE TLS MUST conform to the requirements of Section 8.
With servers publishing compliant TLSA RRsets, TLS clients can, for With servers publishing compliant TLSA RRsets, TLS clients can, for
each combination of usage and selector, ignore all digest records each combination of usage and selector, ignore all digest records
except those that employ their notion of the strongest digest except those that employ their notion of the strongest digest
algorithm. (The server should only publish algorithms it deems algorithm. (The server should only publish algorithms it deems
acceptable at all.) The ordering of digest algorithms by strength is acceptable at all.) The ordering of digest algorithms by strength is
not specified in advance; it is entirely up to the TLS client. TLS not specified in advance; it is entirely up to the TLS client. TLS
client implementations SHOULD make the digest algorithm preference client implementations SHOULD make the digest algorithm preference
ordering a configurable option. ordering a configurable option.
Note, TLSA records with a matching type of Full(0) that publish an Note, TLSA records with a matching type of Full(0) that publish an
skipping to change at page 20, line 49 skipping to change at page 21, line 49
TLS clients SHOULD use digest algorithm agility when processing the TLS clients SHOULD use digest algorithm agility when processing the
DANE TLSA records of an TLS server. Algorithm agility is to be DANE TLSA records of an TLS server. Algorithm agility is to be
applied after first discarding any unusable or malformed records applied after first discarding any unusable or malformed records
(unsupported digest algorithm, or incorrect digest length). Thus, (unsupported digest algorithm, or incorrect digest length). Thus,
for each usage and selector, the client SHOULD process only any for each usage and selector, the client SHOULD process only any
usable records with a matching type of Full(0) and the usable records usable records with a matching type of Full(0) and the usable records
whose digest algorithm is considered by the client to be the whose digest algorithm is considered by the client to be the
strongest among usable records with the given usage and selector. strongest among usable records with the given usage and selector.
9. General DANE Guidelines 10. General DANE Guidelines
These guidelines provide guidance for using or designing protocols These guidelines provide guidance for using or designing protocols
for DANE. for DANE.
9.1. DANE DNS Record Size Guidelines 10.1. DANE DNS Record Size Guidelines
Selecting a combination of TLSA parameters to use requires careful Selecting a combination of TLSA parameters to use requires careful
thought. One important consideration to take into account is the thought. One important consideration to take into account is the
size of the resulting TLSA record after its parameters are selected. size of the resulting TLSA record after its parameters are selected.
9.1.1. UDP and TCP Considerations 10.1.1. UDP and TCP Considerations
Deployments SHOULD avoid TLSA record sizes that cause UDP Deployments SHOULD avoid TLSA record sizes that cause UDP
fragmentation. fragmentation.
Although DNS over TCP would provide the ability to more easily Although DNS over TCP would provide the ability to more easily
transfer larger DNS records between clients and servers, it is not transfer larger DNS records between clients and servers, it is not
universally deployed and is still prohibited by some firewalls. universally deployed and is still prohibited by some firewalls.
Clients that request DNS records via UDP typically only use TCP upon Clients that request DNS records via UDP typically only use TCP upon
receipt of a truncated response in the DNS response message sent over receipt of a truncated response in the DNS response message sent over
UDP. Setting the TC bit alone will be insufficient if the response UDP. Setting the TC bit alone will be insufficient if the response
containing the TC bit is itself fragmented. containing the TC bit is itself fragmented.
9.1.2. Packet Size Considerations for TLSA Parameters 10.1.2. Packet Size Considerations for TLSA Parameters
Server operators SHOULD NOT publish TLSA records using both a TLSA Server operators SHOULD NOT publish TLSA records using both a TLSA
Selector of Cert(0) and a TLSA Matching Type of Full(0), as even a Selector of Cert(0) and a TLSA Matching Type of Full(0), as even a
single certificate is generally too large to be reliably delivered single certificate is generally too large to be reliably delivered
via DNS over UDP. Furthermore, two TLSA records containing full via DNS over UDP. Furthermore, two TLSA records containing full
certificates will need to be published simultaneously during a certificates will need to be published simultaneously during a
certificate rollover, as discussed in Section 7.1. certificate rollover, as discussed in Section 8.1.
While TLSA records using a TLSA Selector of SPKI(1) and a TLSA While TLSA records using a TLSA Selector of SPKI(1) and a TLSA
Matching Type of Full(0) (which publish the bare public keys without Matching Type of Full(0) (which publish the bare public keys without
the overhead of a containing X.509 certificate) are generally more the overhead of a containing X.509 certificate) are generally more
compact, these too should be used with caution as they are still compact, these too should be used with caution as they are still
larger than necessary. Rather, servers SHOULD publish digest-based larger than necessary. Rather, servers SHOULD publish digest-based
TLSA Matching Types in their TLSA records. The complete TLSA Matching Types in their TLSA records. The complete
corresponding certificate should, instead, be transmitted to the corresponding certificate should, instead, be transmitted to the
client in-band during the TLS handshake, which can be easily verified client in-band during the TLS handshake, which can be easily verified
using the digest value. using the digest value.
In summary, the use of a TLSA Matching Type of Full(0) is NOT In summary, the use of a TLSA Matching Type of Full(0) is NOT
RECOMMENDED and the use of a digest-based matching type, such as RECOMMENDED and the use of a digest-based matching type, such as
SHA2-256(1) SHOULD be used. SHA2-256(1) SHOULD be used.
9.2. Certificate Name Check Conventions 10.2. Certificate Name Check Conventions
Certificates presented by a TLS server will generally contain a Certificates presented by a TLS server will generally contain a
subjectAltName (SAN) extension or a Common Name (CN) element within subjectAltName (SAN) extension or a Common Name (CN) element within
the subject distinguished name (DN). The TLS server's DNS domain the subject distinguished name (DN). The TLS server's DNS domain
name is normally published within these elements, ideally within the name is normally published within these elements, ideally within the
subjectAltName extension. (The use of the CN field for this purpose subjectAltName extension. (The use of the CN field for this purpose
is deprecated.) is deprecated.)
When a server hosts multiple domains at the same transport endpoint, When a server hosts multiple domains at the same transport endpoint,
the server's ability to respond with the right certificate chain is the server's ability to respond with the right certificate chain is
predicated on correct SNI information from the client. DANE clients predicated on correct SNI information from the client. DANE clients
MUST send the SNI extension with a HostName value of the base domain MUST send the SNI extension with a HostName value of the base domain
of the TLSA RRset. of the TLSA RRset.
Except with TLSA Certificate Usage DANE-EE(3), where name checks are Except with TLSA Certificate Usage DANE-EE(3), where name checks are
not applicable (see Section 4.1), DANE clients MUST verify that the not applicable (see Section 5.1), DANE clients MUST verify that the
client has reached the correct server by checking that the server client has reached the correct server by checking that the server
name is listed in the server certificate's SAN or CN. The server name is listed in the server certificate's SAN or CN. The server
name used for this comparison SHOULD be the base domain of the TLSA name used for this comparison SHOULD be the base domain of the TLSA
RRset. Additional acceptable names may be specified by protocol- RRset. Additional acceptable names may be specified by protocol-
specific DANE standards. For example, with SMTP both the destination specific DANE standards. For example, with SMTP both the destination
domain name and the MX host name are acceptable names to be found in domain name and the MX host name are acceptable names to be found in
the server certificate (see [I-D.ietf-dane-smtp-with-dane]). the server certificate (see [I-D.ietf-dane-smtp-with-dane]).
It is the responsibility of the service operator, in coordination It is the responsibility of the service operator, in coordination
with the TLSA Publisher, to ensure that at least one of the TLSA with the TLSA Publisher, to ensure that at least one of the TLSA
skipping to change at page 23, line 5 skipping to change at page 24, line 5
HostName in the client's SNI extension. The server certificate chain HostName in the client's SNI extension. The server certificate chain
is required to be be signed by a trust anchor with the above is required to be be signed by a trust anchor with the above
certificate SHA2-256 digest. Finally, one of the DNS names in the certificate SHA2-256 digest. Finally, one of the DNS names in the
server certificate is required to be be either "mail.example.com" or server certificate is required to be be either "mail.example.com" or
"example.com" (this additional name is a concession to compatibility "example.com" (this additional name is a concession to compatibility
with prior practice, see [I-D.ietf-dane-smtp-with-dane] for details). with prior practice, see [I-D.ietf-dane-smtp-with-dane] for details).
The semantics of wildcards in server certificates are left to The semantics of wildcards in server certificates are left to
individual application protocol specifications. individual application protocol specifications.
9.3. Design Considerations for Protocols Using DANE 10.3. Design Considerations for Protocols Using DANE
When a TLS client goes to the trouble of authenticating a certificate When a TLS client goes to the trouble of authenticating a certificate
chain presented by a TLS server, it will typically not continue to chain presented by a TLS server, it will typically not continue to
use that server in the event of authentication failure, or else use that server in the event of authentication failure, or else
authentication serves no purpose. Some clients may, at times, authentication serves no purpose. Some clients may, at times,
operate in an "audit" mode, where authentication failure is reported operate in an "audit" mode, where authentication failure is reported
to the user or in logs as a potential problem, but the connection to the user or in logs as a potential problem, but the connection
proceeds despite the failure. Nevertheless servers publishing TLSA proceeds despite the failure. Nevertheless servers publishing TLSA
records MUST be configured to allow correctly configured clients to records MUST be configured to allow correctly configured clients to
successfully authenticate their TLS certificate chains. successfully authenticate their TLS certificate chains.
skipping to change at page 23, line 34 skipping to change at page 24, line 34
client SHOULD generally use the server via an unauthenticated TLS client SHOULD generally use the server via an unauthenticated TLS
connection, but if TLS encryption cannot be established, the client connection, but if TLS encryption cannot be established, the client
MUST NOT use the server. Standards for DANE specific to the MUST NOT use the server. Standards for DANE specific to the
particular application protocol may modify the above requirements, as particular application protocol may modify the above requirements, as
appropriate, to specify whether the connection should be established appropriate, to specify whether the connection should be established
anyway without relying on TLS security, with only encryption but not anyway without relying on TLS security, with only encryption but not
authentication, or whether to refuse to connect entirely. authentication, or whether to refuse to connect entirely.
Application protocols need to specify when to prioritize security Application protocols need to specify when to prioritize security
over the ability to connect under adverse conditions. over the ability to connect under adverse conditions.
9.3.1. Design Considerations for non-PKIX Protocols
For some application protocols (such as SMTP to MX with opportunistic
TLS), the existing public CA PKI is not a viable alternative to DANE.
For these (non-PKIX) protocols, new DANE standards SHOULD NOT suggest
publishing TLSA records with TLSA Certificate Usage PKIX-TA(0) or
PKIX-EE(1), as TLS clients cannot be expected to perform [RFC5280]
PKIX validation or [RFC6125] identity verification.
Protocols designed for non-PKIX use SHOULD choose to treat any TLSA
records with TLSA Certificate Usage PKIX-TA(0) or PKIX-EE(1) as
unusable. After verifying that the only available TLSA Certificate
Usage types are PKIX-TA(0) or PKIX-EE(1), protocol specifications MAY
instruct clients to either refuse to initiate a connection or to
connect via unauthenticated TLS if no alternative authentication
mechanisms are available.
10. Interaction with Certificate Transparency
Certificate Transparency (CT) [RFC6962] defines an experimental
approach to mitigate the risk of rogue or compromised public CAs
issuing unauthorized certificates. This section clarifies the
interaction of CT and DANE. CT is an experimental protocol and
auditing system that applies only to public CAs, and only when they
are free to issue unauthorized certificates for a domain. If the CA
is not a public CA, or a DANE-EE(3) TLSA RR directly specifies the
end entity certificate, there is no role for CT, and clients need not
apply CT checks.
When a server is authenticated via a DANE TLSA RR with TLSA
Certificate Usage DANE-EE(3), the domain owner has directly specified
the certificate associated with the given service without reference
to any PKIX certification authority. Therefore, when a TLS client
authenticates the TLS server via a TLSA certificate association with
usage DANE-EE(3), CT checks SHOULD NOT be performed. Publication of
the server certificate or public key (digest) in a TLSA record in a
DNSSEC signed zone by the domain owner assures the TLS client that
the certificate is not an unauthorized certificate issued by a rogue
CA without the domain owner's consent.
When a server is authenticated via a DANE TLSA RR with TLSA usage
DANE-TA(2) and the server certificate does not chain to a known
public root CA, CT cannot apply (CT logs only accept chains that
start with a known, public root). Since TLSA Certificate Usage DANE-
TA(2) is generally intended to support non-PKIX trust anchors, TLS
clients SHOULD NOT perform CT checks with usage DANE-TA(2) using
unknown root CAs.
A server operator who wants clients to perform CT checks should
publish TLSA RRs with usage PKIX-TA(0) or PKIX-EE(1).
11. Note on DNSSEC Security 11. Note on DNSSEC Security
Clearly the security of the DANE TLSA PKI rests on the security of Clearly the security of the DANE TLSA PKI rests on the security of
the underlying DNSSEC infrastructure. While this memo is not a guide the underlying DNSSEC infrastructure. While this memo is not a guide
to DNSSEC security, a few comments may be helpful to TLSA to DNSSEC security, a few comments may be helpful to TLSA
implementers. implementers.
With the existing public CA PKI, name constraints are rarely used, With the existing public CA PKI, name constraints are rarely used,
and a public root CA can issue certificates for any domain of its and a public root CA can issue certificates for any domain of its
choice. With DNSSEC, under the Registry/Registrar/Registrant model, choice. With DNSSEC, under the Registry/Registrar/Registrant model,
skipping to change at page 25, line 32 skipping to change at page 25, line 30
bogus. bogus.
12. Summary of Updates to RFC6698 12. Summary of Updates to RFC6698
Authors note: is this section needed? Or is it sufficiently clear Authors note: is this section needed? Or is it sufficiently clear
above that we don't need to restate things here? above that we don't need to restate things here?
o In Section 3 we update [RFC6698] to specify a requirement for o In Section 3 we update [RFC6698] to specify a requirement for
clients to support at least TLS 1.0, and to support SNI. clients to support at least TLS 1.0, and to support SNI.
o In Section 4.1 we update [RFC6698] to specify peer identity o In Section 5.1 we update [RFC6698] to specify peer identity
matching and certificate validity interval based solely on the matching and certificate validity interval based solely on the
basis of the TLSA RRset. We also specify DANE authentication of basis of the TLSA RRset. We also specify DANE authentication of
raw public keys [I-D.ietf-tls-oob-pubkey] via TLSA records with raw public keys [I-D.ietf-tls-oob-pubkey] via TLSA records with
Certificate Usage DANE-EE(3) and selector SPKI(1). Certificate Usage DANE-EE(3) and selector SPKI(1).
o In Section 4.2 we update [RFC6698] to require that servers o In Section 5.2 we update [RFC6698] to require that servers
publishing digest TLSA records with a usage of DANE-TA(2) MUST publishing digest TLSA records with a usage of DANE-TA(2) MUST
include the trust-anchor certificate in their TLS server include the trust-anchor certificate in their TLS server
certificate message. This extends to the case of "2 1 0" TLSA certificate message. This extends to the case of "2 1 0" TLSA
records which publish a full public key. records which publish a full public key.
o In Section 4.3 and Section 4.4, we explain that PKIX-EE(1) and o In Section 5.3 and Section 5.4, we explain that PKIX-EE(1) and
PKIX-TA(0) are generally NOT RECOMMENDED. With usage PKIX-TA(0) PKIX-TA(0) are generally NOT RECOMMENDED. With usage PKIX-TA(0)
we note that clients may need to processes extended trust chains we note that clients may need to processes extended trust chains
beyond the first trusted issuer, when that issuer is not self- beyond the first trusted issuer, when that issuer is not self-
signed. signed.
o In Section 6, we recommend that DANE application protocols specify o In Section 7, we recommend that DANE application protocols specify
that when possible securely CNAME expanded names be used to derive that when possible securely CNAME expanded names be used to derive
the TLSA base domain. the TLSA base domain.
o In Section 7, we specify a strategy for managing TLSA records that o In Section 8, we specify a strategy for managing TLSA records that
interoperates with DANE clients regardless of what subset of the interoperates with DANE clients regardless of what subset of the
possible TLSA record types (combinations of TLSA parameters) is possible TLSA record types (combinations of TLSA parameters) is
supported by the client. supported by the client.
o In Section 8, we propose a digest algorithm agility protocol. o In Section 9, we propose a digest algorithm agility protocol.
[Note: This section does not yet represent the rough consensus of [Note: This section does not yet represent the rough consensus of
the DANE working group and requires further discussion. Perhaps the DANE working group and requires further discussion. Perhaps
this belongs in a separate document.] this belongs in a separate document.]
o In Section 9.1 we recommend against the use of Full(0) TLSA o In Section 10.1 we recommend against the use of Full(0) TLSA
records, as digest records are generally much more compact. records, as digest records are generally much more compact.
13. Security Considerations 13. Operational Considerations
The DNS time-to-live (TTL) of TLSA records needs to be chosen with
care. When an unplanned change in the server's certificate chain and
TLSA RRset is required, such as when keys are compromised or lost,
clients that cache stale TLSA records will fail to validate the
certificate chain of the updated server. TLSA RRsets should have
TTLs that are short enough to limit unplanned service disruption to
an acceptable duration. For example, TLSA records for SMTP servers
with a TTL of approximately an hour are likely sufficiently short.
For interactive HTTP services, TLSA record TTLs of approximately 5
minutes may be more appropriate.
The signature validity time for TLSA records should also not be too
long. Signed DNSSEC records can be replayed by an MiTM attacker
provided the signatures have not yet expired. Shorter signature
validity intervals allow for faster invalidation of compromised keys.
14. Security Considerations
Application protocols that cannot make use of the existing public CA Application protocols that cannot make use of the existing public CA
PKI (so called non-PKIX protocols), may choose not to implement PKI (so called non-PKIX protocols), may choose not to implement
certain PKIX-dependent TLSA record types defined in [RFC6698]. If certain PKIX-dependent TLSA record types defined in [RFC6698]. If
such records are published despite not being supported by the such records are published despite not being supported by the
application protocol, they are treated as "unusable". When TLS is application protocol, they are treated as "unusable". When TLS is
opportunistic, the client may proceed to use the server with opportunistic, the client may proceed to use the server with
mandatory unauthenticated TLS. This is stronger than opportunistic mandatory unauthenticated TLS. This is stronger than opportunistic
TLS without DANE, since in that case the client may also proceed with TLS without DANE, since in that case the client may also proceed with
a plaintext connection. When TLS is not opportunistic, the client a plaintext connection. When TLS is not opportunistic, the client
MUST NOT connect to the server. MUST NOT connect to the server.
Therefore, when TLSA records are used with protocols where PKIX does Therefore, when TLSA records are used with protocols where PKIX does
not apply, the recommended policy is for servers to not publish PKIX- not apply, the recommended policy is for servers to not publish PKIX-
dependent TLSA records, and for opportunistic TLS clients to use them dependent TLSA records, and for opportunistic TLS clients to use them
to enforce the use of (albeit unauthenticated) TLS, but otherwise to enforce the use of (albeit unauthenticated) TLS, but otherwise
treat them as unusable. Of course, when PKIX validation is supported treat them as unusable. Of course, when PKIX validation is supported
by the application protocol, clients SHOULD perform PKIX validation by the application protocol, clients SHOULD perform PKIX validation
per [RFC6698]. per [RFC6698].
14. IANA Considerations 15. IANA Considerations
This specification requires no support from IANA. This specification requires no support from IANA.
15. Acknowledgements 16. Acknowledgements
The authors would like to thank Phil Pennock for his comments and The authors would like to thank Phil Pennock for his comments and
advice on this document. advice on this document.
Acknowledgments from Viktor: Thanks to Tony Finch who finally prodded Acknowledgments from Viktor: Thanks to Tony Finch who finally prodded
me into participating in DANE working group discussions. Thanks to me into participating in DANE working group discussions. Thanks to
Paul Hoffman who motivated me to produce this memo and provided Paul Hoffman who motivated me to produce this memo and provided
feedback on early drafts. Thanks also to Samuel Dukhovni for feedback on early drafts. Thanks also to Samuel Dukhovni for
editorial assistance. editorial assistance.
16. References 17. References
16.1. Normative References 17.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005. 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
skipping to change at page 28, line 9 skipping to change at page 28, line 22
Security Version 1.2", RFC 6347, January 2012. Security Version 1.2", RFC 6347, January 2012.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS) of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, August 2012. Protocol: TLSA", RFC 6698, August 2012.
[RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify
Conversations about DNS-Based Authentication of Named Conversations about DNS-Based Authentication of Named
Entities (DANE)", RFC 7218, April 2014. Entities (DANE)", RFC 7218, April 2014.
16.2. Informative References 17.2. Informative References
[I-D.dukhovni-opportunistic-security] [I-D.dukhovni-opportunistic-security]
Dukhovni, V., "Opportunistic Security: Some Protection Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", draft-dukhovni-opportunistic- Most of the Time", draft-dukhovni-opportunistic-
security-03 (work in progress), August 2014. security-04 (work in progress), August 2014.
[I-D.ietf-dane-smtp-with-dane] [I-D.ietf-dane-smtp-with-dane]
Dukhovni, V. and W. Hardaker, "SMTP security via Dukhovni, V. and W. Hardaker, "SMTP security via
opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-11 opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-12
(work in progress), August 2014. (work in progress), August 2014.
[I-D.ietf-dane-srv] [I-D.ietf-dane-srv]
Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-
Based Authentication of Named Entities (DANE) TLSA Records Based Authentication of Named Entities (DANE) TLSA Records
with SRV Records", draft-ietf-dane-srv-07 (work in with SRV Records", draft-ietf-dane-srv-08 (work in
progress), July 2014. progress), October 2014.
[I-D.ietf-tls-oob-pubkey] [I-D.ietf-tls-oob-pubkey]
Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and
T. Kivinen, "Using Raw Public Keys in Transport Layer T. Kivinen, "Using Raw Public Keys in Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", draft-ietf-tls-oob-pubkey-11 (work in progress), (DTLS)", draft-ietf-tls-oob-pubkey-11 (work in progress),
January 2014. January 2014.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, June 2013. Transparency", RFC 6962, June 2013.
 End of changes. 75 change blocks. 
222 lines changed or deleted 250 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/