Re: [TLS] Alternative ESNI?

[Eric Rescorla <[e-mail]>]

On Tue, Dec 18, 2018 at 10:54 AM Kathleen Moriarty <
[e-mail]> wrote:

> Just a clarifying question inline
> On Sun, Dec 16, 2018 at 3:30 PM Eric Rescorla <[e-mail]> wrote:
>
>>
>>
>> On Sun, Dec 16, 2018 at 11:45 AM Paul Wouters <[e-mail]> wrote:
>>
>>> On Fri, 14 Dec 2018, Eric Rescorla wrote:
>>>
>>> > However, in a large number of cases (e.g., an attacker on your local
>>> network,
>>> > there are non-DNSSEC ways of obtaining this property, such as using
>>> DoH.
>>>
>>> Data origin authenticity is not the same as transport security.
>>>
>>
>> Yes, I'm quite aware of this fact.
>>
>>
>> DoH offers no guarantee that the non-dnssec protected information you
>>> received is not modified.
>>>
>>
>> As with all things security, it depends on your threat model. If the
>> attacker you
>> are concerned with is between you and the DNS server, then in fact it does
>> provide protection.
>>
>>
>> Unfortunately, I keep needing to say this on various IETF lists. The
>>> move towards "blindly trusting DNS over HTTPS/TLS" servers is misguided
>>> and just moving the goal post.
>>>
>>
>> I don't think this is a very accurate characterization of the situation.
>> At present,
>> the vast majority of DNS information is not DNSSEC protected [0], and yet
>> we
>> have to rely on it. If there's a "blindly trusting" in this discussion,
>> it's that. DNS
>> over HTTPS is designed to improve the situation, though of course it's not
>> a panacea.
>>
>> However in *this* case, it actually covers a pretty large fraction of the
>> threat
>> model, because (1) many attackers are close to the user and (2) if the
>> attacker
>> controls your DNS server, then they learn which site you are going to in
>> any case even before you send SNI.
>>
>
> This is written as a pretty broad statement.  Did you intend to say that
> the attackers for this threat vector are close to the user or many
> attackers?
>

I'm not sure I understand the question you are asking. A lot of the threats


Asking as this could sway opinions and the current solution is well suited
> to CDNs, not necessarily others.
>

Yes, the current solution is generally designed to fit into CDN-like
scenarios. However, ESNI is generally not that useful unless you have a lot
of origins on the same domain (otherwise the IP address itself reveals your
destination), and there are a limited number of scenarios of this type
(CDNs, hosting providers, application servers, etc.)



>> [0] https://www.cs.umd.edu/~dml/papers/dnssec_imc17.pdf provides an
>> overview
>>
>
> This is probably a bit better as a reference as it appears to be kept
> current:
> https://www.internetsociety.org/deploy360/dnssec/statistics/
>

Thanks.


and includes links to others providing statistics for reference as well.
> The validation statistics look a bit better in the following study:
> https://stats.labs.apnic.net/dnssec/XA?c=XA&x=1&g=1&r=1&w=7&g=0
> where worldwide, they say 16% DNSSEC validates.
>

I believe this is measuring something different, which is the fraction of
the Internet which is covered by validating resolvers. However, that
doesn't reflect end-to-end validation, but (typically) recursive resolver
validation, which is a rather different matter. To my knowledge, no generic
browser client does DNSSEC validation, for the reason that when people have
looked at it it created unaceptable failure rates.

-Ekr