On 2/13/23 9:43 PM, Evan Burke wrote:
On Fri, Feb 10, 2023 at 2:31 PM Michael Thomas <m...@mtcc.com> wrote:
On 2/10/23 2:10 PM, Evan Burke wrote:
The M3AAWG BCP will cover recommended header signing/oversigning
policies. I'll make sure that's shared here when it's published.
Any idea when that might drop?
I'll roughly summarize the guidance here for now. The primary audience
for these recommendations is senders/signers with high volume shared
signing domains; these domains are prime targets for replay because of
their good reputation. Other approaches exist, but these are the ones
that can generally be implemented relatively quickly.
- Screen new accounts based on industry standard methods
- Scan outbound mail for spam-like content, and restrict or block
sending based on results. Pay closer attention to new accounts, or
accounts that are otherwise high-risk.
- Monitor for signs of replay via abuse reports and third party tools
- Oversign Date and Subject headers
- Set signature expiration via x=, with expiration on the order of 30
minutes to a few days, depending on details of your signing processes
- After implementing oversigning and signature expiration, rotate keys
- Consider signing mail from new or higher risk accounts differently -
perhaps using a shorter signature expiration or different signing domain
Implied here is that Date and Subject are signed in the first place,
which in practice is almost always the case. In a small (n=35) survey
of my own personal mail last year, 97% of sending platforms signed
Subject, and 89% signed Date.
Top two most effective techniques here, in terms of minimizing
long-term viability of replay, are 1) signature expiration, and 2)
shorter expiration for higher-risk accounts.
I have to say that there is a fair amount of irony in my eyes going on
here. Even though I'm fairly skeptical about what we can actually do
about this, it's very ironic that x= was my idea (it was in the original
IIM draft) and that there was a lot of skepticism back then about its
utility which I had to push back on.
Have you considered something like rate limiting on the receiver side
for things with duplicate msg-id's? Aka, a tar pit, iirc?
And to be clear, what do you mean by "oversigning"? Is it something
different than just signing the Subject, etc, header in the first place?
Mike
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
