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]

[Christian Huitema <[e-mail]>]

On 6/9/2020 12:21 PM, Shumon Huque wrote:
> On Tue, Jun 9, 2020 at 2:31 PM John Levine <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     In article
>     <[e-mail]
>     <mailto:[e-mail]>>
>     you write:
>     >Well, the client could just use the zone name as the SNI, no? You
>     can assign
>     >certificates with the same name but different keys to each of the
>     >nameservers.
>
>     That sounds quite painful for servers that serve hundreds or
>     thousands of zones.
>
>
> That's a good point John. It might pose an impediment for them. Anyway,
> I'm not suggesting we adopt my idea yet. I'm just trying to talk
> through the
> possibilities and pros & cons first.
>
>     I am assuming these would be self-signed certs. If you want them
>     signed there's an additional bootstrap problem since the CA everyone
>     uses, Let's Encrypt, needs working DNS to sign a cert.
>
>
> My assumption is that most would be self signed, or self-issued by the
> domain (DANE-TA). I did mention the possibility of supporting the
> PKIX modes earlier too, but now that I think about it, there are 
> additional issues there. An org may be willing to handout public CA
> issued certs for their main domain name to outsourced nameserver
> operators. So to be acceptable, this would need to have more
> compartmentalized security properties, such as the use of things
> like SRVName SAN or similar application specific certificate identities,
> which rules out public CAs, since none of them support those.


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.

In fact, even if SNI encryption is used, you still have a privacy leak.
Third parties can observe that a request to the recursive resolver
triggered a new connection to the authoritative server, and can infer
that the query was for a rarely used domain served by that server. Not
quite as bad as leaking the actual name of the target domain, but still
a piece of information that can be used for further inferences.

It seems prudent to require that a single connection between a recursive
resolver and an authoritative server can be used for requests to all
domains served by that authoritative server. That's better for both
performance and privacy.

-- Christian Huitema


-- Christian Huitema