draft-ietf-tls-dnssec-chain-extension-04.txt   draft-ietf-tls-dnssec-chain-extension-05.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: December 3, 2017 Mozilla Expires: May 2, 2018 Mozilla
S. Huque S. Huque
Salesforce Salesforce
W. Toorop W. Toorop
NLNet Labs NLnet Labs
June 1, 2017 October 29, 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-04 draft-ietf-tls-dnssec-chain-extension-05
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 December 3, 2017. This Internet-Draft will expire on May 2, 2018.
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 26 skipping to change at page 2, line 26
3. DNSSEC Authentication Chain Extension . . . . . . . . . . . . 4 3. DNSSEC Authentication Chain Extension . . . . . . . . . . . . 4
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 . . . . . . 7 4. Construction of Serialized Authentication Chains . . . . . . 7
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 . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . 13
Appendix B. Updates from -01 . . . . . . . . . . . . . . . . . . 13 Appendix B. Updates from -01 . . . . . . . . . . . . . . . . . . 13
Appendix C. Updates from -00 . . . . . . . . . . . . . . . . . . 13 Appendix C. Updates from -00 . . . . . . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . . . . . 15
skipping to change at page 4, line 38 skipping to change at page 4, line 38
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 ClientHello, 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 associated serialized authentication chain in the extension block of the
with the end entity certificate being validated, using the format Certificate message containing the end entity certificate being
described below. The authentication chain will be an extension to validated, using the format described below.
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, when used in conjunction with the is not required. However, DANE, when used in conjunction with the
skipping to change at page 5, line 49 skipping to change at page 5, line 47
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
corresponding signatures (RRSIG) records. corresponding signatures (RRSIG) record sets.
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.
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.
presented in the canonical form and ordering as described in RFC 4034
[RFC4034].
RR(i) = owner | type | class | TTL | RDATA length | RDATA RR(i) = owner | type | class | TTL | RDATA length | RDATA
RRs within the RRset MAY be ordered canonically, by treating the Each RRset in the sequence is followed by its associated RRsig record
RDATA portion of each RR as a left-justified unsigned octet sequence set. The RRsig record wire format is described in RFC 4034
in which the absence of an octet sorts before a zero octet. [RFC4034], Section 3.1. The signature portion of the RDATA, as
Each RRset in the sequence is followed by its associated RRsig
record. The RRsig record is in DNS wire format as described in RFC
4034 [RFC4034], Section 3.1. The signature portion of the RDATA, as
described in the same section, is the following: described in the same section, is the following:
signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) signature = sign(RRSIG_RDATA | RR(1) | RR(2)... )
where RRSIG_RDATA is the wire format of the RRSIG RDATA fields with where RRSIG_RDATA is the wire format of the RRSIG RDATA fields with
the Signer's Name field in canonical form and the signature field the Signer's Name field in canonical form and the signature field
excluded. excluded.
The first RRset in the chain MUST contain the TLSA record set being The first RRset in the chain MUST contain the TLSA record set being
presented. However, if the owner name of the TLSA record set is an presented. However, if the owner name of the TLSA record set is an
skipping to change at page 8, line 48 skipping to change at page 8, line 41
the entire chain at some predefined periodic interval that does not the entire chain at some predefined periodic interval that does not
exceed the DNS TTLs or signature validity periods of the component exceed the DNS TTLs or signature validity periods of the component
records in the chain. records in the chain.
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]. This mechanism is sometimes implemented in a DNSSEC [RFC4035] [RFC5155]. This mechanism is sometimes implemented in a
validation engine or library. DNSSEC validation engine or library.
If the authentication chain is correctly verified, the client then Clients MAY cache the server's validated TLS RRset or other validated
performs DANE authentication of the server according to the DANE TLS portions of the chain as an optimization to save signature
protocol [RFC6698] [RFC7671]. verification work for future connections. The period of such caching
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
trust anchors up to date. They could use the method defined in trust anchors up to date. They could use the method defined in
[RFC5011] to perform trust anchor updates inband in TLS, by tracking [RFC5011] to perform trust anchor updates inband in TLS, by tracking
the introduction of new keys seen in the trust anchor DNSKEY RRset. the introduction of new keys seen in the trust anchor DNSKEY RRset.
However, alternative mechanisms external to TLS may also be utilized. However, alternative mechanisms external to TLS may also be utilized.
Some operating systems may have a system-wide service to maintain and Some operating systems may have a system-wide service to maintain and
keep the root trust anchor up to date. In such cases, the TLS client keep the root trust anchor up to date. In such cases, the TLS client
application could simply reference that as its trust anchor, application could simply reference that as its trust anchor,
periodically checking whether it has changed. Some applications may periodically checking whether it has changed. Some applications may
prefer to implement trust anchor updates as part of their automated prefer to implement trust anchor updates as part of their automated
software updates. software updates.
8. Mandating use of this extension 8. Mandating use of this extension
A TLS server certificate MAY mandate the use of this extension by Green field applications that are designed to always employ this
means of the X.509 TLS Feature Extension described in [RFC7633]. extension, could of course unconditionally mandate its use.
This X.509 certificate extension, when populated with the
dnssec_chain TLS extension identifier, indicates to the client that If TLS applications want to mandate the use of this extension for
the server must deliver the authentication chain when asked to do so. specific servers, clients could maintain a whitelist of sites where
(The X.509 TLS Feature Extension is the same mechanism used to the use of this extension is forced. The client would refuse to
deliver other mandatory signals, such as OCSP "must staple" authenticate such servers if they failed to deliver this extension.
assertions.) Mandating this extension for Raw Public Key Client applications could also employ a Trust on First Use (TOFU)
authentication (where there are no X.509 certificates) could employ like strategy, whereby they would record the fact that a server
configuration mechanisms external to the TLS protocol. offered the extension and use that knowledge to require it for
subsequent connections.
This protocol currently provides no way for a server to prove that it
doesn't have a TLSA record. Hence absent whitelists, a client
misdirected to a server that has fraudulently acquired a public CA
issued certificate for the real server's name, could be induced to
establish a PKIX verified connection to the rogue server that
precluded DANE authentication. This could be solved by enhancing
this protocol to require that servers without TLSA records need to
provide a DNSSEC authentication chain that proves this (i.e. the
chain includes NSEC or NSEC3 records that demonstrate either the
absence of the TLSA record, or the absence of a secure delegation to
the associated zone). Such an enhancement would be impossible to
deploy incrementally though since it requires all TLS servers to
support this protocol.
9. Security Considerations 9. Security Considerations
The security considerations of the normatively referenced RFCs (1035, The security considerations of the normatively referenced RFCs all
4034, 4035, 5246, 6066, 6698, 7633, 7671) all pertain to this pertain to this extension. Since the server is delivering a chain of
extension. Since the server is delivering a chain of DNS records and DNS records and signatures to the client, it MUST rebuild the chain
signatures to the client, it MUST rebuild the chain in accordance in accordance with TTL and signature expiration of the chain
with TTL and signature expiration of the chain components as components as described in Section 5. TLS clients need roughly
described in Section 5. TLS clients need roughly accurate time in accurate time in order to properly authenticate these signatures.
order to properly authenticate these signatures. This could be This could be achieved by running a time synchronization protocol
achieved by running a time synchronization protocol like NTP like NTP [RFC5905] or SNTP [RFC5905], which are already widely used
[RFC5905] or SNTP [RFC5905], which are already widely used today. today. TLS clients MUST support a mechanism to track and rollover
TLS clients MUST support a mechanism to track and rollover the trust the trust anchor key, or be able to avail themselves of a service
anchor key, or be able to avail themselves of a service that does that does this, as described in Section 7.
this, as described in Section 7.
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
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, Rick van Rein, Gowri Visweswaran, Duane Wessels, Nico McManus, Rick van Rein, Ilari Liusvaara, Gowri Visweswaran, Duane
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, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. 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,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc2119>. 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, DOI 10.17487/RFC4034, March 2005,
<http://www.rfc-editor.org/info/rfc4034>. <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, DOI 10.17487/RFC4035, March 2005,
<http://www.rfc-editor.org/info/rfc4035>. <https://www.rfc-editor.org/info/rfc4035>.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, DOI 10.17487/RFC5155, 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,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5246>. editor.org/info/rfc5246>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066, Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc6066>. 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, DOI 10.17487/RFC6698, August
2012, <http://www.rfc-editor.org/info/rfc6698>. 2012, <https://www.rfc-editor.org/info/rfc6698>.
[RFC7633] Hallam-Baker, P., "X.509v3 Transport Layer Security (TLS)
Feature Extension", RFC 7633, DOI 10.17487/RFC7633,
October 2015, <http://www.rfc-editor.org/info/rfc7633>.
[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, <http://www.rfc-editor.org/info/rfc7671>. October 2015, <https://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, DOI 10.17487/RFC5011,
September 2007, <http://www.rfc-editor.org/info/rfc5011>. 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., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<http://www.rfc-editor.org/info/rfc5905>. <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, DOI 10.17487/RFC7120, January
2014, <http://www.rfc-editor.org/info/rfc7120>. 2014, <https://www.rfc-editor.org/info/rfc7120>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <http://www.rfc-editor.org/info/rfc7250>. 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 10.17487/RFC7672, October 2015, DOI 10.17487/RFC7672, October 2015, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7672>. 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 10.17487/RFC7901, June 2016, DOI 10.17487/RFC7901, June 2016, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7901>. 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 23, line 10 skipping to change at page 23, line 10
Richard Barnes Richard Barnes
Mozilla Mozilla
EMail: rlb@ipv.sx EMail: rlb@ipv.sx
Shumon Huque Shumon Huque
Salesforce Salesforce
EMail: shuque@gmail.com EMail: shuque@gmail.com
Willem Toorop Willem Toorop
NLNet Labs NLnet Labs
EMail: willem@nlnetlabs.nl EMail: willem@nlnetlabs.nl
 End of changes. 29 change blocks. 
75 lines changed or deleted 83 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/