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

From: <[email-masked]>
Date: Tue, 31 Jan 2006 11:30:41 -0500

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

If I do not publish any key records and a bad actor whips up an email
purported to be from me with a fake signature attached, a non dkim
compliant mta may have a rule that states "signed messages are probably
okay" that might bypass some spam checking software. Before DKIM is
fully adopted/deployed expect to see this happen,
Thanks,

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

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

---

From: John Levine <[email-masked]>
Date: 31 Jan 2006 16:48:47 -0000

>fully adopted/deployed expect to see this happen,

How long did it take people to realize that the majority of mail that
passes SPF is spam?

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Tue, 31 Jan 2006 09:08:15 -0800

> fully adopted/deployed expect to see this happen,

Unless the attacker also has access to your zone, they won't
be able to insert their key into it, and thus the signature will
never verify. And to have *any* rule that allows bypass of defense
based upon the receipt of a header from outside your control is
extremely dangerous. It would be nothing better than a 
security-through-obscurity backdoor.

		Mike

---

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

John Levine wrote:

> How long did it take people to realize that the majority
> of mail that passes SPF is spam?

Is that already so ?  I've expected that much later in the
game for SPF and DKIM.  And of course also for PRA and CSV.

Whatever "PASS" from unknown strangers is a waste of time,
without white list it's useless.  For the "threats" draft
we mainly need the case "PASS from a white-listed source",
and Jim has this as 4.1.16 (among others):  HIGH + MEDIUM.

                            Bye, Frank

---

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

> fully adopted/deployed expect to see this happen,

1. As previously mentioned, anyone making reputation decisions based on 
an unauthenticated DKIM signature will quickly learn (if they're paying 
any attention at all) that they have made a mistake.

2. the "spammers have co-opted DomainKeys wtf omg" story was last year:
http://www.eweek.com/article2/0,1759,1732576,00.asp?kc=EWNKT0209KTX1K0100440

Re #2, the sky has not yet fallen.

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

---

From: Douglas Otis <[email-masked]>
Date: Tue, 31 Jan 2006 15:20:29 -0800

On Jan 31, 2006, at 2:51 PM, J.D. Falk wrote:

>> If I do not publish any key records and a bad actor whips up an  
>> email purported to be from me with a fake signature attached, a  
>> non dkim compliant mta may have a rule that states "signed  
>> messages are probably okay" that might bypass some spam checking  
>> software. Before DKIM is fully adopted/deployed expect to see this  
>> happen,
>
> 1. As previously mentioned, anyone making reputation decisions  
> based on an unauthenticated DKIM signature will quickly learn (if  
> they're paying any attention at all) that they have made a mistake.
>

By the same token, this story points out that basing reputations upon  
an authenticated DKIM signature is also a mistake.  Reputations can  
only be based upon a "trusted" signing-domain.  Once that trust is  
lost, the domain becomes just another email source.  Most ISPs should  
be excluded from a trustworthy category.  It may be possible to  
establish trust more selectively within a normally untrustworthy  
domain, provided there is a means to make explicit assurances that  
sources are validated by the sender and marked as trustworthy.  Such  
assurances could prove useful for machine to machine communications,  
for example.

-Doug

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 31 Jan 2006 16:07:08 -0800

On 2006-01-31 15:20, Douglas Otis wrote:

> only be based upon a "trusted" signing-domain.

I'd word that statement a bit differently, but either way I think this 
horse has been sufficiently beaten.  No need to beat it again.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 31 Jan 2006 18:02:08 -0800

On Jan 31, 2006, at 4:07 PM, J.D. Falk wrote:
>> By the same token, this story points out that basing reputations  
>> upon  an authenticated DKIM signature is also a mistake.   
>> Reputations can  only be based upon a "trusted" signing-domain.
>
> I'd word that statement a bit differently, but either way I think  
> this horse has been sufficiently beaten.  No need to beat it again.

While it may not be possible to retain trust for a population of user  
within a domain as a whole, a "trusted list" would provide a safe  
means to mark messages as trustworthy.  Segmenting the domain's  
population could preserve trust for select users within the domain,  
much like an OS "group" property.  Maybe this could be a binary flag  
to simplify listings.

While the nature of a domain's diverse users may result in the domain  
being generally "Not Trusted", a special assertion may be able to  
retain trust for a group of users.  This could be done with a Group  
ID within the key perhaps.  This could allow Group ID "trusted"  
messages to receive a "Trusted" marking within a domain that would  
otherwise not be able to retain a level of trust as a whole.  Being  
able to use the same domain name may result in less confusion for  
users being instructed that their system has a problem, for example.

-Doug