Subject: [ietf-dkim] How MALLET PERFORMS a DOWNGRADE ATTACK

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 2 Aug 2006 15:12:33 -0700

> From: Stephen Farrell [mailto:[email-masked]] 
> Hallam-Baker, Phillip wrote:
> >> From: Stephen Farrell [mailto:[email-masked]]
> > 
> >> Why? Surely all that can happen is stripping of the 
> stronger sig and 
> >> we already decided that that wasn't a bother for base, so 
> why is it a 
> >> problem now? (Maybe I mis-remember but I think we decided it was a 
> >> non-problem, not that it was a problem to punt to SSP.)
> > 
> > Alice decides to sign with ZSA which has just been approved, few 
> > people support ZSA so she also signs with RSA2048
> > 
> > Bob's mail gateway does not support ZSA.
> > 
> > Mallet strips out the RSA2048 signature, modifies the 
> message and leaves in the ZSA signature.
> > 
> > 
> > Bob can see that there is a signature which points to a 
> valid key record but has no way to verify it and no way to 
> know that it does not comply with Alice's signature policy.
> 
> So what? What will Bob do differently when his DKIM code sees 
> that Alice sometimes/always signs with ZSA and/or RSA2048? Complain?
> He'll probably do that anyway knowing Bob:-)
> 
> Mallet's not getting much out of it either - maybe he'd be 
> better off flipping a plaintext bit really since then Bob'd 
> do more work.

NO MALLET PERFORMS A SUCCESSFUL DOWNGRADE ATTACK.

As far as Bob is concerned the email is in compliance with policy so he has to accept the message as being compliant with the signature policy even though it is not.

Alice MUST have a way to state "I always sign with BOTH ZSA AND RSA2048".

Otherwise merely publishing a ZSA key record effectively allows an attacker to nullify the signature policy record altogether.

In effect the lack of the AND policy statement means that it will never be possible to upgrade to a new algorithm without rendering the policy specification void. 

What Bob will do differently in this case is to accept a message as compliant with policy that should be rejected as non-compliant. That is huge. It gives Mallet an opening to defeat the attack SSP is intended to prevent.

The selector mechanism is a simple fix.

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave Crocker <[email-masked]>
Date: Wed, 02 Aug 2006 15:45:59 -0700

Stephen Farrell wrote:
> I could quibble. That's not a downgrade attack since Alice
> parallel-signed with both. 

I was under the impression that the working group had said that it was not
concerned about downgrade attacks, for the DKIM usage being discussion.

Assuming I got that correct, why is it still being discussed?

d/

-- 

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 02 Aug 2006 23:50:02 +0100

> Assuming I got that correct, why is it still being discussed?

Yep. That's why I asked Phill what's different now from when
we discussed this before. I admit that I can't see a big
difference, though I didn't look back at the archive/logs/minutes
to check.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 02 Aug 2006 23:43:27 +0100

I could quibble. That's not a downgrade attack since Alice
parallel-signed with both. This is different from bidding
down with spnego/gssapi or SSL where there may be an "export"
option, but I don't want to end up there unless I've no
other option.

Alice also had the option of sequentially signing if
she considers one alg better than the other.

> As far as Bob is concerned the email is in compliance with policy so he has to accept the message as being compliant with the 
signature policy even though it is not.

I'd be more of the opinion that it is fine since Alice
did sign with rsa2048. If she doesn't consider that ok,
she should have just signed with zsa. It is arguable
though, I agree.

> Alice MUST have a way to state "I always sign with BOTH ZSA AND RSA2048".

Sure - invent an "zsaandrsa2048" algorithm:-) Bit I don't see the
reason for the MUST, since this only affects a Bob who's happy
with rsa2048, and who is therefore vulnerable to whatever problems
exist for that algorithm regardless of Alice's policy.

> Otherwise merely publishing a ZSA key record effectively allows an attacker to nullify the signature policy record altogether.

