Hallam-Baker, Phillip wrote:
NO MALLET PERFORMS A SUCCESSFUL DOWNGRADE ATTACK.
I could quibble. That's not a downgrade attack since Alice
parallel-signed with both. This is different from bidding
down with spnego/gssapi or SSL where there may be an "export"
option, but I don't want to end up there unless I've no
other option.
Alice also had the option of sequentially signing if
she considers one alg better than the other.
As far as Bob is concerned the email is in compliance with policy so he has to accept the message as being compliant with the
signature policy even though it is not.
I'd be more of the opinion that it is fine since Alice
did sign with rsa2048. If she doesn't consider that ok,
she should have just signed with zsa. It is arguable
though, I agree.
Alice MUST have a way to state "I always sign with BOTH ZSA AND RSA2048".
Sure - invent an "zsaandrsa2048" algorithm:-) Bit I don't see the
reason for the MUST, since this only affects a Bob who's happy
with rsa2048, and who is therefore vulnerable to whatever problems
exist for that algorithm regardless of Alice's policy.
Otherwise merely publishing a ZSA key record effectively allows an attacker to
nullify the signature policy record altogether.
I don't agree. (And it assumes the existence of the record - see
below.)
In effect the lack of the AND policy statement means that it will never be possible to upgrade to a new algorithm without rendering the policy specification void.
There may or may not be a need for a separate AND construct but
that's another layer of detail.
What Bob will do differently in this case is to accept a message as compliant
with policy that should be rejected as non-compliant. That is huge. It gives
Mallet an opening to defeat the attack SSP is intended to prevent.
Isn't a lot of this a circular argument? The justification for
adopting this as a policy requirement is that it allows Bob to
detect adherence to this policy.
If you could state an advantage in terms of collision-dodgy
signature/hash algorithms then maybe it'd convince folks more.
(Or, maybe not, we'll see.)
And again - you've not said what's new here that causes us to
end up with a different answer about this compared to when the
WG considered it for base? (Or maybe you did and I missed it;-)
Stephen.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html