,---
|3.3.3 Other algorithms
|
| Other algorithms MAY be defined in the future. Verifiers MUST ignore
| any signatures using algorithms that they do not understand.
'___
Change to:
: Other algorithms MAY be defined in the future. Unless there is a
: signature from a signing domain marked as "deprecated", verifiers
: MUST ignore signatures indicating unimplemented algorithms.
:
:
: Signatures referencing "deprecated" keys must be considered invalid
: without the presence of signature from the same signing domain
: referencing a key not marked as "deprecated", also supporting the
: indicated algorithm. Verifiers MUST also ignore signatures
: referencing "deprecated" keys when a different signature from the
: signing domain is found offering an implemented algorithm referencing
: a key not marked as "deprecated."
-------- (key)
| 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"
'___
Change to:
: v= Version of the DKIM key record (plain-text; RECOMMENDED, default
: is "DKIM1"). If specified, this tag MUST be set to "DKIM1"
: or "DKIM1-" (without the quotes). This tag MUST be the first tag
: in the response. Responses beginning with a "v=" tag with any
other
: values MUST be discarded. A version identifier ending with the "-"
: character indicates the record contains a "deprecated" key.
:
: ABNF:
:
: key-v-tag = %x76 [FWS] "=" [FWS] "DKIM1" / "DKIM1-"
,---
| h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to
| allowing all algorithms). A colon-separated list of hash
| algorithms that might be used. Signers and Verifiers MUST
| support the "sha1" hash algorithm.
'___
Change to:
: h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to
: allowing all algorithms). A colon-separated list of hash
: algorithms that might be used. Signers and Verifiers MUST
: support the "sha1" hash algorithm. When present, an
: acceptable hash MUST match the text following the hyphen
: within the value for the DKIM signature field "a=" tag.
,---
| k= Key type (plain-text; OPTIONAL, default is "rsa"). Signers and
| verifiers MUST support the "rsa" key type. The "rsa" key type
| indicates that an RSA public key, as defined in [RFC3447],
| sections 3.1 and A.1.1, is being used in the p= tag. (Note: the
| p= tag further encodes the value using the base64 algorithm.)
'___
change to:
: k= Key type (plain-text; OPTIONAL, default is "rsa"). When present,
: the key type MUST match the text preceding the hyphen within the
: value for the DKIM signature field "a=" tag. Signers and
: verifiers MUST support the "rsa" key type. The "rsa" key type
: indicates that an RSA public key, as defined in [RFC3447],
: sections 3.1 and A.1.1, is being used in the p= tag. (Note: the
: p= tag further encodes the value using the base64 algorithm.)
------------------------------------------------------------------------
---
Rationale:
A transition to a different algorithm may permit several security
lapses.
There is a current requirement that a signature MUST be ignored when
the algorithm indicated within the signature contains unknown text.
The 02 base draft offers NO sure means to refute a spoofed signing
algorithm.
Any sudden change in algorithm due to an unexpected setback creates a
serious quandary when there are signatures anticipated for critical
domains. If this situation is resolved by reporting in some fashion
their new signature might be "unsupported" will mean recipients will
be unable to differentiate a "spoofed" algorithm from that of a truly
"unsupported" algorithm.
The duration of resulting confusion will be extended when bad-actors
take advantage of that transition.
One possible strategy would be the signing domain offering two
signatures, a strong and a weaker (but widely implemented), to avoid
the situation where suddenly their messages appear to be unsigned, as
they will appear according to the 02 base draft. By including both
signatures however, the mere existence of the weaker signature may
enable bad-actors to continue an exploit of these messages, even when
most recipient's verifiers have implemented the stronger algorithm.
Ensuring at least some protection is retained by offering two
signatures will likely span a sizable period of time waiting for most
receiving systems to upgrade.
The "deprecated" flag together with an assured means to refute an
unknown algorithm ensures a bad-actor's ability to exploit the weaker
algorithm is limited to _only_ those verifiers unable to support the
stronger algorithm.
----
The criminal nature of email and the Internet has changed over the
last few years. Many emails are being sent through bot-nets that
comprise _millions_ of compromised systems working in concert, often
using hard to detect encrypted command and control. The DKIM opaque-
ID and reliance options were aimed at problems related to where tens
of thousands of fraudulent accounts are established each day using
unique, valid, albeit stolen credit-card information, and where
hundreds of thousands of compromised computers are also
surreptitiously accessing pre-existing accounts. : (
The sheer size of these bot-nets and the level of the criminal
activity may require different strategies, a rethink, regarding what
is considered adequate security and DDoS protections. As DKIM
attempts to confront this highly skilled and highly criminal element,
being prepared to react quickly without creating a sizable disruption
seems highly prudent, if not absolutely necessary. This minor change
is intended to ensure the possible disruption caused by an unexpected
algorithm transition is minimized.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html