Re: [Ietf-dkim] sender signing practices
On 2/3/23 6:25 PM, Murray S. Kucherawy wrote: But with respect to replay: Even if To and Cc are signed, there's nothing in DKIM requiring that they reflect any identities present in the envelope. That's not the point. The point is that they are leaving clues to that the message is suspicious. Not signing To and Subject looks very sketch. As I said: a preponderance of evidence. As always with spam detection. Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] sender signing practices
On 2/3/2023 6:25 PM, Murray S. Kucherawy wrote: But with respect to replay: Even if To and Cc are signed, there's nothing in DKIM requiring that they reflect any identities present in the envelope. Exactly. The problem being experienced does not have changes to the content. It has re-use of /exactly/ the same message as was originally sent. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] sender signing practices
On Fri, Feb 3, 2023 at 5:14 PM Michael Thomas wrote: > That said, I don't know why we didn't make To:, Cc: and Subject: > mandatory signed fields. But even if it's not mandatory, that should be > a signal that the message should be given increased scrutiny. > RFC 4871 included those as SHOULD when selecting what to sign. In RFC 6376 we backed off of that to more general guidance rather than listing specific header fields. In RFC 5451, we carved out the possibility that a verifier might decide a DKIM signature not covering Subject (for example) might reject such a signature even if it validates because it's not covering important displayed content. I know OpenDKIM exposed this as a configuration option. But with respect to replay: Even if To and Cc are signed, there's nothing in DKIM requiring that they reflect any identities present in the envelope. -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
[Ietf-dkim] sender signing practices
The original SSP proposal was focused on whether a receiver should expect a valid signature from the domain, but it was more open ended than that. It was really intended as a way for the sending domain to describe to any receivers what it does as a matter of policy. I noticed that in draft-chuang-dkim-replay-problem they mentioned that spammers sometimes leave the To and/or Subject unsigned. Aside from wondering how they coax a provider whose reputation they are trying to use to do that, it seems to me this might be an instance of where the sender could tell the receiver what to expect. There may be other things that the sender can inform receivers about their policies and practices to give then more clues as to spaminess or abuse. I know that DMARC is a follow on to SSP/ADSP which so it is now out of scope for this wg which is sort of a pity since it makes the process much harder and they are not likely to be interested in anything other than what they are currently doing. But we should keep in mind that that could be part of the overall solution set. That said, I don't know why we didn't make To:, Cc: and Subject: mandatory signed fields. But even if it's not mandatory, that should be a signal that the message should be given increased scrutiny. Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Chartering update
On 2/2/23 4:06 PM, Scott Kitterman wrote: There is an existing draft of a problem statement, so there's at least a starting point to consider. I think discussion about what's needed is probably more useful relative to a specific draft than in the abstract: https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/ Other than removing the ARC references, this seems like a good start. I sort of like the proposed solution space, but several of them could be tried today or have huge downsides. Bcc, for example, would be a security fail if it were in the message headers. Caching signatures could be tried today but I don't see how that can be distinguished from, say, a mailing list. But it could be rewritten in terms of not solutions but possible angles to attack the problem with pros and cons. It may well be that a preponderance of evidence could be useful. We could list off a bunch of other possible clues too. For one, what is the reputation of the To: address's domain? There are surely more. Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
