Re: [dns-privacy] [Fwd: [EXT] New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-01.txt]

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: internet-drafts@ietf.org
> To: Robin Geuze <robing@transip.nl>, Peter van Dijk <
> peter.van.dijk@powerdns.com>, Emmanuel Bretelle <chantra@fb.com>
> 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
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>