Phill,
Hallam-Baker, Phillip wrote:
Mallet can produce a forgery of a message by Alice that is
100% certain to be considered in compliance with policy - the
signature value just won't verify.
The difference is that a signature that does not verify is treated as if it was
not present and thus the message is not in compliance with policy.
So if a mailing list mangles a message then you'd consider the message
as no longer being policy-compliant? I guess that's one reasonable way
to look at it, but I don't believe its the only reasonable way. I could
equally treat this as a case where the message appears to conform to the
policy, but fails signature checking.
Sounds a bit like an implementation issue.
Verifiers must be able to treat the following conditions differently:
"There is a signature here that I cannot verify"
"There is a signature here that fails the verification process I support"
Verifiers can already handle that difference all by themselves, even
without SSP.
(As an aside - I could imagine someone wanting to allow SSP to say
something like "if you encounter error <foo> when processing a
message apparently from me, then I'd recommend that you <bar>"
and where we'd define a foo="unsupported sig-alg" and maybe have
bar="barf". But that leads down the mandating-recipient-behaviour
rathole and may be better tried out via whatever extensibility
mechanism ends up in SSP.)
What the attack does is to convert the policy Alice intends to express "I always provide a
signature that you can validate" into "I always provide a signature but you may not be
able to check it". That is a crucial difference.
I guess I'd just place a different emphasis on this than you, but
we'll see what consensus emerges as we go,
Stephen.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html