Re: [Add] ECS privacy concerns, alternatives?

[Brian Dickson <[e-mail]>]

On Thu, Apr 25, 2019 at 2:37 PM Erik Kline <[e-mail]> wrote:

>
>
> On Thu, 25 Apr 2019 at 14:06, Puneet Sood <puneets=
> [e-mail]> wrote:
>
>>
>> I think this can be solved by having the recursive resolver probe for
>> ECS support for a zone. If an authoritative nameserver serves a zone
>> that does not support ECS, it can respond w/o the ECS option
>> (https://tools.ietf.org/html/rfc7871#section-7.2.1). A recursive
>> resolver can use this as a signal to not send ECS to the nameserver
>> *for that zone* in the future. The recursive resolver would need to
>> probe periodically to handle the situation when the ECS support
>> changes.
>>
>> What am I missing here?
>>
>
> My recollection from the DPRIVE 104 discussion about TLS to the
> authoritative was that a non-probing method was considered preferable.
>
> Generalizing from there, I think folks want to minimize the amount of
> "probe and remember" activity that has to take place (no matter the problem
> domain).
>

I think there are two independent things that could/should be pursued: (a)
some way of signaling scalably about DoT/DoH support; and (b) a
sufficiently scalable probing method as a stopgap in the interim.

If probing is going to be done and remembered, I would prefer it be done
roughly as follows:
- TLS probing by IP, with support/non-support cached
- ECS probing done over TLS only, with support/non-support cached (to
minimize TLS usage).

The signaling in (a) should, in theory, be regarding *both* ECS and TLS
support, maybe as yet another delegation record (sibling to DS and NS). But
it's an ugly hack.

Brian