On Feb 16, 2021, at 7:23 AM, Ben Schwartz <[email protected]> wrote: > 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.
That seems fine. (Well, "self-issued" is the proper term, and we'd have to elaborate a bit on how to do that, but yes). This also works well with PaulW's prooposed sentinel. > 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. Indeed. --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
