On Wednesday, 29 April 2020 13:44:12 UTC Shumon Huque wrote: > On Wed, Apr 29, 2020 at 12:49 AM Paul Vixie <p...@redbarn.org> wrote: > > ... > > This is by no means a problem unique to DNSSEC. Many new protocol features > have and continue to face the middlebox challenge: SCTP, TCP fast open, > multi- > path TCP, QUIC, TLS 1.3 etc. Some have developed workarounds with varying > degrees of success, some like SCTP have more less died. The web has the > advantage (in my opinion) that a small number of browsers are able to impose > changes on the middlebox ecosystem in a way that the DNS will never be able > to.
so, there were two modes. first, the web was created. it worked everywhere and required no upgrades to the OS or any other protocol or any gateways or firewalls. later (today), the web is dominant and if it makes a change that doesn't work everywhere, the pain will be felt everywhere, and every operating system and gateway and firewall will conform or die. DNSSEC has never been in either mode. depending on DNSSEC for a product or service remains commercial suicide and always will. thus noone invests in such products or services, and anyone thinking about the X.509 CA problem ignores DANE and focuses on cert-pinning or similar. the pre-DS clear path requirement was really "allow unknown RRtypes". the post-DS clear path requirement was really "understand DS". that was a change we made, that stopped all progress beyond "let's opportunistically protect the RDNS cache, and geeky stuff like SSHFP, and DANE for SMTP". > As I mentioned in a previous note, DNS over HTTPS (however one might feel > about current deployment models and such), can probably provide the clean > path that end user applications of DANE need. i heard you say that, and i disagree, but it's off-topic, so, another time. -- Paul _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
