Re: [TLS] Alternative ESNI?

[Eric Rescorla <[e-mail]>]

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. Even if all the attacker can do is
*modify*
records rather than observe queries, this is often enough. For censorship
applications,
they just serve a blackholed IP address, and for surveillance applications,
an
attacker with significant network capabilities can serve a dedicated IP for
each
server name and then forward the traffic.

Note that DNSSEC does not help very much in this case. If the attacker is
the server, they don't need to modify records, and if they are not the
server,
then DNSSEC protection relies upon the client hard-failing on DNSSEC
failures,
which generic clients do not do because it would cause unacceptable failure
rates.

-Ekr

[0] https://www.cs.umd.edu/~dml/papers/dnssec_imc17.pdf provides an overview
of the extremely depressing state of play; only 1% of .com is properly
signed
and about 30% of domains which have DNSSEC don't publish all the records
needed to verify the domain.