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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
