On Sun, Apr 11, 2021 at 3:34 PM Michael Thomas <mike@xxxxxxxx> wrote:
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.
Uh, Jim and I didn't use certificates in the design of IIM and
neither did Mark with DK. Since the three of us were the basis of
the combined protocol I think I have a little bit of insight into
our thinking. So yes, we ignored the webpki guys including you.
Thank goodness for that because a trip down that rat hole would
have doomed it.
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.
We showed Jon our design before we released it as a sanity check.
At no time did he say anything about certificate based approaches.
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.
The original IIM design used SRV records to find key servers.
It's looking more and more that it was actually the right design.
But Cisco was nobody with email so it was easier to go with flow
of DK. I was the original one in our group to advocate that and
I'm at peace with that.
I have no idea how something that signs billions and billions of messages a day can be considered the "wrong model" whatever that means.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.
TLS doesn't do anything to help the end-to-end authentication.
Mike
