On Sun, Apr 11, 2021 at 3:34 PM Michael Thomas <mike@xxxxxxxx> wrote:
On 4/11/21 12:11 PM, Phillip Hallam-Baker wrote:
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.
That is completely false. I was a member of the DKIM working group and its predecessors. Two years before the DKIM WG was started, I designed a DNS based key credentialing scheme together with a major technology vendor. This was demonstrated to Yahoo by my CEO, Stratton Sclavos before the date of the Yahoo patent claim.
The history here is that about a year earlier, I had had discussions with Jon Callas, then CTO of PGP to see if we could persuade the market to move beyond the S/MIME vs PGP format war. The thing that ultimately prevented that work getting off the ground was not DKIM itself but the spam crisis that had prompted it. It was clearly not time to propose a second, different scheme. Some of the proposals I made in that group were intended to keep the door open to progress towards an encryption solution.
I attended every plenary and interim meeting of DKIM and was in constant contact with my peers in the wider industry.
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.
DANE works in a very different way and its cardinal sin is to mix publication of security policy with publication of keys.
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?
DKIM is very definitely the wrong model and we knew that when we wrote the spec. DKIM is simply the best model that was possible within the time frame and with the vast and ugly legacy of SMTP deployment. It would have been even uglier if not for SPF giving us some breathing room.
Given where we are now with all SMTP using STARTTLS, I would probably look to implement TLS client auth instead which would allow fast restart to amortize the public key operations. But thats not where we were then.
