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

[Douglas Otis]

On Jun 4, 2009, at 3:46 PM, Jon Callas wrote:

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

First assume there is a _real_ transition to different DKIM algorithms  
sporadically occurring.  Perhaps based upon being targeted by bot-net  
resources.

An attacker spoofs a K_2 signature referencing a sender's K_1 key.   
Due to the lack of key assertions, the reference creates an appearance  
that the signature might be "unverifiable" rather than "invalid" or  
"spoofed".

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

The attackers know recipients have found _some_ signatures are not  
supported by their provider.  Due to the lack of key assertions,  
attackers will not need to use untrusted key domains, or to only spoof  
the domains using new algorithms.

> * Receiver verifies E_1 and accepts it as having a valid signature.  
> This is normal, expected DKIM operation.

Recipients now see many spoofed unverifiable signatures, in which some  
are legitimate messages.  They may even be aware of the situation in  
the news.  Being able to confirm whether the purported signer employs  
a new algorithm would reduce the level of this type of spoofing, since  
it would work against only a few select domains, of which many  
recipients may not care about, or might know how to identify through  
some other means, such as selected pass-phrases.  One might also  
expect that transitioning legitimate signers could offer utilities to  
confirm their signature whenever a provider might not.

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

Again, this issue is about algorithm agility.  A means to transition  
while avoiding confusion.  When a domain becomes targeted, it might  
become necessary to abandon widely adopted algorithms.

> Is this the scenario you're describing as being undiscussed?

No.

-Doug