On 6/9/2020 12:21 PM, Shumon Huque wrote: > On Tue, Jun 9, 2020 at 2:31 PM John Levine <[email protected] > <mailto:[email protected]>> wrote: > > In article > <cahpuvduozvecj5jfd6nxyj-crhtjts1n8vcc5pc3uwqeclo...@mail.gmail.com > > <mailto:cahpuvduozvecj5jfd6nxyj-crhtjts1n8vcc5pc3uwqeclo...@mail.gmail.com>> > 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
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
