[ietf-dkim] RFC4871bis - whether to drop -- k: Key type

[Douglas Otis]

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