draft-ietf-tls-dnssec-chain-extension-02.txt   draft-ietf-tls-dnssec-chain-extension-03.txt 
TLS M. Shore TLS M. Shore
Internet-Draft No Mountain Software Internet-Draft Fastly
Intended status: Standards Track R. Barnes Intended status: Standards Track R. Barnes
Expires: July 15, 2017 Mozilla Expires: September 28, 2017 Mozilla
S. Huque S. Huque
Verisign Labs Salesforce
W. Toorop W. Toorop
NLNet Labs NLNet Labs
January 11, 2017 March 27, 2017
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-02 draft-ietf-tls-dnssec-chain-extension-03
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 July 15, 2017. This Internet-Draft will expire on September 28, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 22 skipping to change at page 2, line 22
Table of Contents Table of Contents
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, TLS 1.2 . . . . . . . . . . . . . . . . . . . . 4 3.1. Protocol, TLS 1.2 . . . . . . . . . . . . . . . . . . . . 4
3.2. Protocol, TLS 1.3 . . . . . . . . . . . . . . . . . . . . 4 3.2. Protocol, TLS 1.3 . . . . . . . . . . . . . . . . . . . . 4
3.3. Raw Public Keys . . . . . . . . . . . . . . . . . . . . . 4 3.3. Raw Public Keys . . . . . . . . . . . . . . . . . . . . . 4
3.4. DNSSEC Authentication Chain Data . . . . . . . . . . . . 5 3.4. DNSSEC Authentication Chain Data . . . . . . . . . . . . 5
4. Construction of Serialized Authentication Chains . . . . . . 8 4. Construction of Serialized Authentication Chains . . . . . . 8
5. Caching and Regeneration of the Authentication Chain . . . . 8 5. Caching and Regeneration of the Authentication Chain . . . . 9
6. Verification . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Verification . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Trust Anchor Maintenance . . . . . . . . . . . . . . . . . . 9 7. Trust Anchor Maintenance . . . . . . . . . . . . . . . . . . 10
8. Mandating use of this extension . . . . . . . . . . . . . . . 9 8. Mandating use of this extension . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.1. Normative References . . . . . . . . . . . . . . . . . . 10 12.1. Normative References . . . . . . . . . . . . . . . . . . 11
12.2. Informative References . . . . . . . . . . . . . . . . . 11 12.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Updates from -01 . . . . . . . . . . . . . . . . . . 13 Appendix A. Updates from -01 and -02 . . . . . . . . . . . . . . 14
Appendix B. Updates from -00 . . . . . . . . . . . . . . . . . . 13 Appendix B. Updates from -01 . . . . . . . . . . . . . . . . . . 14
Appendix C. Test vector . . . . . . . . . . . . . . . . . . . . 13 Appendix C. Updates from -00 . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Appendix D. Test vector . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
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
skipping to change at page 3, line 25 skipping to change at page 3, line 26
For example, SMTP MTAs are usually located in data centers, may For example, SMTP MTAs are usually located in data centers, may
tolerate extra DNS lookup latency, are on servers where it is easier tolerate extra DNS lookup latency, are on servers where it is easier
to 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 ClientHello message that the DNS authentication chain be returned in
the (extended) server hello message. If the server is configured for the (extended) ServerHello 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 [I-D.agl-dane-serializechain]. It X.509 certificate extension [I-D.agl-dane-serializechain]. It
skipping to change at page 4, line 10 skipping to change at page 4, line 10
applies to the DANE authentication of X.509 certificates. Other applies to the DANE authentication of X.509 certificates. Other
credentials may be supported, as needed, in the future. credentials may be supported, as needed, in the future.
3. DNSSEC Authentication Chain Extension 3. DNSSEC Authentication Chain Extension
3.1. Protocol, TLS 1.2 3.1. Protocol, TLS 1.2
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 ClientHello, and
which are capable of being authenticated via DANE, MAY 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 an using the format described below. If a server is unable to return an
authentication chain, or does not wish to return an 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 A client must not be able to force a server to perform lookups on
arbitrary domain names using this mechanism. Therefore, a server arbitrary domain names using this mechanism. Therefore, a server
MUST NOT construct chains for domain names other than its own. MUST NOT construct chains for domain names other than its own.
3.2. Protocol, TLS 1.3 3.2. Protocol, TLS 1.3
A client MAY include an extension of type "dnssec_chain" in the A client MAY include an extension of type "dnssec_chain" in the
ClientHello. The "extension_data" field of this extension MUST be ClientHello. The "extension_data" field of this extension MUST be
empty. empty.
Servers receiving a "dnssec_chain" extension in the client hello, and Servers receiving a "dnssec_chain" extension in the ClientHello, and
which are capable of being authenticated via DANE, SHOULD return a which are capable of being authenticated via DANE, SHOULD return a
serialized authentication chain in the Certificate message, using the serialized authentication chain in the Certificate message associated
format described below. The authentication chain will be an with the end entity certificate being validated, using the format
extension to the certificate_list to which the certificate being described below. The authentication chain will be an extension to
authenticated belongs. the certificate_list to which the certificate being authenticated
belongs.
The extension protocol behavior otherwise follows that specified for The extension protocol behavior otherwise follows that specified for
TLS version 1.2. TLS version 1.2.
3.3. Raw Public Keys 3.3. Raw Public Keys
[RFC7250] specifies the use of raw public keys for both server and [RFC7250] specifies the use of raw public keys for both server and
client authentication in TLS 1.2. It points out that in cases where client authentication in TLS 1.2. It points out that in cases where
raw public keys are being used, code for certificate path validation raw public keys are being used, code for certificate path validation
is not required. However, DANE provides a mechanism for securely is not required. However, DANE, when used in conjunction with the
binding a raw public key to a named entity in the DNS, and when using dnssec_chain extension, provides a mechanism for securely binding a
DANE for authentication a raw key may be validated using a path raw public key to a named entity in the DNS, and when using DANE for
chaining back to a DNSSEC trust root. This has the added benefit of authentication a raw key may be validated using a path chaining back
mitigating an unknown key share attack, as described in to a DNSSEC trust root. This has the added benefit of mitigating an
[I-D.barnes-dane-uks]. unknown key share attack, as described in [I-D.barnes-dane-uks],
since it effectively augments the raw public key with the server's
name and provides a means to commit both the server and the client to
using that binding.
The UKS attack is possible in situations in which the association
between a domain name and a public key is not tightly bound, as in
the case in DANE in which a client either ignores the name in
certificate (as specified in [RFC7671] or there is no attestation of
trust outside of the DNS. The vulnerability arises in the following
situations:
o If the client does not verify the identity in the server's
certificate (as recommended in Section 5.1 of [RFC7671]), then an
attacker can induce the client to accept an unintended identity
for the server,
o If the client allows the use of raw public keys in TLS, then it
will not receive any indication of the server's identity in the
TLS channel, and is thus unable to check that the server's
identity is as intended.
The mechanism for conveying DNSSEC validation chains described in
this document results in a commitment by both parties, via the TLS
handshake, to a domain name which has been validated as belonging to
the owner name.
The mechanism for encoding DNSSEC authentication chains in a TLS The mechanism for encoding DNSSEC authentication chains in a TLS
extension, as described in this document, is not limited to public extension, as described in this document, is not limited to public
keys encapsulated in PKIX or X.509 containers but MAY be applied to keys encapsulated in X.509 containers but MAY be applied to raw
raw public keys and other representations, as well. public keys and other representations, as well.
3.4. DNSSEC Authentication Chain Data 3.4. 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
skipping to change at page 8, line 20 skipping to change at page 9, line 9
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
Name Indication extension [RFC6066] when present. If the Server Name server_name extension [RFC6066] when present. If the server_name
Indication extension is not present, or if the server does not extension is not present, or if the server does not recognize the
recognize the provided name and wishes to proceed with the handshake provided name and wishes to proceed with the handshake rather than to
rather than to abort the connection, the server uses the domain name abort the connection, the server uses the domain name associated with
associated with the server IP address to which the connection has the server IP address to which the connection has been established.
been established.
The TLSA record to be queried is constructed by prepending the _port The TLSA record to be queried is constructed by prepending the _port
and _transport labels to the domain name as described in [RFC6698], and _transport labels to the domain name as described in [RFC6698],
where "port" is the port number associated with the TLS server. The where "port" is the port number associated with the TLS server. The
transport is "tcp" for TLS servers, and "udp" for DTLS servers. The transport is "tcp" for TLS servers, and "udp" for DTLS servers. The
port number label is the left-most label, followed by the transport, port number label is the left-most label, followed by the transport,
followed by the base domain name. followed by the base domain name.
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
skipping to change at page 13, line 5 skipping to change at page 14, line 5
Langley, A., "Serializing DNS Records with DNSSEC Langley, A., "Serializing DNS Records with DNSSEC
Authentication", draft-agl-dane-serializechain-01 (work in Authentication", draft-agl-dane-serializechain-01 (work in
progress), July 2011. progress), July 2011.
[I-D.barnes-dane-uks] [I-D.barnes-dane-uks]
Barnes, R., Thomson, M., and E. Rescorla, "Unknown Key- Barnes, R., Thomson, M., and E. Rescorla, "Unknown Key-
Share Attacks on DNS-based Authentications of Named Share Attacks on DNS-based Authentications of Named
Entities (DANE)", draft-barnes-dane-uks-00 (work in Entities (DANE)", draft-barnes-dane-uks-00 (work in
progress), October 2016. progress), October 2016.
Appendix A. Updates from -01 Appendix A. Updates from -01 and -02
o Editorial updates for style and consistency
o Updated discussion of UKS attack
Appendix B. Updates from -01
o Added TLS 1.3 support o Added TLS 1.3 support
o Added section describing applicability to raw public keys o Added section describing applicability to raw public keys
o Softened language about record order o Softened language about record order
Appendix B. Updates from -00 Appendix C. Updates from -00
o Edits based on comments from Rick van Rein o Edits based on comments from Rick van Rein
o Warning about not overloading X.509 wildcards on DNSSEC wildcards o Warning about not overloading X.509 wildcards on DNSSEC wildcards
(from V. Dukhovny) (from V. Dukhovny)
o Added MUST include negative proof on 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 o Removed "TODO" on allowing the server to deliver only one
signature per RRset signature per RRset
o Added additional minor edits suggested by Viktor Dukhovny o Added additional minor edits suggested by Viktor Dukhovny
Appendix C. Test vector Appendix D. Test vector
[data go here] [data go here]
Authors' Addresses Authors' Addresses
Melinda Shore Melinda Shore
No Mountain Software Fastly
EMail: melinda.shore@nomountain.net EMail: mshore@fastly.com
Richard Barnes Richard Barnes
Mozilla Mozilla
EMail: rlb@ipv.sx EMail: rlb@ipv.sx
Shumon Huque Shumon Huque
Verisign Labs Salesforce
EMail: shumon.huque@gmail.com
EMail: shuque@verisign.com
Willem Toorop Willem Toorop
NLNet Labs NLNet Labs
EMail: willem@nlnetlabs.nl EMail: willem@nlnetlabs.nl
 End of changes. 23 change blocks. 
50 lines changed or deleted 82 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/