On Mon, Feb 15, 2021 at 2:25 PM Paul Hoffman <[email protected]> wrote:
> Greetings again. One of the issues that seems to most bother people who > don't like the idea of opportunistic ADoT(Q) is the handwaviness of "but > authenticate if you can". That comes from RFC 7435, which is the > informational RFC that defines opportunistic security (OS). To quote from > section 1.2 of that document: > To achieve widespread adoption, OS must support incremental > deployment. Incremental deployment implies that security > capabilities will vary from peer to peer, perhaps for a very long > time. OS protocols will attempt to establish encrypted communication > whenever both parties are capable of such, and authenticated > communication if that is also possible. Thus, use of an OS protocol > may yield communication that is authenticated and encrypted, > unauthenticated but encrypted, or cleartext. This last outcome will > occur if not all parties to a communication support encryption (or if > an active attack makes it appear that this is the case). > > So far, the proposals for opportunistic ADoT(Q) in this WG have followed > that by talking about authentication, but so far no one has given a reason > to require authenticated transport given the presence of DNSSEC in the DNS > protocol. The reason is straightforward: if you do not provide authentication for the server, then you do not have confidentiality in the face of an active attacker. I'm pretty sure I've said this before, so I'm surprised at the claim that "no one has given a reason" I propose a way forward: make the two protocols obviously different so that > they don't affect each other. For those who want opportunistic ADoT(Q), > change the current design so that deploying it would not make creating and > deploying a fully-authenticated protocol more difficult; for those who want > a fully-authenticated protocol, design it so that it does not make > designing and deploying opportunistic ADoT(Q) more difficult. > > Does this sound like a good approach going forward. It gives those > supporting fully-authenticated protocol as much time as they need to come > up with a working protocol design, without stopping progress on the > proposal that has already gotten a fair amount of support in the WG. > This doesn't sound like a very good idea to me. IMO we should only specify a protocol that authenticates the server. -Ekr
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
