On August 7, 2023 11:10:07 PM UTC, Dave Crocker <[email protected]> wrote: >On 8/7/2023 3:58 PM, Scott Kitterman wrote: >> I think a definition that describes a condition that's technically >> distinguishable from normal DKIM operations is essential if we are going to >> make any progress. > >Except that the draft notes that isn't possible. > >There's a fair amount of text in 1.1 that seeks to describe the nature of a >Replay attack, and distinguish it from 'normal' behavior as best as we can. > >A better, more objective and precise definition would be great. Please also >provide one for spam. > >If someone has actual substance to offer, to improve 1.1, please, please, >please do offer it. > >d/ > >ps. Unless it isn't clear what existing draft text I'm referring to: > >> During development of the DKIM specification, DKIM Replay was identified as >> only of hypothetical concern. However, that attack has become commonplace, >> particularly for systems: >> >> * >> >> Attackers create, obtain access, or compromise an account at some >> Originator that signs messages with DKIM >> >> * Attackers locate a Receiver that consumes DKIM to make a delivery >> decision. If the Receiver uses a reputation system with DKIM for >> delivery decisions, the attacker finds an Originator with a high >> reputation. >> * They send an email from that account to an external account also >> under their control. >> * This single message is delivered to the attacker's mailbox, giving >> them an email with a valid DKIM signature, for a domain with high >> reputation. >> * They then post the message to a new and large set of additional >> recipients at the Receiver. >> >> Internet Mail permits sending a message to addresses that are not listed in >> the content To:, Cc: or Bcc: header fields. Although DKIM covers portions of >> the message content, and can cover these header fields, it does not cover >> the envelope addresses, used by the email transport service, for determining >> handling behaviors. So this message can then be replayed to arbitrary >> thousands or millions of other recipients, none of whom were specified by >> the original author.That is, DKIM Replay takes a message with a valid DKIM >> signature, and distributes it widely to many additional recipients, without >> breaking the signature. >> >> * Further, a message used in a Replay Attack has the same attributes >> as some types of legitimate mail. That is, an individual, replayed >> message has no observable differences from a legitimate message.
Then I guess I don't know what we're doing. Solve a problem with a protocol change when the protocol can't tell the problematic case from normal usage seems like either the shortest working group ever or the longest. I would agree that there's a description of what's happening that is considered bad, but that's not the same thing as a technically distinct definition. Scott K _______________________________________________ Ietf-dkim mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-dkim
