ietf-dkim
[Top] [All Lists]

[ietf-dkim] base-02 // worst-case scenario/duration of exploit/use of deprecated

2006-06-07 17:59:47
Definitions:
 Deprecated - Will be made invalid or obsolete in the future.
 Obsolete   - Is currently invalid.
-----

Although a worst-case scenario is highly unlikely, the objective is to review an exigent transitional change in either a DKIM signature service or algorithm. A highly targeted attack using substantial resources is a moderately plausible threat to the protections offered by DKIM, where such an attack may permit only an intermittent exploit.

Much like a balking car, a repair is likely to be sought in conjunction with continued use. (A worst case situation from a protocol standpoint.) An intermittent exploit may cause the available DKIM services or algorithms to be considered deprecated by an affected target with respect to their outbound messages. After upgrading to support a better alternative, the affected domains still needs to offer the deprecated signature by adding two signatures. Two signatures are required when a significant number of verifiers have yet to upgrade.

Abruptly dropping a supported signature in favor of a better but poorly supported alternative will cause recipients to see their messages as unsigned. This strategy will cause most of their recipients to once again experience a flood of fraud by more bad actors. These bad actors now only needed to include a spoofed signature, and may have otherwise lacked the resources to achieve the intermittent exploit. With this outcome, an abrupt transition from a faltering signature version is an irresponsible strategy. Instead, providing two signatures is the responsible action during an exigent transitional two signature phase seeking to thwart the intermittent exploit.

As the targeted entity would be the first to upgrade, knowledge of what represents a deprecated signature is initially understood by only those few domains. Even after a verifier has upgraded, during the two signature transitional phase, the verifier is still unable to discern which MTA has upgraded. Without the signing domain able to communicate what they consider to be deprecated within prior signature constructs, intermittent exploits will continue. This exploit remains viable during the transition even when both the signing and verifying domain have upgraded. A diminished benefit for early upgrading may also slow adoption of the improvement.

There must be a parameter within the existing signature header and key that conveys which signing domain has upgraded. Logically, as any element of the DKIM signature might be affected, the signature version should offer a value that declares that the signing domain now considers this version of the DKIM signature to be deprecated. In essence, this signature is offered only for compatibility during a two signature transitional phase.

The current base draft expects verifiers, irrespective as to whether the signing domain upgraded, to abruptly ignore a deprecated (rather than obsolete) signature. This behavior is highly disruptive when only a small number of domains have adopted the alternative. The verifier ignoring deprecated signatures early within a transitional phase exposes most of their recipients to a flood of fraud instead of a few intermittent instances.

This outcome, caused by a not having a ready means to communicate the version level of the signing domain, implies an intermittent exploit will likely continue over the entire transitional phase, perhaps measured in years. In contrast, with a means for the signing domain to communicate the status of a signature's version, adoption by the affected domains and by a number of major ESPs can then restore protection for most most recipients within weeks without the need for any out-of-band communication. This rapid recovery of DKIM protections should help promote the upgrade.


---------------------
,----
| 4. Semantics of Multiple Signatures
| ...
| When evaluating a message with multiple signatures,
| a receiver should evaluate signatures independently
| and on their own merits.  For example, a receiver
| that by policy chooses not to accept signatures
| with deprecated crypto algorithms should consider
| such signatures invalid.  As with messages with a
| single signature, receievers are at liberty to use
| the presence of valid signatures as an input to
| local policy; likewise, the interpretation of
| multiple valid signatures in combination is a local
| policy decision of the receiver.
'____


Change to:

: When evaluating a message with multiple signatures,
: a receiver should evaluate signatures by different
: signing domains independently.  A receiver,
: that by policy considers a crypto algorithm or
: service to be obsolete, should ignore the signature
: and consider it invalid.  Multiple signatures by the
: same domain must include at least one signature
: version that has not been marked as deprecated.
: When an alternative version of a signature is
: from the same domain is supported, this signature
: should be used in preference to a signature marked
: as deprecated.  As with messages with a single
: signature, receivers are at liberty to use the
: presence of valid signatures as an input to local
: policy; likewise, the interpretation of multiple
: valid signatures in combination is a local policy
: decision of the receiver.

,---
|3.5 The DKIM-Signature header field
| ...
|    v=
|        Version (MUST be included). This tag defines
|        the version of this specification that applies
|        to the signature record. It MUST have the
|        value 0.2.
|
|      ABNF:
|
|         sig-v-tag   = %x76 [FWS] "=" [FWS] "0.2"
'___


:    v=
:        Version (MUST be included). This tag defines
:        the version of this specification that applies
:        to the signature record. It MUST have the
:        numeric value 0.2.  The signing domain may
:        mark the signature as deprecated by appending
:        a "d" character to the version value.
:
:      ABNF:
:
:         dkim-sv      = "0.2"
:         sig-v-tag   = %x76 [FWS] "=" [FWS] dkim-v ["d"]
:

,---
| 3.6.1 Textual Representation
|...
| v=
|     Version of the DKIM key record (plain-text;
|     RECOMMENDED, default is "DKIM1"). If specified,
|     this tag MUST be set to "DKIM1" (without the quotes).
|     This tag MUST be the first tag in the response.
|     Responses beginning with a "v=" tag with any other
|     value MUST be discarded.
|
|   ABNF:
|
|       key-v-tag    = %x76 [FWS] "=" [FWS] "DKIM1"
'___


: v=
:     Version of the DKIM key record (plain-text;
:     RECOMMENDED, default is "DKIM1"). If specified,
:     this tag MUST be set to "DKIM1" (without the quotes).
:     This tag MUST be the first tag in the response.
:     Responses beginning with a "v=" tag with any other
:     numeric value MUST be discarded.  The signing domain
:     may mark the key as deprecated by appending
:     a "d" character to the version value.  When the
:     DKIM-Signature version is marked as deprecated,
:     the DKIM-Key version MUST BE included and marked as
:     deprecated.
:
:    ABNF:
:
:      dkim-kv      = "1"
:      key-v-tag    = %x76 [FWS] "=" [FWS] "DKIM" dkim-kv ["d"]
:
:     INFORMATIVE IMPLEMENTATION NOTE:  The DKIM Signature and
:     Key versions will both have the numeric value "1" in the
:     final draft.

-Doug










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

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