Subject: RE: [ietf-dkim] The key record upgrade attack

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 4 Aug 2006 07:34:37 -0700

> From: Stephen Farrell [mailto:[email-masked]] 

> My issue with this is that I don't see why this is much different
> from:
> 
> Everyone supports rsa-sha256
> 
> Alice publishes:
> 
> 1. The policy statement 'I always sign'
> 2. A key record for algorithm rsa-sha256
> 
> Mallet can produce a forgery of a message by Alice that is 
> 100% certain to be considered in compliance with policy - the 
> signature value just won't verify.

The difference is that a signature that does not verify is treated as if it was not present and thus the message is not in compliance with policy.

Verifiers must be able to treat the following conditions differently:
   "There is a signature here that I cannot verify"
   "There is a signature here that fails the verification process I support"

What the attack does is to convert the policy Alice intends to express "I always provide a signature that you can validate" into "I always provide a signature but you may not be able to check it". That is a crucial difference.

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

---

From: Michael Thomas <[email-masked]>
Date: Fri, 04 Aug 2006 07:48:08 -0700

>What the attack does is to convert the policy Alice intends to express "I always provide a signature that you can validate" into "I always provide a signature but you may not be able to check it". T…
I probably haven't had enough coffee yet, but what would a receiver do
differently with that knowledge? In the end is looks like the recever can't
verify the signature regardless of the reason so it's as good as missing 
from
its standpoint.

       Mike

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 04 Aug 2006 15:55:32 +0100

Phill,

> The difference is that a signature that does not verify is treated as if it was not present and thus the message is not in compliance with policy.

So if a mailing list mangles a message then you'd consider the message
as no longer being policy-compliant? I guess that's one reasonable way
to look at it, but I don't believe its the only reasonable way. I could
equally treat this as a case where the message appears to conform to the
policy, but fails signature checking.

Sounds a bit like an implementation issue.

>    "There is a signature here that fails the verification process I support"

Verifiers can already handle that difference all by themselves, even
without SSP.

(As an aside - I could imagine someone wanting to allow SSP to say
something like "if you encounter error <foo> when processing a
message apparently from me, then I'd recommend that you <bar>"
and where we'd define a foo="unsupported sig-alg" and maybe have
bar="barf". But that leads down the mandating-recipient-behaviour
rathole and may be better tried out via whatever extensibility
mechanism ends up in SSP.)

> What the attack does is to convert the policy Alice intends to express "I always provide a signature that you can validate" into "I always provide a signature but you may not be able to check it".…

I guess I'd just place a different emphasis on this than you, but
we'll see what consensus emerges as we go,

Stephen.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 4 Aug 2006 08:38:33 -0700

On Aug 4, 2006, at 7:48 AM, Michael Thomas wrote:

>>> Mallet can produce a forgery of a message by Alice that is 100%  
>>> certain to be considered in compliance with policy - the  
>> The difference is that a signature that does not verify is treated  
>> as if it was not present and thus the message is not in compliance  
>> with policy.
>>
>> What the attack does is to convert the policy Alice intends to  
>> express "I always provide a signature that you can validate" into  
>> "I always provide a signature but you may not be able to check  
>> it". That is a crucial difference.
>
> I probably haven't had enough coffee yet, but what would a receiver  
> do differently with that knowledge? In the end is looks like the  
> recever can't verify the signature regardless of the reason so it's  
> as good as missing from its standpoint.

During a transition, it would be important to communicate what will  
be offered and what has been deprecated.  Then these options MUST be  
available or the related signatures MUST be ignored.  While this  
policy could be found in the policy record, it should also be found  
in the deprecated key record.  Adding a tag to the key record does  
not break the key record, by the way.

-Doug

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 4 Aug 2006 09:23:17 -0700

At 8:38 AM -0700 8/4/06, Douglas Otis wrote:
>available or the related signatures MUST be ignored.

The SSP document *cannot* change the way implementers of the -base 
document process signatures. "MUST be ignored" changes the logic of 
-base.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Fri, 4 Aug 2006 09:29:08 -0700

On Aug 4, 2006, at 9:23 AM, Paul Hoffman wrote:

>> During a transition, it would be important to communicate what  
>> will be offered and what has been deprecated.  Then these options  
>> MUST be available or the related signatures MUST be ignored.
>

Interesting catch.  This point was raised however during base, but  
ignored.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Fri, 4 Aug 2006 09:46:38 -0700

On Aug 4, 2006, at 9:45 AM, Stephen Farrell wrote:

> Douglas Otis wrote:
>>>> will be offered and what has been deprecated.  Then these  
>>>> options MUST be available or the related signatures MUST be  
>>>> ignored.
>>>
>>> The SSP document *cannot* change the way implementers of the - 
>>> base document process signatures. "MUST be ignored" changes the  
>>> logic of -base.
> Sometimes:         Raised != clearly described.
> Always:            Ignored != didn't achieve consensus.

+1 : )

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 04 Aug 2006 17:45:10 +0100

Douglas Otis wrote:
> Interesting catch.  This point was raised however during base, but ignored.

Stephen.

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 4 Aug 2006 12:46:02 -0400

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

> mechanism ends up in SSP.)

I view this not as a mandate, but as a declaration or an "advisement" of not
wanting to take responsible for any failure seen based on some possible
mispresentation.

Sort of like:

    "if you find an error <foo> from a signed message purported from
     me, please do me a favor and yourself a favor and get of it.
     We will not be responsible for it, but if you want to keep it
     thats up to you."

After all, why go thru the trouble of signing the message if you don't care
for the disposition of the message?  Signing a message should have a reason
and purpose behind it.  No? The "Cross my finger, hope I make it" just seems
really risky.

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

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 4 Aug 2006 09:52:38 -0700

>Interesting catch.  This point was raised however during base, but ignored.

It was not ignored; it was actively rejected.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html