Just a couple of comments on Jim's comments. I don't quote the text on which I
agree, unless I have to add to it.
On Tue 07/Mar/2023 23:46:18 +0100 Jim Fenton wrote:
To get things going, here are a few comments on
draft-chuang-dkim-replay-problem-01:
Section 1.1:
[...]
“Bcc header field”: There is no Bcc header field. That would contradict the
intent of bcc.
Bcc: is used by some command-line MUAs to derive the envelope. Besides, some
mailers copy Bcc:, one mailbox at a time, to each outgoing copy of the message,
which is sent it to the relevant recipient only.
Section 2:
“Spammer may intentionally leave out certain headers”: RFC 6376 (section 5.4,
last paragraph) recommends that signers sign all end-user visible header fields
to avoid exactly this problem. This is really low-hanging fruit for a best
practices document. I have no sympathy for domains that don’t sign (or
over-sign, if they’re not present) these header fields and then suffer replay
attacks.
For clarity, a clause should be added to explain the spammer's intent. For
example:
OLD
Taking advantage of the flexibility in DKIM to selectively sign headers, the
spammer may intentionally leave out certain headers such as To:, and Subject:
that can be added in later without damaging the existing DKIM signature.
NEW
Taking advantage of the extended practice of not signing even important header
fields if they are not present, the spammer may intentionally leave out some of
them such as To:, and Subject: that can be added in later without damaging DKIM
signatures which don't cover them.
While our chair has suggested we not focus on the solution space at this point,
I have a couple brief comments on section 4.
According to our chair's suggestion, I'd drop Section 4 entirely.
Instead, I wish someone adds some information on the volumes and consequences,
even anecdotal, of real cases. Apropos reactions, albeit digressing into
solution space, would be welcome in that context.
Best
Ale
--
_______________________________________________
Ietf-dkim mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-dkim
