Re: DNSSEC architecture vs reality

[Michael Thomas <[e-mail]>]

On 4/12/21 3:27 PM, Nico Williams wrote:
> On Mon, Apr 12, 2021 at 03:17:32PM -0700, Michael Thomas wrote:
>>> (1) may have been because of (2), and I believe (2) was because of
>>> internal technical and political issues.  I.e., I would not consider it
>>> dispositive that Google seemed to like DANE then gave up on it, though
>>> that and why they did certainly is germane.
>> Yes, that's what I would assume as well. Build it and they will come has a
>> sterling track record of failure in IETF.
> Building a technical spec is not enough, indeed.  DANE hasn't succeeded
> yet, and neither has DNSSEC.  But DANE is starting to gather steam (in
> no small part due to Viktor's efforts) in the realm of SMTP.  The fact
> that DANE was early for its time doesn't mean that the single root and
> unyielding name constraints aren't appealing or appealing enough to make
> a more serious try now.
>
> As noted, the tooling for DNSSEC has been substantially improved in
> recent years.  Implementations of DANE do exist now.  There are a number
> of missing elements, such as a TLS extension to staple DANE that
> supports authenticated denial of existence.  We're making progress
> though.  It may seem slow, but there may be a preference cascade at some
> point.  It may only take enough user-agent, and registrar / domain
> hosting services to provide this functionality to make it popular.

Of course it wouldn't necessarily take http to eek out some interesting 
stats. But web stuff is extremely bursty so it's pretty much its own 
thing. I made an update to my flow to show that the TLSA record could be 
speculatively fetched at address resolution time which could be done for 
DNSKEY and DS records too, especially if you know from previous 
interaction that they were there before. All of those considerations are 
going to interact with how it performs in reality.

The one thing that bugs me about DANE is its use of a native RR type. 
This is a well trodden argument of doing it proper and doing it in a 
deployable way. We know what happens when you do it the "right way" 
which is usually nothing at all. If it started to get popular, we could 
gin up a TXT record alternative though, I suppose. When we were doing 
DKIM at Cisco, our IT folks were incredibly accommodating, but 
implementing a new RR type in their infrastructure would have probably 
been a bridge too far. Heck, I wouldn't be surprised if Mark at Y! got 
told the same thing :)

Mike, slowly getting up to speed on a bunch of the details of the 
underlying protocols