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

In-line.

On Wed, Nov 6, 2019 at 9:05 AM Brian Dickson <brian.peter.dickson@gmail.com>
wrote:

>
>
> On Wed, Nov 6, 2019 at 8:21 AM Paul Hoffman <paul.hoffman@icann.org>
> 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.
>

It seems odd to have the code and operations to do this on both signing and
validation , but then use it intermittently.  That seems both hard to
reason about and difficult to explain.

> 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?
>

I don’t think this would be something to recommend, personally.

Ted

>
> 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
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>