draft-ietf-tls-dnssec-chain-extension-05.txt   draft-ietf-tls-dnssec-chain-extension-06.txt 
TLS M. Shore TLS M. Shore
Internet-Draft Fastly Internet-Draft Fastly
Intended status: Standards Track R. Barnes Intended status: Standards Track R. Barnes
Expires: May 2, 2018 Mozilla Expires: July 27, 2018 Mozilla
S. Huque S. Huque
Salesforce Salesforce
W. Toorop W. Toorop
NLnet Labs NLnet Labs
October 29, 2017 January 23, 2018
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-05 draft-ietf-tls-dnssec-chain-extension-06
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
without needing to perform additional DNS record lookups. It will without needing to perform additional DNS record lookups. It will
typically not be used for general DNSSEC validation of TLS endpoint typically not be used for general DNSSEC validation of TLS endpoint
names. 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 May 2, 2018. This Internet-Draft will expire on July 27, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 32 skipping to change at page 2, line 32
5. Caching and Regeneration of the Authentication Chain . . . . 8 5. Caching and Regeneration of the Authentication Chain . . . . 8
6. Verification . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Verification . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Trust Anchor Maintenance . . . . . . . . . . . . . . . . . . 9 7. Trust Anchor Maintenance . . . . . . . . . . . . . . . . . . 9
8. Mandating use of this extension . . . . . . . . . . . . . . . 9 8. Mandating use of this extension . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
12.1. Normative References . . . . . . . . . . . . . . . . . . 10 12.1. Normative References . . . . . . . . . . . . . . . . . . 10
12.2. Informative References . . . . . . . . . . . . . . . . . 11 12.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Updates from -01 and -02 . . . . . . . . . . . . . . 13 Appendix A. Updates from -01 and -02 . . . . . . . . . . . . . . 12
Appendix B. Updates from -01 . . . . . . . . . . . . . . . . . . 13 Appendix B. Updates from -01 . . . . . . . . . . . . . . . . . . 12
Appendix C. Updates from -00 . . . . . . . . . . . . . . . . . . 13 Appendix C. Updates from -00 . . . . . . . . . . . . . . . . . . 12
Appendix D. Test vectors . . . . . . . . . . . . . . . . . . . . 13 Appendix D. Test vectors . . . . . . . . . . . . . . . . . . . . 13
D.1. _443._tcp.www.example.com . . . . . . . . . . . . . . . . 15 D.1. _443._tcp.www.example.com . . . . . . . . . . . . . . . . 14
D.2. _25._tcp.example.com wildcard . . . . . . . . . . . . . . 17 D.2. _25._tcp.example.com wildcard . . . . . . . . . . . . . . 16
D.3. _443._tcp.www.example.org CNAME . . . . . . . . . . . . . 19 D.3. _443._tcp.www.example.org CNAME . . . . . . . . . . . . . 17
D.4. _443._tcp.www.example.net DNAME . . . . . . . . . . . . . 21 D.4. _443._tcp.www.example.net DNAME . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
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 8, line 44 skipping to change at page 8, line 49
6. Verification 6. Verification
A TLS client making use of this specification, and which receives a A TLS client making use of this specification, and which receives a
DNSSEC authentication chain extension from a server, SHOULD use this DNSSEC authentication chain extension from a server, SHOULD use this
information to perform DANE authentication of the server. In order information to perform DANE authentication of the server. In order
to do this, it uses the mechanism specified by the DNSSEC protocol to do this, it uses the mechanism specified by the DNSSEC protocol
[RFC4035] [RFC5155]. This mechanism is sometimes implemented in a [RFC4035] [RFC5155]. This mechanism is sometimes implemented in a
DNSSEC validation engine or library. DNSSEC validation engine or library.
If the authentication chain is correctly verified, the client then
performs DANE authentication of the server according to the DANE TLS
protocol [RFC6698] [RFC7671].
Clients MAY cache the server's validated TLS RRset or other validated Clients MAY cache the server's validated TLS RRset or other validated
portions of the chain as an optimization to save signature portions of the chain as an optimization to save signature
verification work for future connections. The period of such caching verification work for future connections. The period of such caching
MUST NOT exceed the TTL associated with those records. MUST NOT exceed the TTL associated with those records.
7. Trust Anchor Maintenance 7. Trust Anchor Maintenance
The trust anchor may change periodically, e.g. when the operator of The trust anchor may change periodically, e.g. when the operator of
the trust anchor zone performs a DNSSEC key rollover. TLS clients the trust anchor zone performs a DNSSEC key rollover. TLS clients
using this specification MUST implement a mechanism to keep their using this specification MUST implement a mechanism to keep their
skipping to change at page 10, line 17 skipping to change at page 10, line 17
The security considerations of the normatively referenced RFCs all The security considerations of the normatively referenced RFCs all
pertain to this extension. Since the server is delivering a chain of pertain to this extension. Since the server is delivering a chain of
DNS records and signatures to the client, it MUST rebuild the chain DNS records and signatures to the client, it MUST rebuild the chain
in accordance with TTL and signature expiration of the chain in accordance with TTL and signature expiration of the chain
components as described in Section 5. TLS clients need roughly components as described in Section 5. TLS clients need roughly
accurate time in order to properly authenticate these signatures. accurate time in order to properly authenticate these signatures.
This could be achieved by running a time synchronization protocol This could be achieved by running a time synchronization protocol
like NTP [RFC5905] or SNTP [RFC5905], which are already widely used like NTP [RFC5905] or SNTP [RFC5905], which are already widely used
today. TLS clients MUST support a mechanism to track and rollover today. TLS clients MUST support a mechanism to track and rollover
the trust anchor key, or be able to avail themselves of a service the trust anchor key, or be able to avail themselves of a service
that does this, as described in Section 7. that does this, as described in Section 7. Security considerations
related to mandating the use of this extension are described in
Section 8.
10. IANA Considerations 10. IANA Considerations
This extension requires the registration of a new value in the TLS This extension requires the registration of a new value in the TLS
ExtensionsType registry. The value requested from IANA is 53. If ExtensionsType registry. The value requested from IANA is 53. If
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
skipping to change at page 10, line 41 skipping to change at page 10, line 43
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, Rick van Rein, Ilari Liusvaara, Gowri Visweswaran, Duane McManus, Rick van Rein, Ilari Liusvaara, Gowri Visweswaran, Duane
Wessels, Nico Williams, and Paul Wouters. Wessels, Nico 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, November 1987.
November 1987, <https://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
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119, March 1997.
DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>.
[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",
RFC 4034, DOI 10.17487/RFC4034, March 2005, RFC 4034, March 2005.
<https://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, Extensions", RFC 4035, March 2005.
<https://www.rfc-editor.org/info/rfc4035>.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, Existence", RFC 5155, March 2008.
<https://www.rfc-editor.org/info/rfc5155>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246, August 2008.
DOI 10.17487/RFC5246, August 2008, <https://www.rfc-
editor.org/info/rfc5246>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
Extensions: Extension Definitions", RFC 6066, Extension Definitions", RFC 6066, January 2011.
DOI 10.17487/RFC6066, January 2011, <https://www.rfc-
editor.org/info/rfc6066>.
[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, DOI 10.17487/RFC6698, August Protocol: TLSA", RFC 6698, August 2012.
2012, <https://www.rfc-editor.org/info/rfc6698>.
[RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based
Authentication of Named Entities (DANE) Protocol: Updates Authentication of Named Entities (DANE) Protocol: Updates
and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671,
October 2015, <https://www.rfc-editor.org/info/rfc7671>. October 2015, <http://www.rfc-editor.org/info/rfc7671>.
12.2. Informative References 12.2. Informative References
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, Trust Anchors", STD 74, RFC 5011, September 2007.
September 2007, <https://www.rfc-editor.org/info/rfc5011>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
"Network Time Protocol Version 4: Protocol and Algorithms Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, June 2010.
<https://www.rfc-editor.org/info/rfc5905>.
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January Points", BCP 100, RFC 7120, January 2014.
2014, <https://www.rfc-editor.org/info/rfc7120>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., [RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and
Weiler, S., and T. Kivinen, "Using Raw Public Keys in T. Kivinen, "Using Raw Public Keys in Transport Layer
Transport Layer Security (TLS) and Datagram Transport Security (TLS) and Datagram Transport Layer Security
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, (DTLS)", RFC 7250, June 2014.
June 2014, <https://www.rfc-editor.org/info/rfc7250>.
[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, (DANE) Transport Layer Security (TLS)", RFC 7672, DOI
DOI 10.17487/RFC7672, October 2015, <https://www.rfc- 10.17487/RFC7672, October 2015,
editor.org/info/rfc7672>. <http://www.rfc-editor.org/info/rfc7672>.
[RFC7901] Wouters, P., "CHAIN Query Requests in DNS", RFC 7901, [RFC7901] Wouters, P., "CHAIN Query Requests in DNS", RFC 7901, DOI
DOI 10.17487/RFC7901, June 2016, <https://www.rfc- 10.17487/RFC7901, June 2016,
editor.org/info/rfc7901>. <http://www.rfc-editor.org/info/rfc7901>.
[I-D.agl-dane-serializechain] [I-D.agl-dane-serializechain]
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
skipping to change at page 13, line 24 skipping to change at page 12, line 39
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 C. 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 D. Test vectors Appendix D. Test vectors
The provided test vectors will authenticate the certificate used with The provided test vectors will authenticate the certificate used with
https://example.com/, https://example.net/ and https://example.org/ https://example.com/, https://example.net/ and https://example.org/
 End of changes. 26 change blocks. 
56 lines changed or deleted 46 lines changed or added

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