Re: [dns-privacy] NS names, was re-evaluation of the draft, was Re: [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]

[Shumon Huque <[e-mail]>]

On Tue, Jun 9, 2020 at 11:43 PM Christian Huitema <[e-mail]>
wrote

> There are two tests that matter: first, verify that the NS record is
> genuine and that the designated server is indeed the server chosen by the
> target domain; two, verify that the TLS connection terminates at the
> specified server. It is tempting to take a shortcut and merely verify that
> the TLS connection terminates at a server authorized by the target domain,
> but I don't think that's a good idea. John pointed out a management issue:
> the server would have to manage a large set of certificates, one for each
> domain it serves. But on top of the management issue, there are also
> performance issues and privacy issues.
>
> TLS authenticates the server during the connection handshake. That means
> one authentication per connection. In the case of a resolver accessing
> several domains served by the same big server, that means establishing
> separate TLS connections for each target domain, instead of establishing
> just one connection. That will clearly impact performances, but there is
> also a privacy aspect. In the absence of SNI encryption, the SNI can be
> observed. If the SNI just carries the name of the name server, no big deal.
> But if it carries the name of the target domain, the exchange reveals that
> this particular resolver queried that particular domain. Mix that with
> observation of the traffic to the recursive resolver, and you have an
> interesting privacy leak.
>

Hi Christian - yes, the zone name leakage issue would necessitate
SNI encryption in this design. Coupled with the fact that real privacy
means hiding in a large crowd (i.e. locating the zone name servers on
large DNS hosters serving thousands of zones, whose name server
names and addresses reveal no obvious connection to the zone name),
and the resulting certificate management issues that John pointed out,
this idea looks less attractive.

The more I think about all the privacy leaks that have to be plugged at
the DNS and application layers, Tor increasingly looks better as a
general purpose solution (either as a network to funnel DNS messages
through, or even better, having zone operators locate authority servers
inside Tor as hidden services). It has a significant performance cost,
but real privacy always does.

Shumon