I made essentially the same argument to people at Google BEFORE the DANE group was ever proposed. The answer they gave me then has not changed.
DANE was chartered over a decade ago. Individuals in that group made clear that no input was going to be accepted from anyone who was a part of the WebPKI world. The tactics used were intentionally exclusionary. Those of us pointing out the limitations of the proposed approach were never given a fair hearing.
It is now ten years since DANE was chartered. DANE has failed beyond the very limited application to SMTP which was never really covered. The argument for DANE was weak before LetsEncrypt was launched and it seems highly unlikely future events are going to change that.
The TLSA model is simply the wrong model. If you want to change the way discovery is done, you need to think about the full discovery chain. And not least because DOH is another factor in this mix.
DANE and DPRIV should have all been a part of one effort that should have included the introduction of SRV records for HTTP.
The key weakness in the DNS protocol is that the client-resolver interaction is of an entirely different character to resolver-authoritative and the current client-resolver interaction only supports requests for one record at a time.
The kick off meeting for DPRIV was quite interesting. There should be standing IESG instructions to prohibit chartering of any WG that is premised on the need to finish something in a year, so it is essential that it be done in exactly the way the proposers have already decided. Even more so when the results from DPRIV could be easily foreseen from the fact it was the same group that had hijacked DNS security policy with DANE.
I don't claim to always do the right thing but there are some folk who seem to keep doing the same thing with the same outcome and for some reason they get priority over folk who have actually built stuff that was successfully deployed and is in use.
We already have a widely adopted example where we ignored the
webpki folks too: DKIM. Certs are simply not needed in the vast
majority of cases. DKIM could be adapted for this too, and doesn't
have the downside of a new RR type which is always problematic. I
assume that the people doing DANE were looking at DKIM's success
as a template. Quite reasonably, IMO.
And I don't know how something that could reduce the message count to the original 3 way handshake is somehow the "wrong model". In what way? Is DKIM the wrong model too?
My larger point is that a Google-like company
could and should run experiments to reduce the message count to
3 again to finish off what Quic is trying to accomplish. That is
achievable, the only question is whether it's worth it which
experiments would show.
Mike
