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

[Stephen Farrell]

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
>