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
bill(_dot_)oxley(_at_)cox(_dot_)com
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] 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:
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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html