[ietf-dkim] New DKIM threat analysis draft

[Jim Fenton]

Earl Hood wrote:

>(Catching up on mail)
>  
>
Welcome back!

>On September 27, 2005 at 14:53, Jim Fenton wrote:
>
>  
>
>>    ftp://ftpeng.cisco.com/fenton/draft-fenton-dkim-threats-00.html
>>    
>>
>
>My initial comments, sorry if some may be dups:
>
>* Introduction implies a different goal for DKIM than what the
>  draft spec states.  Here, it only mentions DKIM being used to
>  associate domain responsibility for a message vs "the sender of
>  the message was authorized to use a given email address."
>  
>
Good point; this was written somewhat after the base and SSP drafts and 
whatever description we use, it should be consistent.

>* Bad actors in claimed originator's unit may be technically
>  outside of the scope of DKIM, but it can affect its adoption.
>  I.e.  If domains are unable, or unwilling, to control bad
>  actors in their unit, then DKIM will be useless overhead.
>  
>
Sure; the point here was that there are other mechanisms that complement 
DKIM within the claimed originator's and recipients units.  DKIM isn't 
generally useful in these places, and other things need to be deployed 
to make this effective.

>  An obvious example is free email services like Yahoo, Hotmail, etc.
>  Using a replay attack as described in section 6.3, DKIM signatures
>  of such domains can be useless, hurting the effectiveness of all
>  DKIM signatures.
>  
>
I think of this as a separate issue from the previous paragraph, but 
yes, replay is a significant concern.

>* 4.3 implies the benefit of having MUA-based DKIM verification.
>  
>
That's only one way to deal with it.  Equally good is to have MTA-based 
DKIM verification and control the spoofing of Authentication-Results 
headers.

>* The document talks about "origin addresses", implying that DKIM
>  signatures are mainly applicable for such usages.  I.e. DKIM
>  signatures are for use by originating domains and not necessarily
>  any domain that wants to "claim responsibility" for a message.
>  This goes back to previous threads about DKIM scope and who should,
>  and should not, sign and when signing should occur.
>  
>
I can see where you get that impression, but the emphasis on origin 
addresses is just because such a claim has more easily described value 
than a claim of responsibility from some other domain.

>  I think there needs to be clear text somewhere on the scope of DKIM.
>  This will help determine the value DKIM offers and the security
>  threats to it.
>  
>
I'm guessing this should go in the introduction?

>* 5.2.1 does not state explicitly how DKIM is effective in dealing
>  with attacks mentioned in second paragraph.  As noted in past
>  discussions, mainly related to SSP, DKIM, as currently defined,
>  has holes allowing forgery to go undetected.
>  
>
I'll add some more detail.  The effectiveness comes from the fact that, 
if addresses from an address book were being used as From addresses on 
messages, the attacker would not normally be able to sign on behalf of 
these addresses.

>* 5.2.3 should mention the "window" of such, and similiar, attacks.
>  Is simple revocation (either via key or Doug's opaque ID method)
>  sufficient to minimize the damage and deter attackers?
>  
>
I expect the replay to happen effectively instantaneously, rendering the 
revocation techniques that have been discussed ineffective.

>* Attacks on canonicalization methods is not mentioned.  I.e. Bad
>  actors may exploit weakness in specific canonicalization methods to
>  allow messages to pass signature validation but contain different
>  content from what was originally signed.
>  
>
The list of attacks in section 6 is not intended to be exhaustive.  But 
canonicalization attacks should perhaps be in the Security 
Considerations of the base draft.

>* 6.3 should mention the use of complementary technologies, or
>  possible extensions to DKIM.  To provide protection against replay
>  as it is happening, envelope-based technologies will need to be
>  employed.  I'm not sure that systems that rely on reacting to the
>  attack after it has happened will be effective enough in deterring
>  attackers.
>  
>
By "envelope-based" I presume you mean SPF, Sender ID Framework, and/or 
CSV.  We should not create a normative dependency on any of these in the 
DKIM specs, but I think they're worth mentioning in the threat analysis.

-Jim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mipassoc.org/pipermail/ietf-dkim/attachments/20051012/e158ee64/attachment.html