< draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt   draft-vandijk-dprive-ds-dot-signal-and-pin-01.txt >
dprive P. van Dijk dprive P. van Dijk
Internet-Draft PowerDNS Internet-Draft PowerDNS
Intended status: Standards Track R. Geuze Intended status: Standards Track R. Geuze
Expires: 20 November 2020 TransIP Expires: 14 January 2021 TransIP
E. Bretelle E. Bretelle
Facebook Facebook
19 May 2020 13 July 2020
Signalling Authoritative DoT support in DS records, with key pinning Signalling Authoritative DoT support in DS records, with key pinning
draft-vandijk-dprive-ds-dot-signal-and-pin-00 draft-vandijk-dprive-ds-dot-signal-and-pin-01
Abstract Abstract
This document specifies a way to signal the usage of DoT, and the This document specifies a way to signal the usage of DoT, and the
pinned keys for that DoT usage, in authoritative servers. This pinned keys for that DoT usage, in authoritative servers. This
signal lives on the parent side of delegations, in DS records. To signal lives on the parent side of delegations, in DS records. To
ensure easy deployment, the signal is defined in terms of (C)DNSKEY. ensure easy deployment, the signal is defined in terms of (C)DNSKEY.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 20 November 2020. This Internet-Draft will expire on 14 January 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Document work . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Document work . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Generating and placing the (C)DNSKEY/DS records . . . . . 4 5.1. Generating and placing the (C)DNSKEY/DS records . . . . . 5
6. Implementation . . . . . . . . . . . . . . . . . . . . . . . 5 6. Implementation . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Authoritative server changes . . . . . . . . . . . . . . 5 6.1. Authoritative server changes . . . . . . . . . . . . . . 6
6.2. Validating resolver changes . . . . . . . . . . . . . . . 6 6.2. Validating resolver changes . . . . . . . . . . . . . . . 7
6.3. Stub resolver changes . . . . . . . . . . . . . . . . . . 6 6.3. Stub resolver changes . . . . . . . . . . . . . . . . . . 8
6.4. Zone validator changes . . . . . . . . . . . . . . . . . 6 6.4. Zone validator changes . . . . . . . . . . . . . . . . . 8
6.5. Domain registry changes . . . . . . . . . . . . . . . . . 6 6.5. Domain registry changes . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 7 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 9
8.1. PoC . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. PoC . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9. Design Considerations . . . . . . . . . . . . . . . . . . . . 9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
11. Normative References . . . . . . . . . . . . . . . . . . . . 8 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
12. Informative References . . . . . . . . . . . . . . . . . . . 9 12. Normative References . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 13. Informative References . . . . . . . . . . . . . . . . . . . 12
Appendix A. Document history . . . . . . . . . . . . . . . . . . 13
A.1. Changes between -00 and -01 . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Even quite recently, DNS was a completely unencrypted protocol, with Even quite recently, DNS was a completely unencrypted protocol, with
no protection against snooping. In the past few years, this no protection against snooping. In the past few years, this
landscape has shifted. The connections between stubs and resolvers landscape has shifted. The connections between stubs and resolvers
are now often protected by DoT, DoH, or other protocols that provide are now often protected by DoT, DoH, or other protocols that provide
privacy. privacy.
This document introduces a way to signal, from the parent side of a This document introduces a way to signal, from the parent side of a
skipping to change at page 3, line 49 skipping to change at page 4, line 13
DNSKEY record as defined in [RFC4034] DNSKEY record as defined in [RFC4034]
4. Summary 4. Summary
To enable the signaling of DoT a new DNSKEY algorithm type TBD is To enable the signaling of DoT a new DNSKEY algorithm type TBD is
added. If a resolver with support for TBD encounters a DS record added. If a resolver with support for TBD encounters a DS record
with the DNSKEY algorithm type TBD it MUST connect to the with the DNSKEY algorithm type TBD it MUST connect to the
authoritative servers for this domain via DoT. It MUST use the authoritative servers for this domain via DoT. It MUST use the
hashes attached to the DS records with DNSKEY algorithm type TBD to hashes attached to the DS records with DNSKEY algorithm type TBD to
check whether the public key supplied by the authoritative nameserver check whether the public key supplied by the authoritative nameserver
is valid. If the DoT connection is unsuccessful or the public key during the TLS handshake is valid. If the DoT connection is
supplied the server does not match one of the DS digests, the unsuccessful or the public key supplied by the server does not match
resolver MUST NOT fall back to unencrypted Do53. any of the DS digests, the resolver MUST NOT fall back to unencrypted
Do53. For resolvers that are willing to probe for protocol support
(DNS over HTTPS, DNS over QUIC), a fallback to other encrypted
protocols is allowed if they can satisfy the key pin. This means
that if a DS for algo TBD is present, and no name servers satisfy the
pin requirement, the response returned to the client is SERVFAIL
because no name servers for the domain were available to answer the
questions.
The pseudo DNSKEY record MUST contain Base64 encoded ([RFC4648] 4.) A domain MAY have more than one DS record with DNSKEY algorithm TBD.
DER SubjectPublicKeyInfo as defined in [RFC5280] 4.1.2.7. Since the A resolver with support for TBD should then try to verify the public
cert provided by the TLS server over the wire is already DER encoded key supplied by the authoritative nameserver against every supplied
this makes for easy validation. The pseudo DNSKEY algorithm type TBD DS record. Multiple records can be used to support multiple DS
is algorithm agnostic, like the TLSA record, since the DER encoded digest types, multiple TLS key algorithms, different keys for each
data already contains information about the used algorithm. authoritative, and for key rollovers. In case of an algorithm or key
rollover the new DS record should be added to all served domains
before the new key is deployed on the authoritatives. To allow for
emergency rollovers, having a standby DS record for all domains with
a private key securely stored offline can be a valid strategy.
The pseudo DNSKEY record (when considered in wire format) MUST
contain the ([RFC4648] 4.) DER SubjectPublicKeyInfo as defined in
[RFC5280] 4.1.2.7. Since the cert provided by the TLS server over
the wire is already DER encoded this makes for easy validation. (In
the DNSKEY presentation format, the Public Key field contains the
Base64 encoding of the DER SPKI, which is equivalent to the SPKI in
PEM format minus the header and footer.) The pseudo DNSKEY algorithm
type TBD is algorithm agnostic, like the TLSA record, since the DER
encoded data already contains information about the used algorithm.
Algorithm support SHOULD be handled at the TLS handshake level, which Algorithm support SHOULD be handled at the TLS handshake level, which
means a DNS application SHOULD NOT need to be aware of the algorithm means a DNS application SHOULD NOT need to be aware of the algorithm
used by its TLS library. The pseudo DNSKEY record MUST NOT be used by its TLS library. The pseudo DNSKEY record MUST NOT be
present in the zone. The procedure for hashing the pseudo DNSKEY present in the zone. The procedure for hashing the pseudo DNSKEY
record is the same as for a normal DNSKEY as defined in RFC4034. record is the same as for a normal DNSKEY as defined in RFC4034
5.1.4.
As DNSKEY algorithm TBD is not meant to be used for Zone Signing, the
existing ZONE and SEP flags do not mean anything. This specification
statically defines the flags value as 257 for optimal compatibility
with existing registry operations.
The pseudo DNSKEY type can be used in CDNSKEY and CDS (as defined in The pseudo DNSKEY type can be used in CDNSKEY and CDS (as defined in
[RFC7344]) records. These records MAY be present in the zone. [RFC7344]) records. These records MAY be present in the zone.
For those familiar with TLSA ([RFC6698]), key matching for this For those familiar with TLSA ([RFC6698]), key matching for this
protocol is identical to that provided by "TLSA 3 1 0" for (C)DNSKEY. protocol is identical to that provided by "TLSA 3 1 0" for (C)DNSKEY.
For the DS case, key matching is similar to "TLSA 3 1 x" where x is For the DS case, key matching is similar to "TLSA 3 1 x" where x is
not zero, except that the rest of the (C)DNSKEY, including the owner not zero, except that the rest of the (C)DNSKEY, including the owner
name, gets prepended before hashing. name, gets prepended before hashing.
5. Example 5. Example
This section will take you through the various parts of this This section will take you through the various parts of this
specification, by example. specification, by example.
We assume that we are working with a domain "example.com." with one We assume that we are working with a domain "example.com." with one
name server, "ns.example.com.". name server, "ns.example.com.".
5.1. Generating and placing the (C)DNSKEY/DS records 5.1. Generating and placing the (C)DNSKEY/DS records
[NOTE: this section uses '225' instead of 'TBD' because otherwise the
code does not work. We need to fix this before publication.]
We will walk you through the CDNSKEY/DS generation, demonstrating it We will walk you through the CDNSKEY/DS generation, demonstrating it
in terms of basic shell scripting and some common tools. in terms of basic shell scripting and some common tools.
First, we extract the SubjectPublicKeyInfo: First, we extract the SubjectPublicKeyInfo:
openssl s_client -connect ns.example.com:853 < /dev/null \ openssl s_client -connect ns.example.com:853 < /dev/null \
| openssl x509 -noout -pubkey > pubkey.pem | openssl x509 -noout -pubkey > pubkey.pem
This gives us a file "pubkey.pem" that looks like this (abridged): This gives us a file "pubkey.pem" that looks like this (abridged):
skipping to change at page 5, line 8 skipping to change at page 6, line 4
MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAxH2a6NxIcw5527b04kKy MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAxH2a6NxIcw5527b04kKy
... ...
71AWASNoX2GQh7eaQPDD9i8CAwEAAQ== 71AWASNoX2GQh7eaQPDD9i8CAwEAAQ==
-----END PUBLIC KEY----- -----END PUBLIC KEY-----
To turns this into a CDNSKEY: To turns this into a CDNSKEY:
1. remove the header and footer 1. remove the header and footer
2. remove all newlines 2. remove all newlines
In other words: In other words:
openssl s_client -connect ns.example.com:853 </dev/null \ openssl s_client -connect ns.example.com:853 </dev/null \
| openssl x509 -noout -pubkey \ | openssl x509 -noout -pubkey \
| sed '1d;$d' \ | sed '1d;$d' \
| tr -d '\n' | tr -d '\n'
Then we prepend Then we prepend
example.com. IN CDNSKEY 0 3 225 example.com. IN CDNSKEY 257 3 225
so that we end up with so that we end up with
example.com. IN CDNSKEY 0 3 225 MIICIj...AAQ== example.com. IN CDNSKEY 257 3 225 MIICIj...AAQ==
If your registry accepts CDNSKEY, or DNSKEY via EPP, you are done - If your registry accepts CDNSKEY, or DNSKEY via EPP, you are done -
you can get your DS placed. you can get your DS placed.
To generate the DS, do something like this: To generate the DS, do something like this:
echo example.com. IN DNSKEY 0 3 225 MIICIj...AAQ== \ echo example.com. IN DNSKEY 257 3 225 MIICIj...AAQ== \
| ldns-key2ds -f -n -2 /dev/stdin | ldns-key2ds -f -n -2 /dev/stdin
example.com. 3600 IN DS 7573 225 2 fcb6...c26c example.com. 3600 IN DS 7573 225 2 fcb6...c26c
[TODO: what if a server has different keys depending on crypto
algorithm negotiation? probably need some words on that somewhere,
perhaps not (only) in this section]
6. Implementation 6. Implementation
The subsection titles in this section attempt to follow the The subsection titles in this section attempt to follow the
terminology from [RFC8499] in as far as it has suitable terms. terminology from [RFC8499] in as far as it has suitable terms.
'Implementation' is understood to mean both 'code changes' and 'Implementation' is understood to mean both 'code changes' and
'operational changes' here. 'operational changes' here.
6.1. Authoritative server changes 6.1. Authoritative server changes
This specification defines no changes to query processing in This specification defines no changes to query processing in
authoritative servers. authoritative servers.
If DoT-signaling DS records are published for a zone, all name If DoT-signaling DS records are published for a zone, all name
servers for the zone (from both the parent-side and child-side NS servers for the zone (from both the parent-side and child-side NS
RRsets) SHOULD offer DoT service on port 853, and when they do, they RRsets) SHOULD offer DoT service on port 853, and when they do, they
SHOULD do so using keys present in the DS RRset. However, there are SHOULD do so using keys present in the DS RRset. However, there are
potential cases where this is not possible, like having multiple DNS potential cases where this is not possible, like having multiple DNS
providers. In this case the name servers that do not support DoT providers. In this case the name servers that do not support DoT
SHOULD respond with a RST response on the port tcp/853 to prevent MUST respond with a RST response or similar on the port tcp/853 to
name resolution slow downs. prevent name resolution slowdowns.
6.2. Validating resolver changes 6.2. Validating resolver changes
If a resolver succesfully uses DoT with a nameserver as specified in If a resolver successfully uses DoT with a nameserver as specified in
this document, it MAY assume DoT is always available for that this document for one domain, it MAY assume DoT is always available
nameserver. However, it MAY NOT assume that the connection is from that nameserver for questions for another domain. However, it
properly pinned unless there is a DS record available for the domain MUST NOT assume that the connection is properly pinned for that other
it is currently resolving. domain unless there is a DS record available for that other domain it
is currently resolving.
A validating resolver that supports this draft will perform the
following actions when a DS record with algorithm TBD is encountered:
1. Connects to the name server on port 853.
2. During TLS handshake, the resolver will extract the
SubjectPublicKeyInfo from the certificate.
3. Construct an in-memory DNSKEY record [RFC4034] section 2 with its
fields set as follow:
* Flags: 257
* Protocol: 3
* Algorithm: TBD
* Public Key: The wire-format SubjectPublicKeyInfo
4. Get the list of Digest Type for DS records obtained from the
parent with algorithm TBD
5. For each digest type from the list, compute the DS record of the
previously computed DNSKEY, its fields are set as follow:
* Key Tag: computed from DNS key using [RFC4034] appendix B
* Algorithm: TBD
* Digest Type: the current Digest Type we are computing the DS
for.
* Digest: Following [RFC4034] section 5.1.4, compute the digest
of owner name | previously computed DNSKEY's RDATA.
6. Test the computed DS record against all the supplied DS records
until a match is encountered.
7. If any computed DS record matches a DS record in the DS record
set we got from the parent, the connection is successfully
authenticated.
6.3. Stub resolver changes 6.3. Stub resolver changes
This specification defines no changes to stub resolvers. This specification defines no changes to stub resolvers.
6.4. Zone validator changes 6.4. Zone validator changes
This section covers both the 'online' type of zone validator, such as This section covers both the 'online' type of zone validator, such as
Zonemaster, and the 'offline full zone' type, such as "validns" and Zonemaster, and the 'offline full zone' type, such as "validns" and
"dnssec-verify". "dnssec-verify".
skipping to change at page 7, line 44 skipping to change at page 9, line 37
they see fit". they see fit".
8.1. PoC 8.1. PoC
Some Proof of Concept code showing the generation of the (C)DNSKEY, Some Proof of Concept code showing the generation of the (C)DNSKEY,
and the subsequent hashing by a client (which should match one of the and the subsequent hashing by a client (which should match one of the
DS records with algo TBD), in Python and Go, is available at DS records with algo TBD), in Python and Go, is available at
https://github.com/PowerDNS/parent-signals-dot/tree/master/poc https://github.com/PowerDNS/parent-signals-dot/tree/master/poc
(https://github.com/PowerDNS/parent-signals-dot/tree/master/poc) (https://github.com/PowerDNS/parent-signals-dot/tree/master/poc)
9. IANA Considerations 9. Design Considerations
[RFC Editor: please remove this section before publication]
A protocol design is nothing without a clear statement of the
constraints it was designed to meet, and perhaps a list of other
constraints it meets by accident.
We humbly acknowledge Petr Spacek's excellent summary of the 'nice
properties' this protocol has (https://mailarchive.ietf.org/arch/msg/
dns-privacy/_Zf5TGVAcUfPRrQ_7o_NPnmnlZs/) as a source of inspiration
for this section.
Manu's DSPKI proposal had the following excellent properties:
* no extra roundtrips (assuming DSPKI came 'for free' with
delegations like DS records do today)
* downgrade resistance
* simple protocol, no indirections
It also had this one very important undesirable property:
* a new RRtype with 'special' behaviour would be pretty much
impossible to deploy
In various private and public discussions, it was quickly realised
that fitting this into the actual DS record would solve that problem.
The first obvious answer to that is 'just assign some numbers and do
in DS what DSPKI defined in its own type'. Petr Spacek and others
pointed out that this would be incompatible with 'DNSKEY-style'
registries, i.e. those that demand DNSKEY, not DS, in their
communications (those communications being either EPP, some registry-
specific protocol, or CDNSKEY). In other words, a protocol that
would not allow the DS to be hashed 'the usual way' from a DNSKEY
would not go far, as many registries are slow to update their
software even _just_ for a couple of new numbers in an IANA registry.
With that, the puzzle was clear. We need some format to signal and
pin DoT with a DNSKEY, in such a way that a DS can be hashed from it
without software changes in parties such as registries, and such that
that DS is enough for a resolver to validate a TLS connection.
Eventually we realised that a resolver could take the TLS
SubjectPublicKeyInfo, construct a 'pseudo' DNSKEY from it, and hash
that into a DS. This resolves the one bad property of DSPKI
(deployability without changing every auth, resolver, and registry
stack in the world).
The design constraints we felt we must meet with this protocol were:
* deployability without demanding massive software changes or even
'flag days'
* downgrade resistance
And we feel we have met those. The other positive properties of
DSPKI (simplicity, no extra roundtrips) have been kept intact more by
accident than by strong intention.
We can understand that several people are saying that this is hacky
(we do not even disagree), and that TLSA should have been used.
However, we feel that any TLSA-based protocol we can imagine would be
a lot more complex, and therefore prone to breakage which might be
hard to debug. It would also be very easy to accidentally introduce
chicken-and-egg problems with a more indirect approach. Note that we
are responding to imagined TLSA-based protocols here. If a draft
appears for a TLSA-based approach to DoT signaling/pinning, we would
love to read it. Depending on what that draft looks like, it might
even make sense to have that protocol _and_ the protocol described in
this document.
The biggest downside to this DS-based protocol is that a change in
TLS keys on an auth may require DS updates for thousands or even
hundreds of thousands of domains. This issue is partially mitigated
by allowing backup keys to be part of those DS sets. Furthermore we
hope that efforts from Cloudflare and others for shortening the path
between auth operator and domain registrar one day work out. Those
efforts are focused on NSset updates and DS updates for DNSSEC
validation, but they would also aid key rollovers for this protocol
greatly.
10. IANA Considerations
This document updates the IANA registry "DNS Security Algorithm This document updates the IANA registry "DNS Security Algorithm
Numbers" at https://www.iana.org/assignments/dns-sec-alg-numbers/dns- Numbers" at https://www.iana.org/assignments/dns-sec-alg-numbers/dns-
sec-alg-numbers.xhtml (https://www.iana.org/assignments/dns-sec-alg- sec-alg-numbers.xhtml (https://www.iana.org/assignments/dns-sec-alg-
numbers/dns-sec-alg-numbers.xhtml) numbers/dns-sec-alg-numbers.xhtml)
The following entries have been added to the registry: The following entries have been added to the registry:
+--------------+----------------+ +--------------+----------------+
| Number | TBD | | Number | TBD |
| Description | DoT signal+pin | | Description | DoT signal+pin |
| Mnemonic | DOTPIN | | Mnemonic | DOTPIN |
| Zone signing | N | | Zone signing | N |
| Trans sec. | N | | Trans sec. | N |
| Reference | RFC TBD2 | | Reference | RFC TBD2 |
+--------------+----------------+ +--------------+----------------+
10. Acknowledgements 11. Acknowledgements
Great input was received from Job Snijders, Petr Spacek, Pieter
Lexis, Ralph Dolmans, Remi Gacogne, and Vladimir Cunat.
11. Normative References
[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running The authors would like to thank the following individuals for their
Code: The Implementation Status Section", RFC 6982, useful input: Job Snijders, Maik Zumstrull, Petr Spacek, Pieter
DOI 10.17487/RFC6982, July 2013, Lexis, Ralph Dolmans, Remi Gacogne, Seth Arnold, and Vladimir Cunat.
<https://www.rfc-editor.org/info/rfc6982>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 12. Normative References
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from [I-D.bretelle-dprive-dot-for-insecure-delegations]
the Parent via CDS/CDNSKEY", RFC 8078, Bretelle, E., "DNS-over-TLS for insecure delegations",
DOI 10.17487/RFC8078, March 2017, Work in Progress, Internet-Draft, draft-bretelle-dprive-
<https://www.rfc-editor.org/info/rfc8078>. dot-for-insecure-delegations-01, 11 March 2019,
<https://tools.ietf.org/html/draft-bretelle-dprive-dot-
for-insecure-delegations-01>.
[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,
<https://www.rfc-editor.org/info/rfc4034>. <https://www.rfc-editor.org/info/rfc4034>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[I-D.bretelle-dprive-dot-for-insecure-delegations] [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Bretelle, E., "DNS-over-TLS for insecure delegations", Code: The Implementation Status Section", RFC 6982,
Work in Progress, Internet-Draft, draft-bretelle-dprive- DOI 10.17487/RFC6982, July 2013,
dot-for-insecure-delegations-01, 11 March 2019, <https://www.rfc-editor.org/info/rfc6982>.
<https://tools.ietf.org/html/draft-bretelle-dprive-dot-
for-insecure-delegations-01>. [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>.
[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-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
DNSSEC Delegation Trust Maintenance", RFC 7344, DNSSEC Delegation Trust Maintenance", RFC 7344,
DOI 10.17487/RFC7344, September 2014, DOI 10.17487/RFC7344, September 2014,
<https://www.rfc-editor.org/info/rfc7344>. <https://www.rfc-editor.org/info/rfc7344>.
[RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from
the Parent via CDS/CDNSKEY", RFC 8078,
DOI 10.17487/RFC8078, March 2017,
<https://www.rfc-editor.org/info/rfc8078>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
12. Informative References 13. Informative References
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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, <https://www.rfc-editor.org/info/rfc6698>. 2012, <https://www.rfc-editor.org/info/rfc6698>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>. January 2019, <https://www.rfc-editor.org/info/rfc8499>.
Appendix A. Document history
A.1. Changes between -00 and -01
1. Lots of clarifying text that does not change any semantics,
including:
* a section on how resolvers would actually use this protocol.
* we made it clearer that multiple DS records for a delegation
are allowed, and why you would want this.
2. DNSKEY flags are now set to 257, because it looks like this will
make it a lot easier for many registries to accept the records.
3. Added a 'Design Considerations' section to give some background
to why this protocol is what it is.
We have tried to do a review of this protocol against the requirement
of the DPRIVE phase 2 document. You can find this review (which
might be updated outside of revisions of this draft or the phase 2
draft) in our GitHub repo (https://github.com/PowerDNS/parent-
signals-dot/blob/master/draft-vandijk-dprive-ds-dot-signal-and-
pin/yardsticks/draft-ietf-dprive-phase2-requirements-01.md).
Authors' Addresses Authors' Addresses
Peter van Dijk Peter van Dijk
PowerDNS PowerDNS
Den Haag Den Haag
Netherlands Netherlands
Email: peter.van.dijk@powerdns.com Email: peter.van.dijk@powerdns.com
Robin Geuze Robin Geuze
TransIP TransIP
Delft Delft
Netherlands Netherlands
Email: robing@transip.nl Email: robing@transip.nl
Emmanuel Bretelle Emmanuel Bretelle
Facebook Facebook
Email: chantra@fb.com Email: chantra@fb.com
 End of changes. 27 change blocks. 
73 lines changed or deleted 253 lines changed or added

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