On Wed, Apr 29, 2020 at 12:49 AM Paul Vixie <p...@redbarn.org> wrote:
> On Wednesday, 29 April 2020 01:17:04 UTC Shumon Huque wrote: > > ... > > > > Paul - I guess I'm missing some background here. In what sense did > > getting DS working throw validating stubs overboard? Do you mean it > > took the focus away from them? > > no. i mean that the decision to require a "clear path" for DNSSEC meant > that > no DNSSEC-dependent application has ever received investment. for example, > DANE is interesting in the SMTP market because that's small and geeky, but > will never be adopted by the Web because there are too many endpoints who > cannot do stub validation and too many who will never be able to. > Ah, thanks for clarifying. In that case, I would not characterize this as "DS throwing stubs under the bus", but just as a more general challenge with DNSSEC. A validating stub needs to not only have a clean path to issue and obtain DS responses from an upstream RDNS, but more generally, also be able to issue CD=1, EDNS/DO=1, queries for arbitrary record types including, critically DNSKEY. If any of this is blocked by a middlebox, there will be a problem. 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. I certainly agree that the clean path issue is a big impediment for something like DANE. I don't think I want to repeat the long and contentious history of the TLS DNSSEC chain extension effort which was designed to address this for the Web, but you can read my take on it here if you're bored: https://blog.apnic.net/2019/07/05/whither-dane/ 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. Shumon Huque
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
