-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)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(_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