Preventing an exploit during a transition.
Described in the draft and adds the newlist:
draft-otis-dkim-security-concerns-00.txt
3. Deprecated Versions
http://tinyurl.com/o5wh3
,----
| 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, 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.
'____
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 a non-deprecated version of a signature from the
: same domain is supported, this signature should be
: used in preference to a signature marked as
: deprecated. When an unsupported signature is found
: from a domain where the only other signature is
: marked as deprecated, the version details listed
: within the 'n=' parameter of the deprecated
: key must match the values found within the
: unsupported signature, otherwise the deprecated
: signature should be ignored. 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
| ...S
| 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"
'___
Change to:
: 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-sv ["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"
|...
| n= Notes that might be of interest to a human (quoted-printable;
| OPTIONAL, default is empty). No interpretation is made by any
| program. This tag should be used sparingly in any key server
| mechanism that has space limitations (notably DNS).
|
| ABNF:
|
| key-n-tag = %x6e [FWS] "=" [FWS] qp-section
'___
Change to:
: 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.
:...
: n= Notes that might be of interest to a human and, when
: version for the key is marked "deprecated", the
: VAQ values of the concurrent non-deprecated
: signature are prepended (quoted-printable; OPTIONAL,
: default is empty). Except for the version details, no
: interpretation is made by any program. This tag should
: be used sparingly in any key server mechanism that has
: space limitations (notably DNS).
:
: ABNF:
:
: new-v = <non-deprecated sig 'v=' value>
: new-a = <non-deprecated sig 'a=' value>
: new-q = <non-deprecated sig 'q=' value>
: new-list = "|" new-v "|" new-a "|" new-q "|"
: key-n-tag = %x6e [FWS] "=" [FWS] [new-list] qp-section
:
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html