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

From: "Hector Santos" <[email-masked]>
Date: Mon, 30 Jan 2006 14:29:07 -0500

Suggested correction to TA:

Add a new attack item:

   Inconsistent Signature vs. Policy Attacks
         Impact: High
         Likelihood: High

If a new column "Detection/recovery" is added as suggested in a previous
TA review comment, then this would change to:

   Inconsistent Policy Attacks
         Impact: Low
         Likelihood: High
         Detection/Recovery: High

Background reasoning:

Currently the SSP draft intent is to only apply SSP against messages
lacking a signature.  If a valid signature is found, then SSP is not
necessary.  [Note: if this understanding is incorrect, please correct
it.]

Ironically, this SSP draft specification would present the highest and
more probable threats or occurrence of the DKIM/SSP proposal.  By
following the draft specification, there will be many loopholes.

Example loopholes:

1) A message is signed, but the SSP indicated a "o=." (No mail expected
   from domain).

2) A message is signed, but the first party domain has no declaration of
   a signing policy.  Currently, the SSP draft has no specification to
   expose a "No signature expected" policy.  Instead, the NXDOMAIN DNS
   result for a SSP will result with a default o=~ policy (optional
   signing by any party).

3) A message is signed by a 3rd party, but the SSP indicated a o=!
   policy where the original domain signature is required, and a 3rd
   party signature is not expected but allowed to be present.

   Note: The o=! policy can be a defined a "near exclusive" policy, but
   it is not an absolute exclusive policy consideration.

4) Although there is no current SSP specified in the draft to declare an
   optional original domain signature and no 3rd party signing expected
   the policy exist for this scenario to occur.

These signed mail "NO need for SSP" attacks should be consider to have a
high potential occurrence with direct attacks and indirect attacks.

Direct attacks would be bad actor attempts to exploit compliant DKIM/SSP
systems. Indirect attacks would be bad actors attempts to exploit
non-compliant DKIM/SSP and rely in "social engineering" exploits.  With
indirect attacks, bad actors will not emphasize on protocol correctness.

These attacks can be detected if the SSP is checked against the domain
whether the message is signed or not.  This will lower the risk, the
uncertainty of bad attack exploits and hence, lower the impact of these
high probably attacks

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

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

---

From: Tony Hansen <[email-masked]>
Date: Mon, 30 Jan 2006 15:18:44 -0500

My comment here is really about the relationship between DKIM and the
SSP: what Hector is describing below implies to me that we need to know
up front whether or not an SSP should be applied. This can be
accomplished in several ways: 1) always look for the SSP, as Hector
suggests; 2) add information to the DKIM DNS record to indicate that the
SSP should always be looked for; 3) incorporate the SSP information into
the DKIM DNS record; or 4) some other ways I'm not thinking of at the
moment. Of the first three, I'd lean towards #2.

	Tony Hansen
	[email-masked]

---

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 30 Jan 2006 12:26:35 -0800 (PST)

SSP is ability to indicate policy for email address, i.e. when you see
address in from you can check to find if emails from that address are
supposed to be signed. If you only check policy record when you see a
signature - this pretty much breaks the reason for having such policy
record in the first place.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 30 Jan 2006 12:59:57 -0800

Folks,

Tony Hansen wrote:
> up front whether or not an SSP should be applied. 

Having tracked this discussion, for a bit, I am not understanding how it 
pertains to the Threat Analysis.  I see how the question is important for 
engineering protocol and system details, but not how it relates to threats.

Can someone clarify how this is within scope for the current deliverable?

d/
-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
_______________________________________________
ietf-dkim mailing list
http://dkim.org

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 30 Jan 2006 22:07:09 +0100

Tony Hansen wrote:

> 1) always look for the SSP, as Hector suggests;
> 2) add information to the DKIM DNS record to indicate that
>    the SSP should always be looked for; 
> 3) incorporate the SSP information into the DKIM DNS record;
> or 4) some other ways I'm not thinking of at the moment.

