[ietf-dkim] Proposal for specifying syntax and semantics for multiple signatures

[Douglas Otis]

On Apr 3, 2006, at 1:14 PM, Eric Rescorla wrote:

> Douglas Otis <dotis at mail-abuse.org> writes:
>
>> On Apr 3, 2006, at 9:53 AM, Arvel Hathcock wrote:
>>
>>>> 1. Whether we want to have a mechanism to let the signature survive
>>>> the reordering of multiple sig headers or not.  I've heard Mike and
>>>> Dave say no, we don't.  Is that correct?
>>>
>>> I've also said it's added complexity that I don't think we need.
>>>
>>>> 2. Whether we want to be able to detect the removal of a signature
>>>> header (as perhaps in the case of a "stronger" one and leaving a
>>>> "weaker" one).  I think the consensus is that we don't care about
>>>> this; I'd like to confirm that.
>>>
>>> Right, we don't care about that.
>>
>> Email can not easily negotiate these algorithms.  Are you  
>> expecting to sign messages differently for each recipient?
>>
>> A verifier must be able to detect when a stronger signature has  
>> been removed when two signatures are offered.  Without this  
>> ability to detect such a removal, all verifiers and senders will  
>> remain at risk to a downgrade attack during perhaps a _very_ long  
>> algorithm transition period.  It requires very little to repair  
>> this problem at the outset.
>
> Sorry, I still don't understand what the purpose or impact of this  
> attack is. Can you explain?

An attack may be enabled by replaying a message compromised due to a  
weak hash, key, or canonicalization algorithm.

For example, a message is signed with two signatures by example.com.   
The secondary signature with the prior algorithm is added to the  
message to permit a transition to occur.  This change will take time,  
even after exploits have been noted.  To protect verifiers that have  
implemented the stronger algorithm and to accommodate verifiers still  
not upgraded, two or more signatures are added to the message.   
Assume a bad actor knows how to modify the content of a previously  
signed message by inducing the same hash.  This hash technique only  
works for the prior algorithm, so the bad actor excludes the  
resistant signature in their replayed compromised message.  DKIM does  
not encompass elements of the message envelope, only the message  
contained within the envelope.  This permits the bad actor a fair  
amount of freedom to exploit a compromised message.

During a transition phase, perhaps a primary and secondary signature  
are added to a message.  A means is needed to protect verifiers from  
a possible exploit that "downgrades" the selection of algorithms  
normally offered by the sender to only being that of the secondary  
signature with the depreciated algorithm.  Marking keys as primary  
and secondary permits detecting the removal of a stronger algorithm  
when only finding secondary signature/keys from the signing domain.

When the verifier discovers an unknown primary algorithm, the  
verifier should confirm the sender offers the algorithm in the  
primary key.  This would be done by establishing a consistent method  
to identify the algorithms in both the signature and key.  Normally  
this is done using a numbered index in an IANA table.  This is _not_  
a property of DKIM as it is currently defined.   Mark at least one of  
perhaps several signatures/keys added to the message as primary, and  
those signatures using soon depreciated algorithms as secondary.  Any  
verifier that implements the newer algorithm would therefore be  
protected from messages where bad actors have exploited a weakness  
found in the depreciated algorithm, even though both the sender and  
verifier supports the newer algorithm.  The verifier would prefer the  
primary key when supported by the verifier.  If the algorithm in not  
supported by the verifier, the verifier confirms the sender offers  
newer algorithm.  The verifier could then utilize the secondary  
signature and perhaps make some message annotation.  If only a  
secondary signature/key were discovered for the message, the message  
could be rejected.

-Doug