On Mon, Aug 7, 2023 at 3:58 PM Scott Kitterman <ietf-d...@kitterman.com> 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
