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

[Ben Schwartz <[e-mail]>]

On Tue, Feb 16, 2021 at 11:19 AM Paul Wouters <[e-mail]> wrote:

> On Feb 16, 2021, at 10:23, 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).
>
>
> I explained that in my previous message. Opportunistic normally is “do
> encryption, then you may omit authentication if that is too hard”.
> Opportunistic is not “try this technology and maybe in the future try this
> completely other technology”.
>

These are not different technologies; they're precisely different usage
profiles of the same standard (RFC 8310).


> 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.
>
>
> That makes using a LetsEncrypt certificate violate the RFC’s MUST NOT.
>

Serving under such a certificate would not violate this requirement.


> The “big scary” part of using TLS is in the transport that is common for
> authenticated and unauthenticated TLS.
>

I think the scary part is that an authenticated TLS failure (due to
misconfiguration, bug, overload, or rollback) results in an outage.
draft-ietf-dprive-opportunistic-adotq never results in an outage; you just
fall back to cleartext and pay a small latency penalty.