On Mon, Feb 15, 2021 at 5:25 PM Paul Hoffman <[email protected]> wrote: ...
> 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. > I don't see why there would be a conflict between draft-ietf-dprive-opportunistic-adotq and any future authenticated encryption RFC that we produce, so I don't see the need to impose a drastic dividing line (e.g. different port numbers). Here's a counter-proposal: 1. Mark draft-ietf-dprive-opportunistic-adotq "experimental". This is in line with previous work on opportunistic encryption, e.g. RFC 8164, and accurately reflects the draft's status as both speculative and (hopefully) transitional. 2. Replace Section 5 with the following language: There is currently no defined mechanism for authenticated ADoT, so resolvers MUST NOT authenticate the server except by private agreement with the server operator. Server operators SHOULD use self-signed certificates to avoid implying an authentication mechanism that might conflict with a future ADoT authentication standard. As I've said before, I _do_ think this draft is valuable and presents a worthwhile public experiment that will pave the way for authenticated ADoT. For DNS services that are used to DNS over UDP, running DNS over TLS is a big, scary project. This draft can provide a way to get some practice with that in a low-risk setting, where TLS-related failures are not significantly user-visible. Once operators are comfortable with DNS over TLS, I think it will be a lot easier to start rolling out some real authentication. On Mon, Feb 15, 2021 at 5: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. There have been comments on the list (but without any supporting > Internet Drafts) that some resolvers might want to only serve answers that > they got in a fully authenticated fashion, and those same people objected > to the consideration of opportunistic ADoT(Q) because it would make the > possible later definition of a fully-authenticated protocol more difficult. > > 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. > > --Paul Hoffman_______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
