Re: [DNSOP] Privacy and DNSSEC

[Shumon Huque <[e-mail]>]

On Sat, Apr 25, 2020 at 2:57 AM Paul Vixie <[e-mail]> wrote:

> On Saturday, 25 April 2020 06:23:54 UTC Vladimír Čunát wrote:
> > Original subject: New draft on delegation revalidation
> >
> > Still, note that for some consumers the secure transport may be an
> > argument to drop validating DNSSEC themselves.  If they choose some DNS
> > provider that they trust with privacy (it might be their ISP), it seems
> > not a huge leap to trust them with DNS integrity as well (say, the
> > provider doing DNSSEC validation).  Especially as today "regular users"
> > don't get that much benefit from validation, mostly relying on
> > https/tls.
>
> i hope there's some use for DNS results beyond introducing me to an X.509
> authenticated web server. for example i might use DNS to validate an X.509
> self-signed certificate along the lines of DANE. to me this means the goal
> we
> followed for DNSSEC (authenticate what goes into an RDNS cache) was too
> narrow, and the difficulties of getting stub validation working should
> have
> been avoided from the outset (in 1996, that was.)
>

That was the goal that was largely followed, but was it the original goal?

The DNSSEC specs have always contemplated validating stub resolvers.
I think the Kaminsky cache poisoning scare inadvertently focussed our
efforts on solving the DNSSEC-to-RDNS problem to the exclusion of other
more complete possibilities.

There has certainly been work on validating stubs on the margin though:
getdns, stubby, etc, but those are only used by a small minority of tech
savvy users (as far as I'm aware).

The one significant impediment cited for validating stubs is the middlebox
last mile problem. Here again, there has been attempted work, e.g. the
TLS DNSSEC chain extension for TLS enabled applications. And DNS
over TLS/HTTPS could prove to be an enabler for validating stub resolvers
to obtain a clean, unmolested path to an upstream recursive service.

Shumon Huque