1368 straw-poll : (was: Re: [ietf-dkim] Deployment Non-Scenario 7:Cryptographic Upgrade and Downgrade Attacks)

[Hallam-Baker, Phillip]

It seems to me that John is arguing that policy is a hopeless plan altogether. That might even be true in the short term. For SSP to be successful it will have to lead to a rapid decline in the type of remailer practices that cause the problems he is citing. 

I think that is feasible, John appears to not believe this is the case, that is a reasonable difference of opinion but as far as the group is concerned we have already decided to suspend out disbelief and do policy.

We have to be very careful here. If we allow arguments of this form we will guarantee defeat because it applies to every possible SSP variant. In effect we end up designing on the premise that we will inevitably fail so no modifications to SSP are worthwhile.



> -----Original Message-----
> From: ietf-dkim-bounces at mipassoc.org 
> [mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Stephen Farrell
> Sent: Monday, February 26, 2007 6:30 AM
> To: DKIM
> Subject: 1368 straw-poll : (was: Re: [ietf-dkim] Deployment 
> Non-Scenario 7:Cryptographic Upgrade and Downgrade Attacks)
> 
> 
> It seems to me that the exchange between John and Charles 
> below captures the crux of the issue.
> 
> Option 1: If we agree with Charles (& Phill I guess) that 
> looking up SSP and then passing on the only-signed-with-B 
> message will be common practice then there seems to be a 
> sufficient reason to include the "I sign all with A"
> statement or equivalent in SSP.
> 
> Option 2: If OTOH, we agree with John, that further 
> processing (after sig check & SSP lookup) SHOULD or MUST 
> treat the only-signed-with-B message as unsigned, with no 
> code branching on the presence of the putative B-sig, then 
> the additional SSP expressiveness is useless.
> 
> I don't see a rough consensus either way, though I would 
> guess I've seen a little more support for option 1 in the 
> last few days than for option 2.
> 
> Just to help me out, could you say which option you prefer?
> Thanks,
> Stephen.
> 
> PS: If you prefer some other option or would like to quibble 
> with my text above, feel free, but maybe change the subject.
> 
> 
> Charles Lindsey wrote:
> > On Sun, 25 Feb 2007 22:09:06 -0000, John Levine 
> <johnl at iecc.com> wrote:
> > 
> >
> >> Or I have a message that didn't have any good signatures.  I can't 
> >> tell whether that was because it was unsigned, it had a good 
> >> signature that broke in transit, it had a good signature that I 
> >> didn't know how to verify, or it had a bogus signature 
> applied by a 
> >> bad guy.  So, as a receiver, this is all the same situation, it's 
> >> unsigned.  If you believe that SSP can state "I sign 
> everything", you 
> >> might throw it away if that's what the SSP says.  Otherwise, what?
> > 
> > Eh? If it was unsigned, you know that.
> >     If it was signed with an algorithm you couldn't verify, 
> you know that,
> >     If the signature was broken, you know that (but not why 
> it was broken).
> > All those situations are to be classified as 'unsigned' (but more 
> > detailed information is available to you if you want to use it).
> > 
> > So, being "unsigned", you consult the SSP, which maybe 
> tells you "we 
> > sign everything". You might then reject it regardless on that basis 
> > and thus lose some genuine message simply because you 
> couldn't verify 
> > the algorithm in use; more likley, you would want to allow 
> such cases 
> > through (whilst also persuading your local geeks to 
> implement the new 
> > algorithm ASAP). But, in the example quoted (message signed only by 
> > unverifiable algorithm B) you would then accept the bogus 
> message. But 
> > an SSP response of "we sign everything with both A and B" 
> would allow 
> > you to accept genuine messages from that site (because you 
> can veriffy 
> > algorithm A) but reject the bogus one.
> >>
> >> How does a SSP list of signing algorithms provide any useful 
> >> information to a receiver?  Unless I'm missing something rather 
> >> fundamental, it doesn't.
> > 
> > --Charles H. Lindsey ---------At Home, doing my own 
> > thing------------------------
> > 
> > Tel: +44 161 436 6131                      
> >    Web: http://www.cs.man.ac.uk/~chl
> > Email: chl at clerew.man.ac.uk      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 
> > tohttp://mipassoc.org/dkim/ietf-list-rules.html
> > 
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
>