On Mon, 13 Jul 2020, Peter van Dijk wrote:
please find below revision -01 of our proposal for enabling DoT from resolver to authoritative.
DoT can be enabled regardless. This draft is not about enabling DoT. It is about saving a few roundtrips getting the right keys in a trusted method. With some caveats that go along with it.
The value 257, meanwhile, is believed to go down with registries much easier.
What is that believe based on?
* we added a 'Design considerations' section that explains how this protocol came to be, and why we did not go the TLSA route. You can click through to it directly via https://tools.ietf.org/html/draft-vandijk-dprive-ds-dot-signal-and-pin-01#section-9
It's not a good summary of the list discussion. I guess a draft isn't a good place for that, but I don't see the concerns of me and Viktor listed here at all. 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. I don't see how backup keys help here? If you have thousands of domains, and one of them is unresponsble to DS updates, the auth server cannot retire its key. With thousands of domains the change of that happening very quickly goes to 100%. If you tell all of them to pre-publish a backup (or really, new) key, then you are just postponing the problem by one interation. This solution simply cannot work at scale. At operating without scale defeats the whole purpose of anonimity. A much better solution is simply to use TLSA records at the nameservers. Sure, your first domain incurs an extra RTT but that one RTT is made back over all the domains hosted by that auth server. It leaves control of the TLSA record where it belongs - at the owner of the Dot keypair. A DS record can still be used to allow the child zone to make it mandatory to use DoT or hardfail. But it does not (and should not) have a public key embedded in it to do this. A number of other items from our previous discussion I don't see back here either, such as the discussion around CDS so that the client can prevent a TLD scale size MITM DoT redirect from overruling its own policy by the abusive parent playing its own DS DoT records against the child's wishes. (And if I recall, you don't want to do this because you are concerned about RTTs) Paul
Furthermore, we have tried to do a review of this protocol against the requirements 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) via https://github.com/PowerDNS/parent-signals-dot/tree/master/draft-vandijk-dprive-ds-dot-signal-and-pin/yardsticks We'll be presenting the draft at the IETF108 dprive session. Kind regards, Manu, Robin & Peter -------- Forwarded Message -------- From: [email protected] To: Robin Geuze <[email protected]>, Peter van Dijk < [email protected]>, Emmanuel Bretelle <[email protected]> Subject: [EXT] New Version Notification for draft-vandijk-dprive-ds- dot-signal-and-pin-01.txt Date: Mon, 13 Jul 2020 01:47:10 -0700 A new version of I-D, draft-vandijk-dprive-ds-dot-signal-and-pin-01.txt has been successfully submitted by Peter van Dijk and posted to the IETF repository. Name: draft-vandijk-dprive-ds-dot-signal-and-pin Revision: 01 Title: Signalling Authoritative DoT support in DS records, with key pinning Document date: 2020-07-13 Group: Individual Submission Pages: 14 URL: https://www.ietf.org/internet-drafts/draft-vandijk-dprive-ds-dot-signal-and-pin-01.txt Status: https://datatracker.ietf.org/doc/draft-vandijk-dprive-ds-dot-signal-and-pin/ Htmlized: https://tools.ietf.org/html/draft-vandijk-dprive-ds-dot-signal-and-pin-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-vandijk-dprive-ds-dot-signal-and-pin Diff: https://www.ietf.org/rfcdiff?url2=draft-vandijk-dprive-ds-dot-signal-and-pin-01 Abstract: This document specifies a way to signal the usage of DoT, and the pinned keys for that DoT usage, in authoritative servers. This signal lives on the parent side of delegations, in DS records. To ensure easy deployment, the signal is defined in terms of (C)DNSKEY. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