Doug proposed to copy the SSP into the signature as shortcut
for any "check SSP only for valid signatures" strategy.  If I
understood his proposal correctly.  Apparently that has the
same effect as your point (3), and if possible (3) is better.
 
> Of the first three, I'd lean towards #2.

How does that help receivers wishing to reject unsigned mails
with a STRONG or EXCLUSIVE SSP ?  Where "unsigned" includes
"invalid" etc.
                           Bye, Frank

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 30 Jan 2006 16:17:08 -0500

----- Original Message -----
From: "william(at)elan.net" <[email-masked]>

> record in the first place.

I believe Tony's suggestion (which was already discussed 6+ months ago)
is to include the SSP as part of key lookup DNS record as a optimization
feature.

The problem is 3rd party signatures.  The OA might may not want to have
3rd party Key signers defining the signing policy.  So you need to key
it separate.

When discussed in the past, it was all about reducing the SSP lookups.
As  it seemed to me, there was the big resistance in doing additional
lookups.

I agreed, but my only point then was that we should put optimization
aside to workout all the ideal boundary conditions first to remove all
protocol loopholes. Then you optimize it, and if that's not possible and
makes the entire process impractical, then you throw the idea away and
go back to the drawing board. :-)

But the worst thing to do is to ignore it and/or make it all optional
because that would be he easiest thing to do.

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 30 Jan 2006 16:45:44 -0500

----- Original Message -----
From: "Dave Crocker" <[email-masked]>

> Can someone clarify how this is within scope for the

Hmmmmm,

Dave, as requested by Jim and Stephen, I racked my brains trying to mold
this NEW ISSUE entry in the best possible manner that would cater to the
mindset of this mixed discipline group, sensitive of the WG schedule and
to minimize changes to Jim's fine TA document.

I thought I provided a compromise that addresses a very important
fundamental threat related to the SSP specification and ignored in the
TA.  It is 100% related to the TA. Many the current TA threats impact or
likelihood are affected by the issues presented by me.  But I didn't
present it that way. I present it as an additional item to add.

As a side related note, the SSP draft specification as it is currently
defined is implemented in the current common API being made available
for developers.  I don't think to say much about the premature nature of
the decisive (low info, few options) design decisions made.

Nonetheless, I believe this should be added to the TA to serve as a
basis for the next round of signature and SSP design discussions.

The fact is, these are real threats and they need to be documented in
the TA, so I did the best I could to present it in a simple logical
manner, as requested by Jim and Stephen, so that it can easily be
considered.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 30 Jan 2006 13:52:07 -0800

On Jan 30, 2006, at 1:07 PM, Frank Ellermann wrote:
>
> Doug proposed to copy the SSP into the signature as shortcut for  
> any "check SSP only for valid signatures" strategy.  If I  
> understood his proposal correctly.  Apparently that has the same  
> effect as your point (3), and if possible (3) is better.

To the extent that this is somewhat relate to a threat...

Looking for a policy record occurs when the email-address domain is  
not within the signing-domain.  This may still mean the message may  
have been signed.

As many of the policy lookups for email-addresses will not return a  
record, this lack of a record will not persist very long in cache,  
requiring repeated search sequences for each such message.  Those  
email-addresses without a policy record may also burden upper level  
domain DNS servers as the search extends upward.

What will likely become a sizable overhead associated with accessing  
a separate policy record could be eliminated with a strategy that  
caches similar (binding and role) information obtained from within a  
prior signature header and the DNS key.  The same information could  
be part of a white-listing strategy as well.  White-listing and  
marking the mail "good" also overcomes look-alike domain attacks. : )

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 30 Jan 2006 22:09:44 +0000

Hector,

>    Inconsistent Signature vs. Policy Attacks

I think there's a fair enough point there all right though getting
the wording right might be tricky. In 4.1 we do have attacks like
"theft of private key", so something about "applying wrong policy"
ought be appropriate for 4.2.

