(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."
I believe this to simply be a case of the draft specs being a bit behind the
times.
* 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.
I think this is a point worth mentioning.
* 4.3 implies the benefit of having MUA-based DKIM verification.
I think the implication relies on a premise that is unlikely to be
true in practice, specifically, that there won't be some mechanism in
place to detect and deal with bad actors within an administrative domain.
For example, I've seen a marked increase in the number of setups that require
authenticated connections from all clients to send mail.
But regardless, I think this is all outside the scope of the current effort. I
suppose we could note that other mechanisms may come into play within an
organization to thwart attacks within an organization, but that's about
as far as we need to go.
* 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.
I have no problem with this, although I am somewhat at a loss as to what
form such test would take.
* 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.
It may be difficult to nail this down now given the immaturity of the relevant
specifications.
* 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?
Seems reasonable to me.
* 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.
This most certainly needs to be present.
* 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.
I really don't think we should be discussing additional technologies
here.
Ned
_______________________________________________
ietf-dkim mailing list
http://dkim.org