Re: [Ietf-dkim] draft-ietf-dkim-replay-problem comments
On Tue 08/Aug/2023 16:47:23 + Murray S. Kucherawy wrote: On Tue, Aug 8, 2023 at 9:25 AM Alessandro Vesely wrote: On Tue 08/Aug/2023 14:47:37 + Murray S. Kucherawy wrote: On Tue, Aug 8, 2023 at 7:17 AM Scott Kitterman wrote: That's true of all indirect mail flows. It's not a distinguishing feature of the attack. Quite right, making this harder to pin down. But, to Alessandro's point, I do think the description in the document is accurate. Agreed, except for narrating an actual case. However widespread, there are people like me who never recognized a replay attack. What do you mean by "narrating an actual case"? Section 1.1 does contain a narrative of how one executes the attack. Yes, it says DKIM Replay is impossible to detect or prevent with current standards and practices. However, it must have been recognized well enough to grasp the described modus operandi. Are you talking about a narration of how one detects the attack, as distinct from a typical indirect mail flow? I guess a replay attack must engage multiple abuse teams, because of the size. Is the alarm triggered by users reporting many messages as spam? How many abuse teams at different organizations get involved? What is the size of the attack? What emergency measures are taken? At what stage does it become clear that a spam tide is a Replay Attack? What difference does it make such recognition? I admit these questions are much out of curiosity, but knowing those details could help framing possible solutions. Being completely ignorant about operations at large providers, I don't understand why the research steadfastly turns toward hard flying protocol changes rather than, for example, also investigating how to tune signing policies based on exchanged user reputation, or fast recognition of signed body hashes when they re-emerge from unexpected sources. Best Ale -- ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] draft-ietf-dkim-replay-problem comments
On Tue, Aug 8, 2023 at 9:25 AM Alessandro Vesely wrote: > On Tue 08/Aug/2023 14:47:37 + Murray S. Kucherawy wrote: > > On Tue, Aug 8, 2023 at 7:17 AM Scott Kitterman > wrote: > > > >> That's true of all indirect mail flows. It's not a distinguishing > feature > >> of the attack. > > > > Quite right, making this harder to pin down. > > > > But, to Alessandro's point, I do think the description in the document is > > accurate. > > Agreed, except for narrating an actual case. However widespread, there > are > people like me who never recognized a replay attack. > What do you mean by "narrating an actual case"? Section 1.1 does contain a narrative of how one executes the attack. Are you talking about a narration of how one detects the attack, as distinct from a typical indirect mail flow? -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] draft-ietf-dkim-replay-problem comments
On Tue 08/Aug/2023 14:47:37 + Murray S. Kucherawy wrote: On Tue, Aug 8, 2023 at 7:17 AM Scott Kitterman wrote: That's true of all indirect mail flows. It's not a distinguishing feature of the attack. Quite right, making this harder to pin down. But, to Alessandro's point, I do think the description in the document is accurate. Agreed, except for narrating an actual case. However widespread, there are people like me who never recognized a replay attack. Best Ale -- ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] draft-ietf-dkim-replay-problem comments
On Tue, Aug 8, 2023 at 7:17 AM Scott Kitterman wrote: > That's true of all indirect mail flows. It's not a distinguishing feature > of the attack. > Quite right, making this harder to pin down. But, to Alessandro's point, I do think the description in the document is accurate. -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] draft-ietf-dkim-replay-problem comments
On August 8, 2023 2:08:05 PM UTC, "Murray S. Kucherawy" wrote: >On Tue, Aug 8, 2023 at 2:16 AM Alessandro Vesely wrote: > >> On Mon 07/Aug/2023 23:52:02 + Scott Kitterman wrote: >> > On Monday, August 7, 2023 7:47:47 PM EDT Murray S. Kucherawy wrote: >> >> >> >> I think the document does describe the attack. An instance of the >> attack >> >> is when a replayed message lands someplace it wasn't originally >> intended to >> >> land, assuming normal usage. >> >> That's ambiguous. Obviously, since the attack was planned, it may well be >> that the potential victims were originally intended. The meaning is >> tweaked by the "normal usage" assumption, which could be interpreted as >> trying to pretend that the message author wasn't aware that the message >> was >> going to be replayed...? >> > >I don't understand what ambiguity you're talking about. > >The document lays out how the attack is accomplished. It also indicates >that the only difference between typical DKIM operation (the original >recipient set is the only recipient set) and the attack (the final >recipient set is not the same). ... That's true of all indirect mail flows. It's not a distinguishing feature of the attack. Scott K ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] draft-ietf-dkim-replay-problem comments
On Tue, Aug 8, 2023 at 2:16 AM Alessandro Vesely wrote: > On Mon 07/Aug/2023 23:52:02 + Scott Kitterman wrote: > > On Monday, August 7, 2023 7:47:47 PM EDT Murray S. Kucherawy wrote: > >> > >> I think the document does describe the attack. An instance of the > attack > >> is when a replayed message lands someplace it wasn't originally > intended to > >> land, assuming normal usage. > > That's ambiguous. Obviously, since the attack was planned, it may well be > that the potential victims were originally intended. The meaning is > tweaked by the "normal usage" assumption, which could be interpreted as > trying to pretend that the message author wasn't aware that the message > was > going to be replayed...? > I don't understand what ambiguity you're talking about. The document lays out how the attack is accomplished. It also indicates that the only difference between typical DKIM operation (the original recipient set is the only recipient set) and the attack (the final recipient set is not the same). > >> But my point above is simpler: "Replay Attack", when capitalized that > way, > >> has me going to look for a formal definition of that term someplace. > That > >> is, if we're going to use it that way, we should define it that way. > So, > >> just add it to the Glossary at least, or say in Section 1.1 that this > term, > >> in this document, means the attack described by that section. Or > something. > > > Would it be enough to say "Replay Attacks are described in Section 8.6 of > DKIM", somewhere in Section 1.1 of the I-D? > Sure. > > It will be interesting to see what develops. It's not a mystery that I'm > > skeptical of a protocol solution to the issue. > > The definition cannot include a method to recognize the attack. The I-D > implies that attacks are being recognized (became commonplace), but omits > the anecdotical narration of how it happens. > Including a sentence or two about how the attack is recognized, even outside of the protocol, would indeed be helpful. -MSK ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] draft-ietf-dkim-replay-problem comments
On Mon 07/Aug/2023 23:52:02 + Scott Kitterman wrote: On Monday, August 7, 2023 7:47:47 PM EDT Murray S. Kucherawy wrote: I think the document does describe the attack. An instance of the attack is when a replayed message lands someplace it wasn't originally intended to land, assuming normal usage. That's ambiguous. Obviously, since the attack was planned, it may well be that the potential victims were originally intended. The meaning is tweaked by the "normal usage" assumption, which could be interpreted as trying to pretend that the message author wasn't aware that the message was going to be replayed...? But my point above is simpler: "Replay Attack", when capitalized that way, has me going to look for a formal definition of that term someplace. That is, if we're going to use it that way, we should define it that way. So, just add it to the Glossary at least, or say in Section 1.1 that this term, in this document, means the attack described by that section. Or something. Would it be enough to say "Replay Attacks are described in Section 8.6 of DKIM", somewhere in Section 1.1 of the I-D? I see your point. Thanks, It will be interesting to see what develops. It's not a mystery that I'm skeptical of a protocol solution to the issue. The definition cannot include a method to recognize the attack. The I-D implies that attacks are being recognized (became commonplace), but omits the anecdotical narration of how it happens. Best Ale -- ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] draft-ietf-dkim-replay-problem comments
On Monday, August 7, 2023 7:47:47 PM EDT Murray S. Kucherawy wrote: > On Mon, Aug 7, 2023 at 3:58 PM Scott Kitterman > > wrote: > > On Monday, August 7, 2023 6:53:19 PM EDT Murray S. Kucherawy wrote: > > ... > > > > > (2) Throughout the document, the proper term "Replay Attack" (and > > > > sometimes > > > > > "Replay") is used, but it's never directly defined. I don't think you > > > > need > > > > > it to be formal, but if you really want to do it that way, please add a > > > definition for it. > > > > ... > > > > 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. "I know it when I see it" may work for the US Supreme > > Court, but it's not adequate here. > > I think the document does describe the attack. An instance of the attack > is when a replayed message lands someplace it wasn't originally intended to > land, assuming normal usage. > > The document also describes that the payload itself in normal usage is > indistinguishable from an instance of the attack; the obvious implication > is that there's no solution based solely on the payload format. > > Your point that we possibly can't go much further than that is one for the > WG to deliberate, to be sure. And I suggest that that's one possible > outcome of this WG. > > But my point above is simpler: "Replay Attack", when capitalized that way, > has me going to look for a formal definition of that term someplace. That > is, if we're going to use it that way, we should define it that way. So, > just add it to the Glossary at least, or say in Section 1.1 that this term, > in this document, means the attack described by that section. Or something. I see your point. Thanks, It will be interesting to see what develops. It's not a mystery that I'm skeptical of a protocol solution to the issue. Scott k ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] draft-ietf-dkim-replay-problem comments
On Mon, Aug 7, 2023 at 3:58 PM Scott Kitterman wrote: > On Monday, August 7, 2023 6:53:19 PM EDT Murray S. Kucherawy wrote: > ... > > (2) Throughout the document, the proper term "Replay Attack" (and > sometimes > > "Replay") is used, but it's never directly defined. I don't think you > need > > it to be formal, but if you really want to do it that way, please add a > > definition for it. > ... > > 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. "I know it when I see it" may work for the US Supreme > Court, but it's not adequate here. > I think the document does describe the attack. An instance of the attack is when a replayed message lands someplace it wasn't originally intended to land, assuming normal usage. The document also describes that the payload itself in normal usage is indistinguishable from an instance of the attack; the obvious implication is that there's no solution based solely on the payload format. Your point that we possibly can't go much further than that is one for the WG to deliberate, to be sure. And I suggest that that's one possible outcome of this WG. But my point above is simpler: "Replay Attack", when capitalized that way, has me going to look for a formal definition of that term someplace. That is, if we're going to use it that way, we should define it that way. So, just add it to the Glossary at least, or say in Section 1.1 that this term, in this document, means the attack described by that section. Or something. -MSK, participating ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] draft-ietf-dkim-replay-problem comments
On August 7, 2023 11:10:07 PM UTC, Dave Crocker 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 Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] draft-ietf-dkim-replay-problem comments
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. -- 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] draft-ietf-dkim-replay-problem comments
On Monday, August 7, 2023 6:53:19 PM EDT Murray S. Kucherawy wrote: ... > (2) Throughout the document, the proper term "Replay Attack" (and sometimes > "Replay") is used, but it's never directly defined. I don't think you need > it to be formal, but if you really want to do it that way, please add a > definition for it. ... 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. "I know it when I see it" may work for the US Supreme Court, but it's not adequate here. Scott K ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
