draft-ietf-tls-dnssec-chain-extension-00.txt   draft-ietf-tls-dnssec-chain-extension-01.txt 
TLS M. Shore TLS M. Shore
Internet-Draft No Mountain Software Internet-Draft No Mountain Software
Intended status: Standards Track R. Barnes Intended status: Standards Track R. Barnes
Expires: December 6, 2016 Mozilla Expires: January 8, 2017 Mozilla
S. Huque S. Huque
Verisign Labs Verisign Labs
W. Toorop W. Toorop
NLNet Labs NLNet Labs
June 4, 2016 July 7, 2016
A DANE Record and DNSSEC Authentication Chain Extension for TLS A DANE Record and DNSSEC Authentication Chain Extension for TLS
draft-ietf-tls-dnssec-chain-extension-00 draft-ietf-tls-dnssec-chain-extension-01
Abstract Abstract
This draft describes a new TLS extension for transport of a DNS This draft describes a new TLS extension for transport of a DNS
record set serialized with the DNSSEC signatures needed to record set serialized with the DNSSEC signatures needed to
authenticate that record set. The intent of this proposal is to authenticate that record set. The intent of this proposal is to
allow TLS clients to perform DANE authentication of a TLS server allow TLS clients to perform DANE authentication of a TLS server
certificate without needing to perform additional DNS record lookups. certificate without needing to perform additional DNS record lookups.
It will typically not be used for general DNSSEC validation of TLS It will typically not be used for general DNSSEC validation of TLS
endpoint names. endpoint names.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 December 6, 2016. This Internet-Draft will expire on January 8, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 24 skipping to change at page 2, line 24
1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. DNSSEC Authentication Chain Extension . . . . . . . . . . . . 3 3. DNSSEC Authentication Chain Extension . . . . . . . . . . . . 3
3.1. Protocol . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Protocol . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. DNSSEC Authentication Chain Data . . . . . . . . . . . . 4 3.2. DNSSEC Authentication Chain Data . . . . . . . . . . . . 4
4. Construction of Serialized Authentication Chains . . . . . . 7 4. Construction of Serialized Authentication Chains . . . . . . 7
5. Caching and Regeneration of the Authentication Chain . . . . 7 5. Caching and Regeneration of the Authentication Chain . . . . 7
6. Verification . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Verification . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Trust Anchor Maintenance . . . . . . . . . . . . . . . . . . 8 7. Trust Anchor Maintenance . . . . . . . . . . . . . . . . . . 8
8. Mandating use of this extension . . . . . . . . . . . . . . . 8 8. Mandating use of this extension . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
12.1. Normative References . . . . . . . . . . . . . . . . . . 9 12.1. Normative References . . . . . . . . . . . . . . . . . . 9
12.2. Informative References . . . . . . . . . . . . . . . . . 10 12.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Pseudocode example . . . . . . . . . . . . . . . . . 12 Appendix A. Updates from -00 . . . . . . . . . . . . . . . . . . 12
Appendix B. Test vector . . . . . . . . . . . . . . . . . . . . 12 Appendix B. Test vector . . . . . . . . . . . . . . . . . . . . 12
1. Requirements Notation 1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
This draft describes a new TLS [RFC5246] extension for transport of a This draft describes a new TLS [RFC5246] extension for transport of a
DNS record set serialized with the DNSSEC signatures [RFC4034] needed DNS record set serialized with the DNSSEC signatures [RFC4034] needed
to authenticate that record set. The intent of this proposal is to to authenticate that record set. The intent of this proposal is to
allow TLS clients to perform DANE authentication [RFC6698] of a TLS allow TLS clients to perform DANE authentication [RFC6698] of a TLS
server certificate without performing perform additional DNS record server certificate without performing additional DNS record lookups
lookups and incurring the associated latency penalty. It also and incurring the associated latency penalty. It also provides the
provides the ability to avoid potential problems with TLS clients ability to avoid potential problems with TLS clients being unable to
being unable to look up DANE records because of an interfering or look up DANE records because of an interfering or broken middlebox on
broken middlebox on the path between the endpoint and a DNS server. the path between the client and a DNS server. And lastly, it allows
And lastly, it allows a TLS client to validate DANE records itself a TLS client to validate DANE records itself without necessarily
without needing access to a validating DNS resolver to which it has a needing access to a validating DNS resolver to which it has a secure
secure connection. It will typically not be used for general DNSSEC connection. It will typically not be used for general DNSSEC
validation of endpoint names, but is more appropriate for validation validation of endpoint names, but is more appropriate for validation
of DANE TLSA records. of DANE TLSA records.
This mechanism is useful for TLS applications that need to address This mechanism is useful for TLS applications that need to address
the problems described above, typically web browsers or VoIP and XMPP the problems described above, typically web browsers or VoIP and XMPP
services. It may not be relevant for many other applications. For applications. It may not be relevant for many other applications.
example, SMTP MTAs are usually located in data centers, may tolerate For example, SMTP MTAs are usually located in data centers, may
extra DNS lookup latency, are on servers where it is easier to tolerate extra DNS lookup latency, are on servers where it is easier
provision a validating resolver, or are less likely to experience to provision a validating resolver, or are less likely to experience
traffic interference from misconfigured middleboxes. Furthermore, traffic interference from misconfigured middleboxes. Furthermore,
SMTP MTAs usually employ Opportunistic Security [RFC7435], in which SMTP MTAs usually employ Opportunistic Security [RFC7435], in which
the presence of the DNS TLSA records is used to determine whether to the presence of the DNS TLSA records is used to determine whether to
enforce an authenticated TLS connection. Hence DANE authentication enforce an authenticated TLS connection. Hence DANE authentication
of SMTP MTAs [RFC7672] will typically not use this mechanism. of SMTP MTAs [RFC7672] will typically not use this mechanism.
The extension described here allows a TLS client to request in the The extension described here allows a TLS client to request in the
client hello message that the DNS authentication chain be returned in client hello message that the DNS authentication chain be returned in
the (extended) server hello message. If the server is configured for the (extended) server hello message. If the server is configured for
DANE authentication, then it performs the appropriate DNS queries, DANE authentication, then it performs the appropriate DNS queries,
builds the authentication chain, and returns it to the client. The builds the authentication chain, and returns it to the client. The
server will usually use a previously cached authentication chain, but server will usually use a previously cached authentication chain, but
it will need to rebuild it periodically as described in Section 5. it will need to rebuild it periodically as described in Section 5.
The client then authenticates the chain using a pre-configured trust The client then authenticates the chain using a pre-configured trust
anchor. anchor.
This specification is based on Adam Langley's original proposal for This specification is based on Adam Langley's original proposal for
serializing DNSSEC authentication chains and delivering them in an serializing DNSSEC authentication chains and delivering them in an
X.509 certificate extension [AGL]. It modifies the approach by using X.509 certificate extension [I-D.agl-dane-serializechain]. It
wire format DNS records in the serialized data (assuming that the modifies the approach by using wire format DNS records in the
data will be prepared and consumed by a DNS-specific library), and by serialized data (assuming that the data will be prepared and consumed
using a TLS extension to deliver the data. by a DNS-specific library), and by using a TLS extension to deliver
the data.
3. DNSSEC Authentication Chain Extension 3. DNSSEC Authentication Chain Extension
3.1. Protocol 3.1. Protocol
A client MAY include an extension of type "dnssec_chain" in the A client MAY include an extension of type "dnssec_chain" in the
(extended) ClientHello. The "extension_data" field of this extension (extended) ClientHello. The "extension_data" field of this extension
MUST be empty. MUST be empty.
Servers receiving a "dnssec_chain" extension in the client hello, and Servers receiving a "dnssec_chain" extension in the client hello, and
which are capable of being authenticated via DANE, SHOULD return a which are capable of being authenticated via DANE, MAY return a
serialized authentication chain in the extended ServerHello message, serialized authentication chain in the extended ServerHello message,
using the format described below. If a server is unable to return a using the format described below. If a server is unable to return an
authentication chain, or does not wish to return a authentication authentication chain, or does not wish to return an authentication
chain, it does not include a dnssec_chain extension. As with all TLS chain, it does not include a dnssec_chain extension. As with all TLS
extensions, if the server does not support this extension it will not extensions, if the server does not support this extension it will not
return any authentication chain. return any authentication chain.
A client must not be able to force a server to perform lookups on
arbitrary domain names using this mechanism. Therefore, a server
MUST NOT construct chains for domain names other than its own.
3.2. DNSSEC Authentication Chain Data 3.2. DNSSEC Authentication Chain Data
The "extension_data" field of the "dnssec_chain" extension MUST The "extension_data" field of the "dnssec_chain" extension MUST
contain a DNSSEC Authentication Chain encoded in the following form: contain a DNSSEC Authentication Chain encoded in the following form:
opaque AuthenticationChain<0..2^16-1>; opaque AuthenticationChain<0..2^16-1>
The AuthenticationChain structure is composed of a sequence of The AuthenticationChain structure is composed of a sequence of
uncompressed wire format DNS resource record sets (RRset) and uncompressed wire format DNS resource record sets (RRset) and
corresponding signatures (RRsig) records. The record sets and corresponding signatures (RRsig) records. The record sets and
signatures are presented in validation order, starting at the target signatures are presented in validation order, starting at the target
DANE record, followed by the DNSKEY and DS record sets for each DANE record, followed by the DNSKEY and DS record sets for each
intervening DNS zone up to a trust anchor chosen by the server, intervening DNS zone up to a trust anchor chosen by the server,
typically the DNS root. typically the DNS root.
This sequence of native DNS wire format records enables easier This sequence of native DNS wire format records enables easier
generation of the data structure on the server and easier generation of the data structure on the server and easier
verification of the data on client by means of existing DNS library verification of the data on client by means of existing DNS library
functions. However this document describes the data structure in functions. However this document describes the data structure in
sufficient detail that implementers if they desire can write their sufficient detail that implementers if they desire can write their
own code to do this. own code to do this.
[TODO: mention that to reduce the size of the chain, the server can
deliver exactly one RRsig per RRset, namely the one used to validate
the chain as it is built.]
Each RRset in the chain is composed of a sequence of wire format DNS Each RRset in the chain is composed of a sequence of wire format DNS
resource records. The format of the resource record is described in resource records. The format of the resource record is described in
RFC 1035 [RFC1035], Section 3.2.1. The resource records SHOULD be RFC 1035 [RFC1035], Section 3.2.1. The resource records SHOULD be
presented in the canonical form and ordering as described in RFC 4034 presented in the canonical form and ordering as described in RFC 4034
[RFC4034]. [RFC4034].
RR(i) = owner | type | class | TTL | RDATA length | RDATA RR(i) = owner | type | class | TTL | RDATA length | RDATA
RRs within the RRset are ordered canonically, by treating the RDATA RRs within the RRset are ordered canonically, by treating the RDATA
portion of each RR as a left-justified unsigned octet sequence in portion of each RR as a left-justified unsigned octet sequence in
skipping to change at page 6, line 11 skipping to change at page 6, line 11
RRSIG(com. DS) RRSIG(com. DS)
. DNSKEY . DNSKEY
RRSIG(. DNSKEY) RRSIG(. DNSKEY)
Names that are aliased via CNAME and/or DNAME records may involve Names that are aliased via CNAME and/or DNAME records may involve
multiple branches of the DNS tree. In this case the authentication multiple branches of the DNS tree. In this case the authentication
chain structure will be composed of a sequence of these multiple chain structure will be composed of a sequence of these multiple
intersecting branches. DNAME chains should omit unsigned CNAME intersecting branches. DNAME chains should omit unsigned CNAME
records that may have been synthesized in the response from a DNS records that may have been synthesized in the response from a DNS
resolver. Wildcard DANE records will need to include the wildcard resolver. Wildcard DANE records will need to include the wildcard
name as well as a negative proof (i.e. NSEC or NSEC3 records) that name, and negative proof (i.e. NSEC or NSEC3 records) that no closer
no closer name exists. name exists MUST be included.
A CNAME example: A CNAME example:
_443._tcp.www.example.com. IN CNAME ca.example.net. _443._tcp.www.example.com. IN CNAME ca.example.net.
ca.example.net. IN TLSA 2 0 1 ... ca.example.net. IN TLSA 2 0 1 ...
Here the authentication chain structure is composed of two Here the authentication chain structure is composed of two
consecutive chains, one for _443._tcp.www.example.com/CNAME consecutive chains, one for _443._tcp.www.example.com/CNAME
and one for ca.example.net/TLSA. The second chain can omit and one for ca.example.net/TLSA. The second chain can omit
the record sets at the end that overlap with the first. the record sets at the end that overlap with the first.
skipping to change at page 7, line 5 skipping to change at page 7, line 5
RRSIG(ca.example.net. TLSA) RRSIG(ca.example.net. TLSA)
example.net. DNSKEY example.net. DNSKEY
RRSIG(example.net. DNSKEY) RRSIG(example.net. DNSKEY)
example.net. DS example.net. DS
RRSIG(example.net. DS) RRSIG(example.net. DS)
net. DNSKEY net. DNSKEY
RRSIG(net. DNSKEY) RRSIG(net. DNSKEY)
net. DS net. DS
RRSIG(net. DS) RRSIG(net. DS)
Note as well that if a user has a specific TLSA record for port 443,
and a different wildcard covering other ports, attackers MUST NOT be
able to substitute the wildcard TLSA RRset for the more specific one
for port 443. DNSSEC wildcards must not be confused with the X.509
wildcards.
4. Construction of Serialized Authentication Chains 4. Construction of Serialized Authentication Chains
This section describes a possible procedure for the server to use to This section describes a possible procedure for the server to use to
build the serialized DNSSEC chain. build the serialized DNSSEC chain.
When the goal is to perform DANE authentication [RFC6698] of the When the goal is to perform DANE authentication [RFC6698] of the
server's X.509 certificate, the DNS record set to be serialized is a server's X.509 certificate, the DNS record set to be serialized is a
TLSA record set corresponding to the server's domain name. TLSA record set corresponding to the server's domain name.
The domain name of the server MUST be that included in the TLS Server The domain name of the server MUST be that included in the TLS Server
skipping to change at page 7, line 38 skipping to change at page 7, line 44
The components of the authentication chain are built by starting at The components of the authentication chain are built by starting at
the target record set and its corresponding RRSIG. Then traversing the target record set and its corresponding RRSIG. Then traversing
the DNS tree upwards towards the trust anchor zone (normally the DNS the DNS tree upwards towards the trust anchor zone (normally the DNS
root), for each zone cut, the DNSKEY and DS RRsets and their root), for each zone cut, the DNSKEY and DS RRsets and their
signatures are added. If DNS responses messages contain any domain signatures are added. If DNS responses messages contain any domain
names utilizing name compression [RFC1035], then they must be names utilizing name compression [RFC1035], then they must be
uncompressed. uncompressed.
In the future, proposed DNS protocol enhancements, such as the EDNS In the future, proposed DNS protocol enhancements, such as the EDNS
Chain Query extension [CHAINQUERY] may offer easy ways to obtain all Chain Query extension [I-D.ietf-dnsop-edns-client-subnet] may offer
of the chain data in one transaction with an upstream DNSSEC aware easy ways to obtain all of the chain data in one transaction with an
recursive server. upstream DNSSEC aware recursive server.
5. Caching and Regeneration of the Authentication Chain 5. Caching and Regeneration of the Authentication Chain
DNS records have Time To Live (TTL) parameters, and DNSSEC signatures DNS records have Time To Live (TTL) parameters, and DNSSEC signatures
have validity periods (specifically signature expiration times). have validity periods (specifically signature expiration times).
After the TLS server constructs the serialized authentication chain, After the TLS server constructs the serialized authentication chain,
it SHOULD cache and reuse it in multiple TLS connection handshakes. it SHOULD cache and reuse it in multiple TLS connection handshakes.
However, it MUST refresh and rebuild the chain as TTLs and signature However, it MUST refresh and rebuild the chain as TTLs and signature
validity periods dictate. A server implementation could carefully validity periods dictate. A server implementation could carefully
track these parameters and requery component records in the chain track these parameters and requery component records in the chain
skipping to change at page 9, line 26 skipping to change at page 9, line 34
the draft is adopted by the WG, the authors expect to make an early the draft is adopted by the WG, the authors expect to make an early
allocation request as specified in [RFC7120]. allocation request as specified in [RFC7120].
11. Acknowledgments 11. Acknowledgments
Many thanks to Adam Langley for laying the groundwork for this Many thanks to Adam Langley for laying the groundwork for this
extension. The original idea is his but our acknowledgment in no way extension. The original idea is his but our acknowledgment in no way
implies his endorsement. This document also benefited from implies his endorsement. This document also benefited from
discussions with and review from the following people: Viktor discussions with and review from the following people: Viktor
Dukhovni, Daniel Kahn Gillmor, Jeff Hodges, Allison Mankin, Patrick Dukhovni, Daniel Kahn Gillmor, Jeff Hodges, Allison Mankin, Patrick
McManus, Gowri Visweswaran, Duane Wessels, Nico Williams, and Paul McManus, Rick van Rein, Gowri Visweswaran, Duane Wessels, Nico
Wouters. Williams, and Paul Wouters.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 11, line 5 skipping to change at page 11, line 15
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435, Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <http://www.rfc-editor.org/info/rfc7435>. December 2014, <http://www.rfc-editor.org/info/rfc7435>.
[RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via
Opportunistic DNS-Based Authentication of Named Entities Opportunistic DNS-Based Authentication of Named Entities
(DANE) Transport Layer Security (TLS)", RFC 7672, DOI (DANE) Transport Layer Security (TLS)", RFC 7672, DOI
10.17487/RFC7672, October 2015, 10.17487/RFC7672, October 2015,
<http://www.rfc-editor.org/info/rfc7672>. <http://www.rfc-editor.org/info/rfc7672>.
[AGL] Langley, A., "Serializing DNS Records with DNSSEC [I-D.agl-dane-serializechain]
Authentication", July 2011, <https://tools.ietf.org/id/ Langley, A., "Serializing DNS Records with DNSSEC
draft-agl-dane-serializechain-01.txt>. Authentication", draft-agl-dane-serializechain-01 (work in
progress), July 2011.
[CHAINQUERY] [I-D.ietf-dnsop-edns-client-subnet]
Wouters, P., "Chain Query Requests in DNS", Contavalli, C., Gaast, W., tale, t., and W. Kumari,
<https://tools.ietf.org/html/draft-ietf-dnsop-edns-chain- "Client Subnet in DNS Queries", draft-ietf-dnsop-edns-
query>. client-subnet-07 (work in progress), March 2016.
Appendix A. Pseudocode example Appendix A. Updates from -00
[code goes here] o Edits based on comments from Rick van Rein
o Warning about not overloading X.509 wildcards on DNSSEC wildcards
(from V. Dukhovny)
o Added MUST include negative proof on wildcards (from V. Dukhovny)
o Removed "TODO" on allowing the server to deliver only one
signature per RRset
o Added additional minor edits suggested by Viktor Dukhovny
Appendix B. Test vector Appendix B. Test vector
[data go here] [data go here]
Authors' Addresses Authors' Addresses
Melinda Shore Melinda Shore
No Mountain Software No Mountain Software
 End of changes. 22 change blocks. 
46 lines changed or deleted 64 lines changed or added

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