(This is an idea that germinated from discussions at the DKIM summit
in Santa Clara yesterday, and I'd like to bring it on-list. It's not
my idea, but I think it's a good one).
Hopefully it's obvious to all that the algorithms we pick today for
signature and hash calcs will not survive the lifetime of DKIM. Many
will have seen sha256 popping up as a potential replacement for sha1.
It's been said before that the most obvious solution to supporting
algorithm upgrades consists of three parts:
o a signer MUST sign with the strongest algorithm and MAY
additionally sign with a weaker algorithm. In short, multiple
signature headers.
o a verifier MUST select the strongest signature they recognize and
verify with that. All lessor signatures are ignored.
o A future spec that defines new algorithms MUST define relative
strengths. Eg, sha256 is stronger than sha1. If relative strength
is not clear, then why introduce a new alg?
While that provides a transition mechanism and a backward
compatibility mechanism, it is vulnerable to downgrade attacks.
For example, say a vulnerability is found in sha1 and a future spec
defines sha256 as the stronger hash alg. A dutiful signer will
generate a sha256-based signature and an sha1-based signature.
The downgrade attack is to remove the stronger sha256-based signature
and apply the attack to the weaker sha1-based signature.
The problem for the unwitting verifier is that they don't know the
signer originally added a stronger signature. All they see is the
weaker sha1 signature.
The simple solution is to provide an indication to the verifier that
the signer generates a stronger signature. That indication could
possibly go in one of three places:
o SSP, but that's not normally consulted on a successful verify.
o The signature header, but all message content is vulnerable to the
downgrade attack so the indicator cannot be trusted.
o The Selector of all the signatures excepting the strongest.
The latter seems the best choice and is the crux of the idea.
Picking some random tag, say, U= which indicates that this is a
downgrade Selector. The rules become:
o a signer MUST sign with the strongest algorithm and if they also
add signatures with weaker algorithms, the Selectors for those
weaker algorithms must have a U= tag.
o a verifier MUST select the strongest signature they recognize and
verify with that.
Assuming verification success:
o If the Selector of the strongest recognizable signature has no U=
tag, then accept the verification.
o If the Selector of the strongest recognizable signature has a U=
tag *AND* the verifier is capable of recognizing stronger, then
reject the verification as a potential downgrade attack.
o If the Selector of the strongest recognizable signature has a U=
tag *AND* this is the strongest signature recognized by the
verifier, suggest to your owner that you upgrade and cautiously
accept the verification.
With just one algorithm upgrade that logic works just fine. However,
with two or more upgrades, we need to introduce further logic; here's
why.
In a future world, what if DKIM has evolved to support three hash
algs: rsa1, rsa256 and rsa1024? Let's say the verifier recognizes rsa1
and rsa256. The signer OTOH is more modern and additionally knows
about rsa1024.
If the signer were to sign with rsa1024 and rsa1, then the verifier
will think such an email is a downgrade attack as it will recognize
the rsa1-based sig and detect a U= tag. However it will not recognize
the stronger sha1024-based sig and thus conclude a possible downgrade
attack.
The gap created by the signer is the problem here so the rule needs to
be that a signer must sign from strongest to weakest, WITH NO GAPS.
A signer need not use every algorithm, it simply cannot create gaps, so
Asha1024 and sha256 is fine as is a sole sha1024. While sha256 and
sha1 do meet the "no gaps" requirement, they do not meet the "use the
strongest you know" requirement.
Mark.
_______________________________________________
NOTE WELL: This list operates according to
http://dkim.org/ietf-list-rules.html