On Tue, Jun 9, 2020 at 2:31 PM John Levine <[email protected]> wrote: > In article < > 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. Shumon.
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
