Here's my rationale for the values I put in the document regarding Signed Message Replay.
There should perhaps be a third column in addition to "impact" and "likelihood"; let's call it "utility". The Signed Message Replay attack in section 4.1.5 differs from nearly all of the other attacks in that the attacker can't do everything they'd perhaps like. If they steal the private key for the domain, they can sign any message they like and send out advertising or objectionable material, etc. With the SMR attack they can't do that -- they can only inappropriately distribute things that are already signed. This can be bad for the domain's reputation, but if the attacker is looking to sell pharmecuticals, this isn't going to help. So I marked this attack as "low impact", in part because of its limited utility, and in part because (in accordance with the definitions in section 1.2) this attack deals with individual messages -- it doesn't affect the majority of the messages from the domain, only those selected by the attacker for replay. Perhaps the definitions need adjusting but I think we need some objective means for scoring the threats. I do recognize my role on this is as a document editor, and I will adjust the document to group consensus, but I wanted you to know where I was coming from. -Jim Frank Ellermann wrote: > Douglas Otis wrote: > > >>> 4.1.5. >>> > > >> The Very High was used to make a point. Just High would be >> fine. >> > > Your point is clear. What you say is that MONs shouldn't sign > mails if they have no MoU with the (final) MRN to protect this > signature. Otherwise the bad guys abuse this signature in a > replay attack against the reputation of the MON. > > And you say that the _impact_ is HIGH. In addition to a HIGH > likelihood. That sounds fairly serious, I'd be interested to > hear some other opinions about this. Your proposed workaround > is a bit too esoteric for my tastes, and IFF your analysis is > correct that could be a showstopper. Is the "likelihood HIGH" > maybe a bit exaggerated ? > Bye, Frank > > > _______________________________________________ > ietf-dkim mailing list > http://dkim.org > > _______________________________________________ ietf-dkim mailing list http://dkim.org
