Stephen Farrell wrote:
> The putative attack would be to sign with foo-sha256 where foo is some
> algorithm that a verifier supports and such that the foo key encoding could
> accept an rsa p= value as input and such that that combination allows the
> attacker to forge signatures.
>
> That's fairly theoretical, but there'd be a bit of work to go check that
> there is in fact no realistic situation where such confusion could arise. So
> on the whole, for me, keeping the k= just makes it easier to get things right
> now and in future.
If out-of-band algorithm/key-type registration like this is not a regular
"protection" mechanism provided in existing, related crypto-based schemes:
1) Why should it be only in DKIM?
2) Won't it need expert vetting by the security community to validate
that
the threat is real and the protection is sufficient?
I have been repeatedly taught by the security community to be extremely
cautious
about casual assumptions of what will fix a theoretical exposure. So, for
example, there have been cases where encrypting twice using the same algorithm
reduces protection rather than raising it. That ain't intuitive.
Same concern here.
Having this information maintained in the DNS isn't free and isn't certain to
be
safe.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
