Re: [Ietf-dkim] sender signing practices
On 2/6/23 10:34 AM, Alessandro Vesely wrote: On Sat 04/Feb/2023 04:45:15 +0100 Michael Thomas wrote: 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. Does that mean that, in case the submission server doesn't trust the current author, it should create a signature where To: and/or Subject: are not covered, in order to rise suspicion at receivers? That sounds convoluted. I still prefer i=bulshit...@gmail.com. No, I'm saying that the sender can publish what it does and what the receiver should expect. That no difference in kind to the "we sign everything" for p=. Like, say, sh=From|To|Subject|..." There are probably many other things that the sender can tell the receiver about their practices as well. That's why the original draft was called Sender Signing Practices. Mike ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] sender signing practices
On Sat 04/Feb/2023 04:45:15 +0100 Michael Thomas wrote: 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. Does that mean that, in case the submission server doesn't trust the current author, it should create a signature where To: and/or Subject: are not covered, in order to rise suspicion at receivers? That sounds convoluted. I still prefer i=bulshit...@gmail.com. Best Ale -- ___ 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/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
