ietf-dkim
[Top] [All Lists]

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

2005-10-12 14:20:35
(Catching up on mail)

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."

* 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.

  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.

* 4.3 implies the benefit of having MUA-based DKIM verification.

* 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 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.

* 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.

* 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?

* 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.

* 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.

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