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

From: <[email-masked]>
Date: Tue, 31 Jan 2006 12:59:00 -0500

Sorry,
Should have been clearer.

Bad guy sends a message purportedly from cox.com with a header 
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;  s=s1024; d=cox.com

The non dkim compliant mta who hasn't deployed dkim yet or knowing much
about it places a rule stating that signed messages should be allowed to
travel inbound without further checking because dkim is new and safe.

A dkim compliant mta will do a dip on my dns records and find no ssp or
dk record and drop the message as non compliant.

I suspect that in the beginning there will be a lot more of the former
than the latter.

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: Dave Crocker [mailto:[email-masked]] 
Sent: Tuesday, January 31, 2006 12:49 PM
To: Oxley, Bill (CCI-Atlanta)
Cc: [email-masked]
Subject: Re: [ietf-dkim] New Issue: 4.2 needs new Attack Item:
InconsistentSignature vs Policy Attacks

Bill,

[email-masked] wrote:
> The hacker does not need access to my zone, he just attaches a
lookalike
> header yes " And to have *any* rule that allows bypass of defense
> based upon the receipt of a header from outside your control is
> extremely dangerous." But folks will do it anyway

By "lookalike" do you mean social engineering with a related name
string, such 
as citibank.com vs. c1t1bank.com, or do you mean something else.

If something else, please elaborate.

On the other hand, if you mean the name confusion thing, I would guess
that that 
is entirely out of the scope for this working group, since it really
pertains to 
reputation mechanisms, associations between domain names and brands,
etc.

d/
-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>

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

---

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

> travel inbound without further checking because dkim is new and safe.

non-dkim compliant, but nonetheless makes a policy decision based on the 
presence -- and not even the validity -- of a signature?

that sort of receive-side behavior seems sufficiently misguided that I can't 
imagine a need to protect against it by our work.

> dk record and drop the message as non compliant.

if the signature succeeds, why do they need to check ssp?

d/
-- 

Dave Crocker

---

From: Steve Atkins <[email-masked]>
Date: Tue, 31 Jan 2006 10:18:59 -0800

> I suspect that in the beginning there will be a lot more of the former

I suspect this is a non-issue.

The reason is that the early adopters of DKIM are going to be bulk
mailers. As such, any MTA or spam filtering system that's not got to
the point of actually checking DKIM signatures is going to be configured
to behave according to the correlation between DKIM headers and
unwanted mail, if they pay any attention at all.

The odds of more than a vanishingly small fraction of non-DKIM-aware
MTAs _increasing_ deliverability for DKIM headers is really low.
Decreasing, sure, but not increasing.

It's also "not our problem".

Cheers,
   Steve

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 31 Jan 2006 14:46:40 -0500

----- Original Message -----
From: <[email-masked]>

> The non dkim compliant mta who hasn't deployed dkim yet or knowing
> much about it places a rule stating that signed messages should be
> allowed to travel inbound without further checking because dkim is
> new and safe.
>
> A dkim compliant mta will do a dip on my dns records and find no
> ssp or dk record and drop the message as non compliant.
>
> I suspect that in the beginning there will be a lot more of the
> former than the latter.

I agree, and history has already proved this with SPF and it migration
recommendations which suggest that SPF policies can be defined first
(for others to use) before the SMTP servers actually support it for
inbound mail.  This is a big part reason for the SPF forwarding and
alias mail problem.

I also suspect the same with happen with DKIM. There is no reason to
suspect otherwise. But it can worked out with a sound DKIM migration
recommendation based on its EXPIRATION concept (which SPF lacks).

But I agree with you overall. Policies will most likely be defined
first.

This is especially the case with DKIM since software requirements is a
bit more complex.

With SPF, the implementation issues was clearly highlighted with POST
SMTP (easier to plug and play) vs. DYNAMIC SMTP operations (some skim,
hook  system required).

The easier POST SMTP implementation promoted bounce attack issues for
SPF.  This is alleviated with a DYNAMIC SMTP response system.

Same with apply with DKIM implementation decisions - post vs. dynamic.

>From my perspective, the concern with POST SMTP systems is that it
promotes a higher level of unreliable deliverables; i.e. POST SMTP
analyzers are not sure what to do with the "suspicious mail." But to
avoid bounce attacks, it dumps it.

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

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 31 Jan 2006 14:44:43 -0800

> imagine a need to protect against it by our work.

If we have to list out every stupid thing that somebody might possibly 
do which they know doesn't comply with DKIM, we'll never finish.

And yet, listing every security issue with every technology that DKIM 
depends on (DNS, SMTP, TCP, etc) would take forever too.  We might as 
well just write "the Internet is inherently insecure" and go home.

Are there truly no bounds on the threat analysis?

-- 
J.D. Falk, Anti-Spam Product Manager
Yahoo! Communications Platform Team
_______________________________________________
ietf-dkim mailing list
http://dkim.org

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 01 Feb 2006 01:01:55 +0100

> Are there truly no bounds on the threat analysis?

Of course there are, as Phil explained it yesterday:  Get some
"WG rough consensus" and a GO from the proto-shepherd (or from
the real shepherd, Russ), submit to IESG, get GenArt review
nits and IESG [Discuss], fix that in a new revision supported
again by "WG rough consensus" and another GO, submit it again
to the IESG.  Let at most five (?) [Discuss] drop to [Abstain]
turning the rest into [No objection] or [Yes], that's all.

The potential deadloop if there's no GO is a bug in the proto-
draft.  If the real shepherd refuses to vote "yes" it would be
a rather odd case (but it's not impossible), and we're in some
procedural situation.

Best plan would be to ask for an "IETF last call", that would
avoid IESG attempts to try stupid things (like "senderid").
  
It would also almost guarantee that we don't get away with an
insufficient threat analysis.  The real danger are bad RfCs,
not procedural dead locks.  It has to be good enough for the
folks that are no "DIM fans", or generally of screwing with
mail and / or security.
                            Bye, Frank