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

From: "Hector Santos" <[email-masked]>
Date: Wed, 1 Feb 2006 09:45:31 -0500

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" <[email-masked]>
To: "Jim Fenton" <[email-masked]>
Cc: "IETF-DKIM" <[email-masked]>
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

---

From: Jim Fenton <[email-masked]>
Date: Wed, 01 Feb 2006 15:58:49 -0800

> perhaps one named something like "applying the wrong policy".
This makes sense to me.  There is an analogous attack to 4.1.12 against
SSP, which I will add to section 4.2.  I'm not sure this is quite what
was being described earlier in this message thread, but this one is clear.
> impact than this putative threat, but that the likelihoods
By the definition of "impact", I think it's about the same:  it can
affect the verification of an entire domain.  The attacker might also
wish to make valid mail from a domain look suspicious, and push out a
"NONE" policy.  If it differs from 4.1.12 at all, it's in terms of the
capability that the attack gives you:  it allows one to make mail look
more or less suspicious, but doesn't help them to create a valid signature.
> If so, the question is whether its worth including in the
I think so.

-Jim

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 02 Feb 2006 06:59:33 +0100

Hector Santos wrote:

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

It's not possible to "exploit" NEUTRAL, as it's by definion the
same as NONE.  What's so unusual with 60% spam ?  Apparently a
bit lower than the average.  As with DKIM the only real exploit
is a PASS from a white-listed source.

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

Any o=~ spam without signature is no exploit.  The domain owner
has reasons for o=~, among them the valid reason "not all of my
mails are signed".

NEUTRAL or unsigned spam is the same spam as it always was, no
"exploit".  Some spammers just ignore DKIM or SPF or your CBV,
and if you catch them with SPF FAIL or DKIM STRONG or your CBV
they bite the dust.  Working as designed.

                             Bye, Frank

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 2 Feb 2006 09:59:23 -0500

----- Original Message -----
From: "Frank Ellermann" <[email-masked]>
To: <[email-masked]>

> is a PASS from a white-listed source.

Good points. It would had been better to just say relaxed policies, in
the case of SPF; Neutral, SoftFail.

The issue of PASS is true. Why should we trust it?

But we don't have must more we can do here but to apply or augment
optional and non-standard tracking concepts.

However, what you want to make sure you don't allow fall thru the cracks
are the mix policy and protocol inconsistencies, and that might include
mixing DKIM with other methods as well at the implementation level.  But
at the very least, the protocol level.

The overall goal, atleast from my (SSI) perspective, is providing
consumer confidence in your product offerings. And that includes doing a
diligent job in making sure what you are offering has a high payoff, it
is transparent as much as possible and has no vulnerabilities ignored or
neglected.

The first goal is to make sure that the "rules" are followed as it is
expected to be followed.  Any fault detected, in whatever form that may
be, is how your protection is realized.  When the rules are relaxed,
fault detection is minimized.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 2 Feb 2006 16:30:42 -0800

On Feb 2, 2006, at 6:59 AM, Hector Santos wrote:

>>  As with DKIM the only real exploit is a PASS from a white-listed  
>> source.
>

DKIM is about restoring trust for transactional emails.  A domain  
should be assumed untrusted until otherwise vetted as trustworthy.   
When the signature is verified, the white-listed source is being  
trusted.  However, white-listing a signing domain may include both  
trustworthy and untrusted users or signing applications.  There  
should be a means where the signing-domain is able to offer guidance  
with respect to which internal sources are trustworthy and which are  
not.  After all, a single signed message can be replicated widely and  
wreck havoc.  Such havoc may impact the domain's trusted status.

> optional and non-standard tracking concepts.

