Stephen Farrell wrote:
> I guess Jim'll tell us what he wants.
That must be my cue.
The current threat analysis (draft-fenton-dkim-threats-01) is just a
start, to get us chartered. The part that will see the most expansion
is that on the Bad Acts (threats) themselves, particularly threats to
and involving the use of DKIM.
I'm going to be as inclusive as I can with respect to what we include.
If something is an actual threat, it is easier just to include it in the
document and move on than it is to debate whether it goes in or not.
However, to do this, I'll need everyone's help: the contributor of the
threat needs to provide something similar to what Stephen wrote
describing the threat, its impact, possible countermeasures, and
likelihood. For "countermeasures", I'd like to declare out-of-scope the
use of independent mechanisms such as SPF and CSV; I think those apply
more-or-less equally to all. I also prefer the term "likelihood" over
"probability", so that we encompass the difficulty of mounting the
attack, the chance it will succeed, and whether anyone is actually going
to try it.
In addition, I'd like to include a chart of threats with their
likelihood and impact rated as High/Medium/Low. Here are some suggested
guidelines (I'm open for suggestions) on how those might be scored:
Likelihood:
High: All users of DKIM should expect this attack on a frequent basis
Medium: Users of DKIM should expect this attack occasionally;
frequently for a few users
Low: Attack is expected to be rare and/or very infrequent
Impact:
High: Affects the verification of messages by an entire domain
or multiple domains
Medium: Affects the verification of messages by specific users,
MTAs, and/or bounded time periods
Low: Affects the verification of isolated individual messages only.
I hope to have a more complete outline in a few days; in the meantime,
be thinking of attacks.
Here are a few to think about:
- Replay (reputation "joe-job" and advertising subcategories)
- Body munging (attacks against canonicalization)
- Mishandling of messages with broken signatures
- Denial of service (several possibilities here)
- Privacy (leaking info to sender about recipient)
- Hash collisions
- Private key mis-appropriation/theft
- Publication of bogus key records
- De-publication of legitimate key records
- Look-alike domains (including internationalized domain names)
-Jim
_______________________________________________
ietf-dkim mailing list
http://dkim.org