Note - I don't think we should get into solutions in the threats
draft, though the considerations from Tony's mail should come back
up for discussion later.

Stephen.

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 30 Jan 2006 17:34:33 -0500

----- Original Message -----
From: "Stephen Farrell" <[email-masked]>
To: "Hector Santos" <[email-masked]>

> draft, though the considerations from Tony's mail should come back

Unbelievable. :-) The TA is full of functional recommendations. In all
honesty I am no longer sure what hat I should be wearing here.  It might
surprise you that I'm less concern about specific "how to" but rather
risk management and the decision making process for this proposed
protocol. This is about extracting all the information that is possible
from protocol protocols as well understanding all the options in order
to have well informed hierarchic design decisions that survive the test
of time.

It should be noted, Tony's input has already been discussed in quite
detail - the suggestion about minimizing DNS lookups by coupling the DNS
key record with SSP attribute information. But these are specific
implementation details.

The general problem is first party policies vs. 3rd party signers making
possible fraudulent policy declaration for the first party. So you can't
do what Tony suggested as an specific optimizing solution.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 30 Jan 2006 22:48:17 +0000

Hector Santos wrote:
> Unbelievable. :-) 

Believe it:-) But I can see how "get into" above might be
misunderstood.

 > The TA is full of functional recommendations.

Sure. I'd have no problem if it said "one possibility is to
include the policy assertion alongside the public key and
require some restriction as to how domains map" or whatever
is the right thing to say.

What I meant was that this (document) isn't the time (place)
to decide details of such e.g whether an actual assertion
or a pointer would be alongside.

So I don't think we're really disagreeing.

Stephen.

---

From: Jim Fenton <[email-masked]>
Date: Mon, 30 Jan 2006 23:14:12 -0800

> necessary.  [Note: if this understanding is incorrect, please correct
SSP is not necessary if a valid originating address signature is found. 
If the only valid signature(s) is/are third-party, it is still necessary
to check SSP associated with the originating address.
> 1) A message is signed, but the SSP indicated a "o=." (No mail expected
There has been a lot of discussion of "o=." but it's not actually in the
current version of the SSP draft.  I personally don't think it's really
necessary.  But that's probably a better topic for later.

>    result for a SSP will result with a default o=~ policy (optional
In the presence of a "no signature expected" policy, would a message
with a valid signature be more suspicious than one without?  But if no
signature is expected, why would the OA domain have any keys published
in the first place?
>    it is not an absolute exclusive policy consideration.
I'm afraid I don't follow this.
> uncertainty of bad attack exploits and hence, lower the impact of these
Sorry, I'm not following this either.  It seems the threat has to do
with receipt of signed messages when none should be expected.  But isn't
this addressed simply by not publishing any key records?

-Jim

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 31 Jan 2006 17:37:21 +0100

>> 1) A message is signed, but the SSP indicated a "o=." (No
>>    mail expected from domain).

> There has been a lot of discussion of "o=." but it's not
> actually in the current version of the SSP draft.

Did you confuse this with WEAK ?  Or do you have a fresher copy
of the draft ?  My copy draft-allman-dkim-ssp-01 still has o=.
on <http://tools.ietf.org/html/draft-allman-dkim-ssp-01#page-9>

                               Bye, Frank

---

From: Dave Crocker <[email-masked]>
Date: Tue, 31 Jan 2006 09:45:54 -0800

> SSP is not necessary if a valid originating address signature is found. 

This has always struck me as an astonishingly powerful observation.

It means that we can have entirely independent lines of discussion.  One for the 
creation and handling of a successful signature.  The other for all other 
scenarios.

In particular, it means that the signature work can be partitioned from the 
non-signature work.  (To anticipate a mis-reading of this comment:  I am not 
saying that the two are not equally important.  Merely that each can receive its 
own focus of effort.)

My reading of the comments about the signature mechanism, versus comments on the 
  SSP mechanism, is that the former tend to represent very narrow, crisp, 
technical details, whereas the latter tend to be far more conceptual.

Given that the signature mechanism was carefully designed to re-use quite a bit 
of well-understood mechanism, it is not surprising that review and revision to 
it can be so crisp.  This tends to permit efficiently understanding the problem 
and usually means efficiently fixing it.

Given that SSP pertains to a topic that has little, if any, Internet-scale 
standardization or operations history, and given that it pertains to 
human/organizational rules, rather than lower-level bit-twiddling, it is also 
not a surprise that discussion about it requires wandering around the concept 
space rather more.

d/
-- 

Dave Crocker

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 31 Jan 2006 13:42:15 -0500

Jim, thanks for the feedback.

----- Original Message -----
From: "Jim Fenton" <[email-masked]>

>> Example loopholes:
>>
>> 1) A message is signed, but the SSP indicated a "o=." (No mail
>>    expected from domain).

