ietf-dkim
[Top] [All Lists]

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

2007-02-26 04:34:24

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(_dot_)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(_dot_)man(_dot_)ac(_dot_)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

<Prev in Thread] Current Thread [Next in Thread>