A bit in the key verifying the message's signature can note whether  
the specific internal source for the message is considered  
trustworthy.  Such an assertion could help sort out trusted and non- 
trusted messages.  The signing domain would be motivated to protect  
their own trustworthy status and ensure messages obtaining a  
"trusted" status are indeed from trustworthy sources.  It is  
important to minimize the amount of "trusted" abuse allowed to slip  
through.  This concern would be due to evaluation costs, as this  
would be based upon message content.  :-(

> However, what you want to make sure you don't allow fall thru the  
> cracks are the mix policy and protocol inconsistencies, and that  
> might include mixing DKIM with other methods as well at the  
> implementation level.  But at the very least, the protocol level.

Just one small aspect of a violation of trust would be an  
"inappropriate" use of header fields.  Even this apparent  
inappropriate use of a header field would depend upon the role of the  
signing-domain and whether the signing domain is also asserting the  
message to be trustworthy.  For a typical list-server, none of the  
list's messages should be marked as trustworthy.  Perhaps messages  
from the list's administrator could be marked as trustworthy, in  
which case headers will likely not be an issue.

DKIM is independent of the message envelope.  This independence means  
that DKIM can _not_ be used to abate spam.   Third-party signing  
policies will likely play little, if any, role in evaluating a  
violation of trust.  When the signing-domain is trustworthy (third- 
party or not) and indicates the message can be trusted, the email- 
address that appears in the header will likely be of little concern,  
unless or until there is a report of a violation of trust.  Those  
domains considered trustworthy should also held accountable for any  
criminal acts that they both sign and _mark_ as trustworthy.

Not marking the message trustworthy should mean the message is simply  
treated as not signed, irrespective as to whether the domain itself  
is trustworthy.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 2 Feb 2006 21:10:51 -0500

Doug,

I agree with you 100%, but this is how my brain is wired (excuse my
chemical engineering hat):

Think of a perfect circle used for monitoring variables of a process,
i.e. pressures, temperatures, etc.  A perfect circle represents
equilibrium and steady state operations.  Any deviation of this perfect
circle shape means there is a difference, a "delta" in the system.
Could it be a faulty value? A leak? A built up of corrosion in
heterogeneous material interfaces or curvatures?

Think of a perfect harmony, a song, a tune mapped to the health of your
blood, urine, etc. Any deviation in the chemical levels creates kinks,
squeaks in the tones of the harmony.

Take your car. You hear a strange noise in the engine you never
expected, maybe it is shaking a lot. Most likely there is something
going
on or just the beginning of things to come.  A tune up?

etc, etc.

These are basic fault detection designs based on "Expert Systems"
methodologies.

Same with any expected behavior of any "Process" including the extremely
simplistic email and the proposed DKIM protocol.

Lets look at Cisco's DKIM flow charts and presentations on how
DKIM will work. Those perfect graphs are based on "steady state"
operations of the protocol.

The question is, what happens when there is a deviation of the protocol
operations. How do you handle it?  What does it mean?  Is it a broken
client?  Is there a bug? Is there a terrorist spoofing a domain?  Did a
terrorist put poison in your message?

Whatever happen you might not know right away, but you do know there is
problem. An alarm has been raised.

Lets go ahead and apply a trust system.

We can say a slight torque on the perfect circle is not a concern. We
still "trust" the system will not blow up.  Maybe we can plot an inner
and outer circles representing boundary conditions (acceptable or
undesirable limits). If any part of the twisted circle touches the inner
or outer circles, then you no longer "trust" the process - something
might blow up!

The problem is that one trust expert (process engineer) might say:

     "No Charlie, we are still ok. Nothing to worry about
      yet. Tolerances are built into the system."

And another trust expert may say,

     "Well Larry, we should consult the operations
      manual and call the 800 number to see what
      vendors have to say."

And yet another trust expert might say:

     "Excuse me Larry and Charlie?. But why isn't it adjusting
      itself back to steady state?"

Suddenly, alarms ring and the system blows up!! <g>

So even thought we can always apply trust on top of an expect system
concept to any system, it will always be hindered on judgment calls
based on the black art of knowledge extraction.  You can learn from it,
of course.

But all of it will always need to follow an expected mode of operations
and any deviations from this expectation is where and when you begin to
measure and protect the system.

I didn't want to muddy the water critiquing hard work put into the TA.
But that analysis was predominately based on "external" attacks.  There
was a fundamental neglect on the attacks based on the breakdown of
proper protocol usage and this was highlighted with the incredible mind
bogging revelation of the "near" exclusive policy.

So it really doesn't matter what you have for a trust system or any new
idea for DKIM attributes, opaque-id or anything else. If we want to go
there, lets do it.

But it still needs to follow an expected and consistent protocol
behavior.  If your first level of protection isn't based on fundamental
principles of following a steady state expectation of a protocol, then
we have issues.

----- Original Message -----
From: "Douglas Otis" <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: <[email-masked]>; "Frank Ellermann"
<[email-masked]>
Sent: Thursday, February 02, 2006 7:30 PM
Subject: Re: [ietf-dkim] Re: New Issue: 4.2 needs new Attack Item:
InconsistentSignature vs Policy Attacks