Well, at least DMARC is also necessary, since if you recieve an email lacking a DKIM signature, you can’t know if the email should have had a DKIM signature unless there is a DMARC record configured for the sender’s domain.
Why not take the stance that every email should have a DKIM signature? Just like how we moved to "every website should use https". If you don't, your untrusted by default.
Google is slowly moving to reject mail that doesn't pass DMARC no matter the domain settings; it sounds like they are currently rejecting a percentage of messages that fail DMARC.
The issue mentioned in the paper related to SPF is due to adding third parties to the SPF record who then allow spoofing (see table 3 at the top of page 9 in the paper for a summary of the four issues they describe). Hopefully, those third parties will fix that and more mail admins will be aware of the potential negative effects of adding a third party to SPF. It doesn't seem like SPF causes much trouble and if it was possible for DMARC to specify that both SPF and DKIM must validate then that would help in the case of issues with the DKIM signature cryptography. DKIM has a replay issue, although that is not as bad if the to and date fields are signed.
If they're doing that, that seems like a move intended to prevent forwarding rather than one that's actually necessary for DKIM? Again, I don't see why DKIM isn't enough here. Like you said, replay attacks only work if you don't do DKIM properly, i.e. if you avoid signing some of the initial headers. So how about just... require them to be signed? Sign the message ID, sign the date, sign the addressees, sign the body... sign everything. If you don't, you're assumed to be risky, just like with http://. Problem solved, no?
DMARC is DKIM or SPF so requiring DMARC part of the way to what you are suggesting. There is still a replay possibility with DKIM even if limited to replaying the exact same message (unless providers or email clients track already seen messages until DKIM expiration, which could happen but I don't think is happening at this point). I'm not an expert just someone trying to find a security focused email provider with minimally reasonable privacy policies that doesn't randomly drop email (which unfortunately doesn't seem to exist :( ) so I'm not sure why things are the way they are. Why SPF exists might just be due to being earlier and there not being any strong reason to stop using it.
Even Google and Microsoft aren't able to simply require whatever they want without a long transition period. I'm fairly sure Microsoft would like to make email entirely proprietary (and some of the issues almost only apply to them so they aren't likely to be the ones to improve email security). As best I can tell the people with the most direct financial interest in email are the marketers, which isn't a great situation for real improvement (BIMI seems primarily designed to replace the lost income from browsers dropping EV certificates while having similar issues). And security is a hard sell for anything it seems. So all in all I think we are lucky that Google has been doing as much as they have been. A number of old timers already complain about how it isn't really email any more. If Google did want to eventually require DKIM the path to get there would likely still look like what they have been doing.
There has also been recent activity just this year to improve the S/MIME situation (best practices document) and in a lot of ways requiring email to be signed by the sender rather than the sender's provider would be more helpful than requiring DKIM over SPF (although it isn't ideal to tie email to the CA system). Possibly we will see a push in that direction at some point.
> There is still a replay possibility with DKIM even if limited to replaying the exact same message (unless providers or email clients track already seen messages until DKIM expiration, which could happen but I don't think is happening at this point).
IIRC Gmail deduplicates based on Message-ID. But even if you replay an identical message... the date would still land it next to the original. So worst case you have two copies of the same thing next to each other. Which can (and already does!) happen occasionally when a server resends a message for whatever reason. It's hardly an issue.
Thanks! And good that Google at least likely deals with it ok. Just as a general thing it is a good idea to be very careful about replay possibilities and I think you are a bit too casually dismissive. Not every provider stores email forever (although storing just the DKIM signature could be done without too much trouble) and there are circumstances where receiving the same message as previously to a cleared inbox might not be an obvious duplicate if you don't happen to look at the date (which is not something I usually do when looking at email). Of course, this is already a potential issue today.
It is if the only thing preventing seeing a resent message as new is the recipient looking at the date or message id. Certainly it is arguable that the client and/or provider tracking seen signatures is a reasonable way to prevent it, but this isn't universally the case at this point and SPF if required (which it never is now unless DKIM isn't used at all) would at least prevent most third parties from doing this (at least without IP spoofing which would be disruptive to do bidirectionally). Not that this is necessarily a sufficient reason to justify using SPF over DKIM only just that it is a consideration. I don't know SMTP enough to know if someone between two servers who can block an encrypted connection at just the right point could cause the sending server to resend a delivered message but I would guess that might be possible. MTA-STS seems infrequently used at this point so currently someone between two servers could likely prevent the use of encryption.