I don't agree. (And it assumes the existence of the record - see
below.)

> In effect the lack of the AND policy statement means that it will never be possible to upgrade to a new algorithm without rendering the policy specification void. 

There may or may not be a need for a separate AND construct but
that's another layer of detail.

> What Bob will do differently in this case is to accept a message as compliant with policy that should be rejected as non-compliant. That is huge. It gives Mallet an opening to defeat the attack SSP…

Isn't a lot of this a circular argument? The justification for
adopting this as a policy requirement is that it allows Bob to
detect adherence to this policy.

If you could state an advantage in terms of collision-dodgy
signature/hash algorithms then maybe it'd convince folks more.
(Or, maybe not, we'll see.)

And again - you've not said what's new here that causes us to
end up with a different answer about this compared to when the
WG considered it for base? (Or maybe you did and I missed it;-)

Stephen.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 2 Aug 2006 16:02:35 -0700

On Aug 2, 2006, at 3:12 PM, Hallam-Baker, Phillip wrote:

> As far as Bob is concerned the email is in compliance with policy  
> so he has to accept the message as being compliant with the  

On this I tend to agree with you.  However, until someone  
demonstrates a chronic non-catastrophic scenario, it would appear few  
want to go through the exercise.  From an overhead standpoint, the  
announcement that prevents the downgrade attack of a deprecated  
version, algorithm, or query method could be included within the key  
supporting the element declared as deprecated.  Once both the sender  
and verifier have upgraded, this would immediately thwart a downgrade  
attack.  When the verifier has not upgraded, it would act a warning.   
Both policy and key are found in DNS, so this limits the value having  
this announcement in policy, rather than in the key that must be  
acquired.  Depending upon how policy is used, it may not be acquired  
for every message.  However the sender can control whether the key is  
acquired.  Although the list of possible weak points is not complete,  
version could act as a catch-all.

> The selector mechanism is a simple fix.

I tend to agree with John, the selector mechanism seems overly  
complex.  Perhaps a convention of right-hand labels within the  
selector, or adoption of the r= mechanism could simplify this  
somewhat.  The r= mechanism also has the advantage of not impacting  
key management, which should also simplify when and where it gets  
applied.

-Doug

---

From: Damon <[email-masked]>
Date: Wed, 2 Aug 2006 19:14:22 -0400

> key management, which should also simplify when and where it gets

+1

Damon

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 03 Aug 2006 00:22:37 +0100

Oh come on. We're done on that issue. Let's at least try
make progress please. You suggested it. The WG chose not
to do that. That's all.

S.

Douglas Otis wrote:
>> As far as Bob is concerned the email is in compliance with policy so 
>> he has to accept the message as being compliant with the signature 
>> policy even though it is not.
> 
> 
> On this I tend to agree with you.  However, until someone demonstrates a 
> chronic non-catastrophic scenario, it would appear few want to go 
> through the exercise.  From an overhead standpoint, the announcement 
> that prevents the downgrade attack of a deprecated version, algorithm, 
> or query method could be included within the key supporting the element 
> declared as deprecated.  Once both the sender and verifier have 
> upgraded, this would immediately thwart a downgrade attack.  When the 
> verifier has not upgraded, it would act a warning.  Both policy and key 
> are found in DNS, so this limits the value having this announcement in 
> policy, rather than in the key that must be acquired.  Depending upon 
> how policy is used, it may not be acquired for every message.  However 
> the sender can control whether the key is acquired.  Although the list 
> of possible weak points is not complete, version could act as a catch-all.
> 
>>
> I tend to agree with John, the selector mechanism seems overly complex.  
> Perhaps a convention of right-hand labels within the selector, or 
> adoption of the r= mechanism could simplify this somewhat.  The r= 
> mechanism also has the advantage of not impacting key management, which 
> should also simplify when and where it gets applied.
> 
> -Doug
> NOTE WELL: This list operates according 
> tohttp://mipassoc.org/dkim/ietf-list-rules.html
>