On Thu, Oct 31, 2019 at 2:41 PM Brian Dickson <[email protected]> wrote:
> > > On Thu, Oct 31, 2019 at 4:12 PM John Levine <[email protected]> wrote: > >> In article < >> cahbrmsdwdotqn8y5zk7rsvepjwwyateyaa6f0oj9desmafh...@mail.gmail.com >> <cahbrmsdwdotqn8y5zk7rsvepjwwyateyaa6f0oj9desmafh...@mail..gmail.com>> >> you write: >> >The ideas floated here about ADoT to the root are not, in my view, about >> >privacy (directly). They're about using ADoT to protect the integrity of >> >(currently) unsigned data in the root zone. >> > >> >An alternative solution is to get ADoT bootstrap info from the child >> zone, >> >where it could be signed, before making a query that reveals the next >> >label. This could work, but at the cost of an extra roundtrip. (How >> often >> >this latency penalty applies depends on the details of the >> construction..) >> >> Thinking about it a little more, I think it is likely that there will >> be islands of ADoT sort of like there used to be islands of DNSSEC. >> For example, I expect the people on this list are likely to deploy >> ADoT long before some of the 2LD's above them. Moreover, all of the >> problems about getting your DS into the zone above would apply to >> getting your ADoT signal there. Even with the cost of an extra lookup >> it's probably going to work better to have each island describe itself >> so you don't need an unbroken chain of ADoT from the root. >> > > IMNSHO, ADoT at the leaf + QNAME minimization is all that is required for > privacy. > I.e. No need for ADoT anywhere other than at the leaf zone's name server > (whose NS name might not be in-bailiwick, FYI). > Hmm.... I think that's only true if you are assuming that the NS record for the leaf is DNSSEC secured, but that doesn't seem like a safe assumption. -Ekr > Brian > _______________________________________________ > 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
