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

From: Douglas Otis <[email-masked]>
Date: Wed, 7 Jun 2006 17:32:03 -0700

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

---

From: <[email-masked]>
Date: Thu, 8 Jun 2006 09:08:28 -0400

Doug,
You are dictating what a sender and verifier must do. If I have a faulty
algorithm and change my keys to reflect the new ones I may not be
interesting in signing with what I consider a depreciated key. I signed
my mail, published a key and sent my mail. A receiver who gets old mail
that does not verify can use local policy to determine what to do.

Spammers recognizing a key change may flood the market with spuriously
signed messages purporting to be from me for a brief period of time but
I would expect that from non-depreciated key holders as well.

Your purported solution doesn't solve this. I could publish 7 keys 6
that are depreciated and spammers will still send out badly signed
email, it still resolves to local verification policy and all the
headers in the world wont change that.
Thanks,

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Douglas Otis
Sent: Wednesday, June 07, 2006 8:32 PM
To: IETF-DKIM
Subject: [ietf-dkim] base-02 // worst-case scenario/duration of
exploit/useof deprecated

Definitions:

---------------------
,----

Change to:

,---

:    v=

,---

: v=

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Thu, 08 Jun 2006 07:11:29 -0700

> that does not verify can use local policy to determine what to do.

The signing domain free to not sign with what they consider to be
unacceptable.  The added text does not prevent that at all, nor does it
require any special action in that case.  It only says that if you
"mark" a signature and key as deprecated, the signing domain must
include a signature and key that is not marked as deprecated.  This is
the _only_ added requirement for the signing domain.

The text was changed to call an unacceptable signature version obsolete
rather than deprecated, as deprecated implies soon to be obsolete.  The
verifier should use a signatures not marked as deprecated from the same
domain when possible, however the verifying domain may still consider
this remaining signature obsolete based upon their policy. 

> I would expect that from non-depreciated key holders as well.

This is what the change prevents. By brief, this could take years. Mark
the key you want to retire soon as deprecated, but this must accompany a
signature from the same domain not marked as deprecated.  This assumes
the damage caused by an erratic exploit is less than what you have just
described.  You have underestimated what is implied by brief. 

> Your purported solution doesn't solve this. 

Oh but it does.  This change requires that a message must include at
least one signature not marked as deprecated from the same domain.  This
assumes the deprecated signature has not suffered a complete failure,
otherwise a disruption can not be avoided anyway.

> I could publish 7 keys 6 that are depreciated and spammers will still
> send out badly signed email, it still resolves to local verification
> policy and all the headers in the world wont change that.

The requirement that a non-deprecated signature must be included means
that once the verifier becomes upgraded, an erratic exploit is
prevented.  This can happen much sooner than expecting all to upgrade.

The difficult case is dealing with something that is not completely
broken.  Your car is sputtering, but rather than calling for a tow truck
and a cab, you continue driving until you make it to a garage that can
make the repair.  An abrupt change in signatures would be like calling a
tow truck every time the engine sputtered.  That action will likely
astonish your recipients who will likely consider this a poor choice
when a less disruptive solution was available (or at least could be
available by making a minor change to the version ABNF in the base).

> :        to the sign
> http://mipassoc.org/dkim/ietf-list-rules.htmlature record. It MUST have the

-Doug