Hallam-Baker, Phillip wrote:
From: Stephen Farrell [mailto:stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie]
Hi Phill,
Hallam-Baker, Phillip wrote:
The sequence of events hypothesized is:
1) Sender determines that the existing algorithm is deprecated
2) In response to (1) sender prepares to support an additional
signature algorithm
3) In order to support (2) sender publishes an additional
key record
for the new algorithm
4) Mallet starts sending bogus messages with forged signatures
purporting to be under the new key
5) Receivers that have not yet upgraded to support the new
algorithm are unable to determine that the messages with
forged signatures are inconsistent with the signer's policy.
I think that that is clear. However, what do you say to the
fact that anyone can produce a message with a bad signature
that does adhere to such a policy? (By looking up the policy
or copying a real example.)
The two examples you give are entirely different.
No. I just wasn't clear. My point was that a bad guy most likely
doesn't have to lookup policy (via DNS) if he sees a message that
conforms - that's enough to derive loads of new messages that do
(probably) conform to the published policy. I wasn't considering
strict replay, only totally bogus messages.
Case 2: Policy at Paypal is 'I always sign with at least A'
1) If any signature under the paypal.com domain is valid the message is
accepted.
2) If there is no signature whatsoever the message goes in the bit bucket
3) If there is no signature with A the message goes in the bit bucket
4) If there was a signature with a key record in A for an algorithm that is not
understood then process the message using content filtering.
Eh..didn't you leave out:
5) Everything is policy-conformant, the receiver understands A,
but the signature bits are just wrong (since the message is
totally bogus).
That's the case I want to know about, since if that is really a
problem I see no clear benefit in the "...with at least A" part of
the SSP statement.
Stephen.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html