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

[Brian Dickson <[e-mail]>]

On Wed, Nov 6, 2019 at 9:31 AM Ted Hardie <[e-mail]> wrote:

> In-line.
>
> On Wed, Nov 6, 2019 at 9:05 AM Brian Dickson <
> [e-mail]> wrote:
>
>>
>>
>> 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.
>>
>
> 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 was interested in Paul's reason for "do not validate", as to whether it
was the concerns of generally validating everything, versus having the code
and operations that do the validation.
I.e., is it the concern about some zones having signing errors, independent
from the ADoT thing?

More recent operational results have show vastly improved levels of correct
operation of DNSSEC, and many fewer problems showing up, although I don't
track that myself and don't have references handy.
(I think there was a thread recently on one of the relevant lists to that
effect, though.)
I.e. I don't think aversion to validation generally is rational, but I also
don't like all-or-nothing when it comes to validation. I see this as likely
being an MTI (mandatory to implement) thing, with knobs to allow operators
to disable (against "medical" advice, as it were).



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

Exactly, you have very clearly made my point for me between your two
comments. :-)


>
> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>
>