On Jun 4, 2009, at 11:34 AM, Jon Callas wrote:
On Jun 3, 2009, at 10:53 PM, Eliot Lear wrote:
The basic question is simply this: is it sufficient to list the key
algorithm in the header? I don't see a plausible attack, so I'm
okay with that. But let's at least have the debate based on facts.
It is in fact sufficient to list the key algorithm in the header.
Let us suppose for the sake of argument that the DNS contained an
undifferentiated bag of bits. There is no plausible attack against
that. You can't lie to someone and get them to get a false
positive. Or to phrase that another way, if you could do it, then
there's a Best Paper award waiting for you at the next CRYPTO and
you'll be catapulted into the limelight for your crypto-fu. It would
likely also be a new fundamental result in core mathematics, as well.
This non-issue overlooks the intended goal of the k= parameter within
the key that is not being discussed. When is it safe to decide
algorithm agility is not improved by assertions that allow senders to
explicitly indicate their supported the algorithm which may differ
form an unverifiable DKIM signature? Clearly, such messages should be
outright rejected, whereas the alternative would require the recipient
to wonder why the signature failed.
What problem might be created when this feature remains as currently
defined?
Why are we going over this again?
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html