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]
Why? Surely all that can happen is stripping of the
stronger sig and
we already decided that that wasn't a bother for base, so
why is it a
problem now? (Maybe I mis-remember but I think we decided it was a
non-problem, not that it was a problem to punt to SSP.)
Alice decides to sign with ZSA which has just been approved, few
people support ZSA so she also signs with RSA2048
Bob's mail gateway does not support ZSA.
Mallet strips out the RSA2048 signature, modifies the
message and leaves in the ZSA signature.
Bob can see that there is a signature which points to a
valid key record but has no way to verify it and no way to
know that it does not comply with Alice's signature policy.
So what? What will Bob do differently when his DKIM code sees
that Alice sometimes/always signs with ZSA and/or RSA2048? Complain?
He'll probably do that anyway knowing Bob:-)
Mallet's not getting much out of it either - maybe he'd be
better off flipping a plaintext bit really since then Bob'd
do more work.
NO MALLET PERFORMS A SUCCESSFUL DOWNGRADE ATTACK.
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.
Alice MUST have a way to state "I always sign with BOTH ZSA AND RSA2048".
Otherwise merely publishing a ZSA key record effectively allows an attacker to
nullify the signature policy record altogether.
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.
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.
The selector mechanism is a simple fix.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html