> There has been a lot of discussion of "o=." but it's not actually
> in the current version of the SSP draft.  I personally don't
> think it's really necessary.  But that's probably a better topic
> for later.

Ok. I suggest that we not close protocol options yet. Lets look for all
the possibilities, outline it, jot it down and then we work it out.

Just to the point, AltaVista.com has a "Never Expect From Us" email
policy.  A TXT lookup provides:

 Non-authoritative answer:

 altavista.com   text =
    "This domain sends no email"
 altavista.com   text =
    "Null SPF is for tracking purposes only"
 altavista.com   text =
    "All mail claiming to be from altavista.com is forged"
 altavista.com   text =
    "v=spf1 +exists:CL.%{i}.FR.%{s}.HE.%{h}.null.spf.altavista.com -all"

I think DKIM should offer the same.  I will probably do the same soon
for 4-5 our domains.

> with a valid signature be more suspicious than one without?

This is a rethorical question. Do you know and prove it isn't a threat?
These are decisive decisions based on having low information and few
options to take.

It is the possibility that it can exist.  The "ideal" (as oppose to
practical) solution is to get more information, and in this case, check
the domain policy and this provides more appropiate options to take.
That solves the problem.

The question of whether it is a 'feasible idea' should be left for
design
implementation discussions. But without it, it is a possible threat
until you can prove otherwise.

> But if no signature is expected, why would the OA domain have
> any keys published in the first place?

Exactly.  Again, rethorically, could a bad actor use this scenario as an
exploit?

Me?

My simple policy change offer a greater value to all parties.

   Default SSP should be NO POLICY.  Force the issue with DKIM
   domain policy implementation. If they want to use it, be
   specific. Don't leave it up to verifiers what your intent
   really was.

But this should part of SSP discussions.

>>    Note: The o=! policy can be a defined a "near exclusive" policy,
>>    but it is not an absolute exclusive policy consideration.
>>

This is to point out there is no longer (never was) a 'true' exclusive
security benefit with SSP.  Since you clarified what this policy is,
it highlights the possibiluty that it allows for any 3rd party entity to
"touch" the message.

If you allow it to happen, it can be exploited. How and why? Who knows,
but  bad actors are creative and will figure out how to exploit this.
But more important, it also lowers the reliability of the policy and
confidence lever of a domain wanting to use this.  The "hole" exist so
IMO, it should be noted in the TA.

> Sorry, I'm not following this either.  It seems the threat has
> to do with receipt of signed messages when none should be
> expected.  But isn't this addressed simply by not publishing
> any key records?

Maybe. But I think it the fake ones that could cause grief.  We don't
know how it can use.  But the door is open. That is all my point here is
about.

Each of the examples I showed have their own specific level of
likelihood, detection and impact.  The overall common issue is
consistency of the signature vs policy expectations.  This in itself is
a major threat.

