Doug,
This is still issues 1184 and 1196 which we seem to have consensus
to regard as CLOSED. Absent support from (2) others for such changes
we won't reopen those.
Stephen.
PS: Keys are not deprecated, algorithms are. The analogous action for
keys is presumably revocation. No need to reword this though, since
the issues have been handled already.
Douglas Otis wrote:
,---
|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
tohttp://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html