Re: [ietf-dkim] Re: New DKIM threat analysis draft

[Jim Fenton]

Frank Ellermann wrote: Jim Fenton wrote: By "envelope-based" I presume you mean SPF, Sender ID Framework, and/or CSV. JFTR, Sender ID minus PRA is SPF, and PRA isn't envelope based. True; I mentioned it because I think SIDF could also be used to address replay issues. We should not create a normative dependency on any of these in the DKIM specs Most definitely, that would result in some "downref" effects. For your threat analysis no problem, that's only informational. I think they're worth mentioning in the threat analysis. You already have this point as "an DKIM PASS from an unknown stranger is not much better than an SPF PASS from an unknown stranger" (in other words, but that's how I read your 5.1 and 6.2). 5.2.2. is somewhat vague. For 5.2.1 and 5.2.3 you say what DKIM might do, or what it can't do. But in 5.2.2 you only state a problem without mentioning the good, bad, or ugly effects of DKIM. That's a good point, I should probably say something about that. DKIM is no FUSSP, there will be legit domains that don't use DKIM for at least years. The bad actors would then forge its addresses, sign it with their own throw-away domains, and naive users (5.1 + 6.2) could then erroneously "think" that they got a PASS "for" the forged identity. But they only got an "accountable signature", in the case 5.1 (repeated in 6.2) that means that an abuse report won't hit an innocent bystander. It's true that a lot more effective things can be done if the identity associated with the signature can be made visible to the recipient.  But that requires MUA changes, and there's no way to mandate that. So far that's 100% the same as SPF. Maybe you should mention that DKIM can be checked everywhere (not only at the "border") as long as nobody manipulates the DATA. Resulting in a minor "threat" of FPs behind many mailing lists => users intending to act on invalid signatures should white list these lists. Details about the funs of FWS canonicalization are probably unnecessary for your threat analyis, it's too special, and besides I hope that it can be solved for many relevant cases. I expect that we'll be tightening canonicalization in the next revision of the base draft, and hopefully that will be sufficient for the threat analysis for now. -Jim

_______________________________________________
ietf-dkim mailing list
http://dkim.org