Re: [dns-privacy] [Ext] Threat Model

[Brian Dickson <[e-mail]>]

On Wed, Nov 6, 2019 at 8:21 AM Paul Hoffman <[e-mail]> wrote:

> Given that we are (still supposedly) talking about requirements and not
> solutions, I would be unhappy with a requirement that prevents a resolver
> that is not validating from being able to use encrypted transport to
> authoritative servers. Any protocol we develop for ADoT capability
> discovery should prevent downgrade attacks but should also work fine for
> resolvers that do not validate.
>

Why?

Or rather, let me put together a straw-man to attack.

Suppose the requirement (for the protocol for establishing the encrypted
transport for actual ADoT or for discovery of ADoT parameters) was that
*for this record* the record must be signed and must be validated, but that
it placed no broader requirement on validation.

I.e. TSLA for cert validation for the TLS connections used, which would
require DNSSEC validation (mandatory per DANE RFCs).

That would mean resolvers that don't validate *generally*, but do follow
the protocol (and validate very specific records) would would fine. Would
that be an unhappy-making requirement, or would you be okay with that
hair-splitting on validation?

Given that presumably *some* changes would need to be made to resolvers for
ADoT, IMHO the particulars of *what* changes should all be open to
discussion.

Brian