Subject: Re: [ietf-dkim] Issue 1386 and downgrade attacks

From: Paul Hoffman <[email-masked]>
Date: Wed, 28 Feb 2007 12:17:12 -0800

At 10:48 AM -0800 2/28/07, Dave Crocker wrote:
>It's probably worth noting that a catastrophe with a deployed 
>algorithm, so that a rapid transition is required, has no precedent 
>in the large-scale, open Internet, and probably would take 
>considerably more effort and mechanism than anything we are 
>discussing here.

Similarly, given that the failure would be in a signature algorithm, 
the world will be much more concerned with forgeries of SSL 
certificates, banking records, and weapons deployment codes than they 
will of their email whitelists, regardless of what two or three 
people on this list might think.

--Paul Hoffman, Director
--Domain Assurance Council
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 01 Mar 2007 12:56:35 -0000

On Wed, 28 Feb 2007 18:00:03 -0000, Eric Allman <[email-masked]>  
wrote:

> I'm tempted to say "well, duh."  That's the reason why senders will  
> probably want to support both A and B for a fairly long period.  But  
> there will always be some verifiers that do not upgrade, and at some  
> point the signers are going to drop support for A, and that will create  
> problems for verifiers who haven't upgraded.
>
> If the transition is short, then I'll be concerned about it.  But if the  
> transition is multiple years and the verifiers still haven't upgraded  
> I'm not going to lose any sleep over it.  By the way, this is Assumption  
> 2.
>
> If a signer does go from SA to SB without passing through SAB (or not  
> maintaining it long enough) then they will be hurting themselves,

So you are saying, and I think we all agree, that the period during which  
the signer implements SAB needs to be at least O(Months) but not O(Years).

But O(Months) is still quite a long time, and provides a sufficient window  
of opportunity for a spammer to mount this attack.

> since (Assumption 5, from my previous mail to Charles, saying that  
> verifiers actually implement the spec as written) their mail will be  
> treated like any unsigned message --- which in the long run means  
> "poorly".

What verifiers actually implement will in the Real World (TM) be what  
their customers pay them to implement.

If they let through too much spam/phish/whatever, their customers will go  
elsewhere.

If they fail to let through too many genuine messages, their customers  
will go elsewhere.

Here we have an exploit that works against a verifier that tries to help  
his customers by letting through mails that are most likely genuine. A  
fairly simple cure for this exploit has been suggested (extra information  
in the SSP, though other cures might work as well).

So why not let that cure go into the SSP (or any other adequate cure), and  
move on to next business. The cure is not expensive; it improves security;  
so why not implement it?

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html