Re: [dns-privacy] [Ext] Authentication in draft-ietf-dprive-opportunistic-adotq

[Paul Hoffman <[e-mail]>]

On Feb 16, 2021, at 7:23 AM, Ben Schwartz <bemasc=[e-mail]> 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