-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Jun 4, 2009, at 2:18 PM, Douglas Otis wrote:
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
Again, forgive me, Doug, but what is the issue that's not being
discussed? I genuinely don't understand what you're trying to say.
I don't mean to put words in your mouth, but are you saying describing
this use case:
* Sender puts a key K_1 into the DNS. K_1 is of algorithm A_1, but the
DNS entry does not note this fact.
* Sender creates an email E_1 that is signed with K_1 and sends it to
Receiver.
* Attacker creates a key K_2 that is of algorithm A_2.
* Attacker creates an email E_2 that is forged from sender, and signed
with K_2, but refers to the DNS entry for K_1. Attacker sends this
email to Receiver.
* Receiver verifies E_1 and accepts it as having a valid signature.
This is normal, expected DKIM operation.
* Receiver verifies E_2 and accepts it has having a valid signature.
This is erroneous behavior because it was verified with A_1 despite
having been generated by A_2.
Is this the scenario you're describing as being undiscussed?
Jon
-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.6.3
Charset: US-ASCII
wj8DBQFKKE7esTedWZOD3gYRAso8AKDyEUmvvwP6QZyjhIuCbOCc4FO5yACfZzov
Ars589Xjft/SAJ6RZkwo25U=
=uAt9
-----END PGP SIGNATURE-----
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html