ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] draft-ietf-dkim-base-02 //Deprecating keys and confirming algorithms

2006-05-24 23:40:35

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