[ih] DKIM history, was IETF relevance (was Memories of Flag Day?)

[Michael Thomas]

On 8/29/23 8:04 PM, John Levine wrote:
> It appears that Michael Thomas via Internet-history <enervatron at gmail.com> said:
>>> I also have no idea what your reference to DNSSec and Domainkeys is
>>> about, since DK didn't involve DNSSec.
>> IIM protected the integrity of fetching the key record using TLS. DNSSec
>> was never deployed widely. So yes, by all means let's ignore that DK's
>> security for fetching the selector never materialized where IIM got it
>> right using TLS. Alice, Bob and Eve entered the chat.
> Depends on what your goals are. At least until Let's Encrypt came
> along, TLS certs were a lot harder to deploy than just publishing a
> key record in the DNS. People use DKIM to associate a domain with a
> message to develop reputations for mail filtering, not for stronger
> assertions or non-repudiation. For that purpose it's been a wild
> success, partly due to its relatively easy deployment.
>
> On the other hand, if you want high strength certificate signatures on
> your mail, S/MIME has always been there and is notable for its lack of
> use outside of some niche applications.
>
> I don't think I've ever seen the kind of attack that DNSSEC defends
> against in the wild, certainly not against DKIM records, so in
> practice it's secure enough. Perhaps by accident we made the right
> tradeoff.

Email is relatively low value. I'd never trust some DANE implementation 
that wasn't protected by DNSSec for my bank, for example. But by 2004 
getting a cert onto a web server was completely routine and the number 
of web sites using it was immense. It turns out that the overhead of 
http wasn't an issue in the long run as evidenced by DoH. Those of us 
who wrote code were worried about the overhead of per message RSA 
signatures were proven wrong with actual evidence. The same should have 
been done for http fetching of keys. It's sort of the point of the 
"running code" maxim that people far too often forget, especially by 
people who don't write code.

So yes, it was a mistake. We could have a had a very secure solution 
with proven and widely deployed technology with a pattern that could be 
replicated in other solutions so that we did get complete messes like 
STIR/SHAKEN and its use of x.509 when simple naked public key use would 
have been completely sufficient. X.509 for TLS is legacy and we have no 
other choice. There are vanishingly few other things where it's needed 
and we shouldn't keep propagating it. We now know that we can't count on 
DNSSec deployment. It was an unfortunate tradeoff getting something out 
the door vs. security. That is the actual history.

Mike