On Mon, Nov 23, 2020 at 12:49:25PM +0100, Peter van Dijk wrote: > On Fri, 2020-11-20 at 20:47 +0100, Vladimír Čunát wrote: > > > > In retrospect I see that what I wrote is very similar to Manu's > > "Do9" except for replacing WebPKI by TLSA, with all their pros > > and cons: > > https://datatracker.ietf.org/meeting/104/materials/slides-104-dprive-dot-for-insecure-delegations-01 > > WebPKI has excellent latency properties compared to TLSA. In more > words: a parent-side signal that does not pin keys, but does > authenticate names, would allow WebPKI based DoT with zero extra > queries compared to current non-DoT operations.
The WebPKI folks would really hate that, due to the serious ossificiation concerns it would pose to WebPKI. And by history of DNS, those concerns are very much warranted (DNSSEC root key rollover was the most obvious example). There have been number of incidents where non-web use of WebPKI has caused significant headaches for WebPKI folks. On the other side, there are very real concerns about security of WebPKI. Some of the approved validation methods are downright scary. Then security of WebPKI fundamentially based on DNS (despite it managing to collect more single points of failure), so using it in DNS would cause cyclic dependency with non-obvious implications. Then WebPKI can not do service authentication (it is not needed for the Web). Then what should the contents of the trust store be? While in theory, TLS is capable of negotiation here, in practice that does not work (because clients have too many trusted CAs, and servers have no room to manover in). So one would likely get interop issues. Then this would cause issues if there are ever two incompatible transports, e.g., DNS over TLS and TLS over QUIC. The server operators would prefer not to have involve zone owners in what transports they offer. If one has secure capability advertisment from server operators, one could just put the authentication data into that (but there would be some concerns about many queries to various servers, even if the advertisment is just one rrset). If there is DNSSEC, stapling the chain would offer the same latency properties. Of course, that turns out to hit some layer-9 issues to specify (there was draft about that that got kicked out of TLS WG for being too toxic), alongside with above-noted issues with incompatible transports. -Ilari _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
