On Wed, 2020-11-18 at 23:09 +0000, Tony Finch wrote: > > > * Authenticate the server by `subjectAltName` `iPAddress`. [snip] > > > > For DOTPIN, Ralph Dolmans had the bright insight to suggest not sending > > a server name at all (which matches what I said earlier - name servers > > have IPs, not really names). > > Do you mean not sending in TLS SNI? Yes, that would make sense if we're > not doing name-based auth.
Yes. > > > * Ignore certificate name mismatches, and authenticate just the public > > > key. [snip] > > > > As above. (Not saying that it is the only way, but 'a name server has > > no name' has a lot of convenient properties.) > > There's another downside to this case: with IP-based or name-based auth, > you can put the CA's public key in the TLSA rather than the server key, so > there's less rollover churn, but that doesn't make sense for key-based > auth. Ah, of course. Then you have the downsides of TLSA with the downsides of DOTPIN. > I think there are significant (albeit woolly) advantages to staying as > close as possible to normal webPKI for DoT: much lower congnitive load for > operators who can reuse their https knowledge; deveopers don't have to > write code that's too weirdly different from https; very straightforward > parallel deployment for DoT, DoH, DoQ (if we ever want to support more > transports). That makes sense. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
