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

[Ben Schwartz <[e-mail]>]

On Mon, Feb 15, 2021 at 5:25 PM Paul Hoffman <[e-mail]> 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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>