ietf-dkim
[Top] [All Lists]

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

2006-04-03 15:02:54

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

Douglas Otis <dotis(_at_)mail-abuse(_dot_)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



_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>