ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] New Issue: 4.2 needs new Attack Item: InconsistentSignature vs Policy Attacks

2006-02-01 07:57:58
Stephen,

When it is outlined this way, high potential and most probable to occur
threats are minimized.

If we want to learn from the past....

Atleast 80-84% of all SPF policies seen by SMTP receivers are NEUTRAL
(relaxed) policies.  Among these, atleast 60%, are Bad Actors exploiting
a RELAXED domain policy.    This is verified by using a CBV (Callback
Verification) process. Other systems have used a GreyListing concept to
verify this.

Since we are one of the few companies using a non-standard CBV to
perform a "double checking" process to stop the true bad 60% of these
80% Neutral Polices, DKIM without its own DOUBLE CHECKING SSP concept
will fall thru the crack.

There is no reason to believe that DKIM will not have the same form
of inconsistent signature/policy (or Mixed Policy) exploitations.

The TA seems to be framed mostly around from an administrators and DNS
point of view and it lacks the implementators point of view.  While the
current TA threats outlined are real, the most probable threats when it
comes to implementation are ignored.

This will be my last statement on this question on whether it should be
added to the TA or not.  But this whole idea will be closely watched,
because if ignored in the final analysis, the victims of such neglect
will be SMTP operators (both DKIM and NON-DKIM compliant) and there
users.  From an engineering ethical standpoint, I simply can't let that
go untold.  Sorry if this rubs others, but that is a honest assessment
of the issue.


--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com






----- Original Message -----
From: "Stephen Farrell" <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
To: "Jim Fenton" <fenton(_at_)cisco(_dot_)com>
Cc: "IETF-DKIM" <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Tuesday, January 31, 2006 6:13 PM
Subject: Re: [ietf-dkim] New Issue: 4.2 needs new Attack Item:
InconsistentSignature vs Policy Attacks



Hi Jim, All,

Does the following make sense?

In section 4.1 we include a couple of vulnerabilities where an
exploit would depend on the DNS being poisoned or otherwise
containing bad values (e.g. 4.1.12).

Since we're also proposing to use the DNS to store policy
assertions then there should be some analogous threat in 4.2,
perhaps one named something like "applying the wrong policy".

One attack might be to delete everything to do with DKIM or
to put in a very open policy assertion so that unsigned
mail or 3-rd party signed mail would no longer look
suspicious.

I guess this could achieve a similar effect to replacing the
public key, but at less (run-time) cost to the attacker. I'd
further guess that replacing the public key would have higher
impact than this putative threat, but that the likelihoods
would be the same.

I'm not saying that this is compelling, but I guess it makes
a certain amount of sense in the abstract.

If so, the question is whether its worth including in the
document?

Stephen.

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



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