ietf-dkim
[Top] [All Lists]

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

2005-10-13 02:08:39
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.

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.

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.

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.

                           Bye, Frank


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