The most perfect analogy is the "SMTP rule" that the return path should
reflect the sender address.  Since the SMTP protocol is relaxed and has
no required provision to validate this address, it has become the #1
exploited feature of SMTP. It is the basis for many forms of email
attacks, spam, spoofs, bounce-attacks as used by SORBIG generation
e-virues using a dual level distribution scheme: Try directly the RCPT
address, if accepted and then latter rejected, exploit the expected
bounce system itself to bounce it to MAIL FROM, etc, etc. - a dual level
addressing attack.

Here is what I hope we don't duplicate:

RFC 2821, section 7.1

  7.1 Mail Security and Spoofing

  ..

  This specification does not further address the authentication issues
  associated with SMTP other than to advocate that useful functionality
  not be disabled in the hope of providing some small margin of
  protection against an ignorant user who is trying to fake mail.

It isn't a few ignorant bad actors any more, but an entire industry.

It it my hope to highlight these critical points and that we avoid
repeating the same type of relaxed protocol provisions mistakes with
DKIM without thinking it all out very thoroughly.

Look at this another way:

How about legacy software?

You can put money in the back that all SMTP systems will still need to
support legacy clients.

The best way to avoid any new security concept, is for the the Bad Actor
to avoid it.  In order words, they won't use DKIM. They won't sign the
message. They won't raise any red-flags.

So where is the protection? Where is the pay off?

In leiu of having prior information about the sender, what we can't
avoid the segment of bad actors who DO try to use DKIM in some form or
fashion to be ignored.

In other words, by using DKIM or trying to exploit, it raises the bar to
a new level that is ABOVE backward compatible operations.

This is the protection begins.  But if the protocol is full of relaxed
provisions making it essentially all optional, then you lose a good bit
of this protection and the end result is that a SMTP system, having to
support legacy software anyway, will punt on DKIM processing and just
put ignore any information about it.

The two extremes policies are:

    NEVER     (o=.)
    EXCLUSIVE (o=!)

But we now relaxed EXCLUSIVE so it really isn't exclusive anymore but
more of a STRONGER policy over the STRONG policy as you initially
indicated you referred to it.  So we lost some protection there.

In any case, the devil's details is not what I was trying to extract
here, but to highlight that not following consistent protocol
expectations is a threat itself.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 31 Jan 2006 11:50:13 -0800

On Jan 31, 2006, at 9:45 AM, Dave Crocker wrote:
>
> Given that SSP pertains to a topic that has little, if any,  
> Internet-scale standardization or operations history, and given  
> that it pertains to human/organizational rules, rather than lower- 
> level bit-twiddling, it is also not a surprise that discussion  
> about it requires wandering around the concept space rather more.

Agreed.  The successful verification of a signature should stand on  
its own.

Such a successful signature may allow messages to be marked "trusted"  
when the signing-domain is found within a list of known trustworthy  
domains.  This could be independent of whether an email-address in  
the message is also within the signing-domain.  A violation of trust  
can easily occur by what is found within the message content, where  
perhaps greater attention is received.  What may be indicated within  
a email-address could be shown only as the display-name anyway.  If  
there is abuse, there is a known, previously trusted entity that can  
be held accountable.

There is risk associated with marking messages solely upon a basis  
that an email-address is within the signing-domain.  This would  
assume the recipient can clearly see and know a trustworthy email- 
address from that of the thousands of potential look-alikes.  If  
there is a problem, the entity involved may be unknown.

On average, the contained email-address may not be within the signing- 
domain, with the common practice of allowing the free use of email- 
addresses by large providers serving the public.  Domains with  
minimal vetting such as these should be excluded from being listed as  
trustworthy, regardless whether the email-address matches.  Messages  
from these sources should undergo the same scrutiny as given today.

Whether any reduction in scrutiny can occur with a policy that the  
domain's email-address MUST be within their signing-domain eliminates  
some but not all sources of uncontrolled abuse.  Countering this  
abuse, it is doubtful that "bad" signatures can be distributed from a  
centralized service at a high enough rate to control this potential  
problem.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 31 Jan 2006 23:13:19 +0000

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.