[ietf-dkim] RFC4871bis - whether to drop -- k: Key type
dotis at mail-abuse.org
Thu Jun 4 14:18:30 PDT 2009
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
Why are we going over this again?
More information about the ietf-dkim