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

[Jon Callas]

-----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-----