Hallam-Baker, Phillip wrote:
From: Stephen Farrell [mailto:stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie]
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).
No, if you have a signature that does not verify you treat it as if it did not
exist and reject the message under rule 2.
Good.
Treating a message with an invalid signature as if it was unsigned means
precisely that. Unsigned messages go to the bit bucket and bogus signatures
follow them. The problem that some people seem to be having here is that they
have internalized this as 'failed signatures don't matter' which is not the
case when you have policy. The whole point of policy is to allow a signer to
allow receivers to take a different path when they notice the absence of a
signature.
Providing a specified, deterministic path for this processing is vastly better
than waiting for receivers to develop heuristics to induce the same information
based on the number of legitimate messages they see that carry signatures.
Paypal messages do not get routed through mailing lists so a message with a
broken sig is either the result of forwarding (which is checkable),
misconfiguration at Paypal (which is unlikely and means bit bucket) or fake
(bit bucket).
So the *only* time you want to content-filter the message (in this
example case) is where the message is ostensibly signed with some
DKIM parameter (like sig-alg,c14n) that the receiver doesn't support
and where the sender's SSP declares that they do, in fact, emit
messages with that parameter value.
Is that true?
Can you say how you think this pans out for less-phished
originating domains?
S.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html