Funny how "security experts" here complain about accidental non-repudiation misfeature of DKIM, but apparently being forced to do a bunch of crazy crap HTTPS forces you to do when all you need is content signature verification is perfectly fine with those same people. Security is becoming a field dominated by some bizarre corporate ideology.
I don't understand your point, content signature verification would have the same consequences that HTTPS for non-repudiation, no?
Also it's really different from DKIM: the problem with DKIM is that since the signature is part of the email itself, so unless the receiver bothers to strip it (why would they?) then it's stored forever in the metadata, even though arguably its use as an anti-spam feature stops being relevant once it's been delivered to the MUA. So basically every time you send an email through gmail you effectively also send a signature saying "I, Google, vouch that h4x0r@gmail.com did send this email" and the receiving end will keep this signature for as long as they keep the email.
HTTPS session keys however are not typically saved unless somebody goes out of their way to do it. As such it's a lot less likely to be used for blackmail in hindsight. In general people use archive.org to prove that some content used to exist in this scenario, not old HTTPS session dumps.
And like for DKIM the solution is fairly trivial if it's really an issue: every time you rotate your keys (which should be fairly frequent if you use something like letsencrypt) be sure to make the expired private keys available publicly to give you plausible deniability.
I have yet to hear a good argument against HTTPS everywhere honestly, it generally boils down to "but I don't want to do it" with some weak post-hoc justification for why it's bad.
It’s perfectly fine only to the people who already did it; there are visibly annoyed comment from people who haven’t yet because they think it’s pointless, too. The same issue exists with DNS-over-HTTPS: most people don’t want to have to take new and extra steps to monitor DNS traffic in their home or work, and the concept of having to do that work varies from annoying to offensive (whether they use them or not).
DNS-over-HTTPS is one in a long series of decisions that contradict the assumption that network operators deserve cleartext access to your traffic. I suppose we can thank the NSA’s Room 641A for inspiring the tech world to pivot to this view all those years ago. It’s finally reaching critical mass, and endpoint network operators are furious at having their sniffing/spying capabilities hindered.
Captive WiFi portals are next on that list of institutions that are at risk of failing. I can’t wait, personally.
What "crazy crap" are you talking about? I get that HTTPS might be overkill for some situations, but it's not difficult to use and every client device supports it. If you came up with your own signature-but-no-encryption protocol (maybe something similar to DKIM, actually?), nobody would support it. Even if they did, I'm sure that some people would use it when HTTPS is a better solution, just because they don't understand the tradeoffs.
A standardized overkill solution that covers most use cases is probably better than n+1 standards with different tradeoffs.
I'm not sure if that "security expert" note is pointed at me (I have not talked about DKIM at all, nor do I consider myself a security expert by any means).
I'm merely pointing out what is in my humble opinion, even when no sensitive data is traveling, the main reason why HTTPS should be everywhere. If you believe there are other easy to deploy and maintain solutions with the same amount of relevant user outreach, then by all means suggest them.
(I could of course point other reasons, like the fact that even if your website has no sensitive data it can still be scraped to build a profile of the visitor by a third party, etc).
Doing content signature verification securely would require all the same "crazy crap" that HTTPS does (certificates, CAs, OCSP, ACME, etc). The PKI is the hard part; once you have that there's very little reason not to encrypt as well as sign.
