Re: [TLS] Alternative ESNI?

[Kathleen Moriarty <[e-mail]>]

Hey EKR,

Sent from my mobile device

> On Dec 18, 2018, at 4:48 PM, Eric Rescorla <[e-mail]> wrote:
> 
> 
> 
>> 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 

It’s a broad statement.  If I were to give that acting in a CISO role, it would sound like FUD and I either wouldn’t get very far or wouldn’t get anywhere towards goals the next time around.  Crisping it up to the exact threat, point of risk, quantifying, and prioritizing would help.

I’m hearing from concerned people in the threat detection/response side on this (eSNI) who are not willing to speak up.  This point is also where they sit on a network , typically one they manage and users consent to monitoring in their employment agreement.  They are watching for attackers, including nation-state threat actors.  

When ‘many’ attackers are listed, it sounds ominous.  However, if it were quantified and the exact threat were listed, then judgement calls could be made.  Maybe the threats you are referring to are far worse than nation state supply chain attacks or are ones that TLS as a WG prioritizes.  It would be good to either leave out generic statements or to list something more specific (or a list or point back to the draft that covers this topic).

It’s likely that incident responders will just need to adapt, but keeping a prioritized list of threats and point of defense could be helpful to many.

Best,
Kathleen 
> 
> 
>> 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
>