[ietf-dkim] RFC4871bis - whether to drop -- k: Key type
jon at callas.org
Thu Jun 4 15:46:46 PDT 2009
-----BEGIN PGP SIGNED MESSAGE-----
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
>> 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
> Why are we going over this again?
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
* 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?
-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.6.3
-----END PGP SIGNATURE-----
More information about the ietf-dkim