On Jan 26, 2021, at 1:07 PM, Jacques Latour <[email protected]> wrote: > >>> Opportunistic encryption from authoritative perspective > > I was hoping to make it tomorrow but in case I don't, here's my feedback. I > want to avoid a DoH here by voicing my concerns too late where this proposal > end up a MUST instead of SHOULD to support encryption on authoritative.
Just to be clear, there is nothing in the current draft that even suggests "SHOULD". There are many reasons why a particular authoritative server operator would not want to add ADoT. > I'm pretty sure that there are many people that are silent on this proposal, > or simply don't have visibility. I think encryption at this level is not > addressing the root problem to preserve client privacy. Quite true, but that is not even listed as part of the use case. > We should look at how clients could round robin their queries to resolvers > via DoH, DoT, even D-over-Jabber 😉, there are 10000s of open resolvers, > anonymity can be achieved for sure to an authoritative server. True. If the use case is "a user wants to be assured of more anonymity", this proposal is not good for that. > It’s not because we can we should, and I don't see how this level of > encryption will enhance the end client’s privacy posture. It will slightly but unpredictably help the privacy of users of a resolver. It helps the privacy of the users in aggregate, but certainly not in the specific. > If you don’t trust the resolver, pick one you trust, because if you run your > own, people can see the which authoritative you’re querying… I don't see how "pick one you trust" helps the privacy, given that the resolver still needs to talk to authoritative servers. > In reading through the draft that there’s going to be unacceptable induced > latency on resolver for TLDs and authoritative domains that are (would) not > ADoT enabled. If a resolver decides that the increased latency is unacceptable, then it won't use the protocol. However, that should be an operational decision for the resolver operators to make, not forced on them by reluctant authoritative server operators. An authoritative operator can decide not to support ADoT if they don't want resolvers using it with their service, of course, but not for the whole DNS. --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
