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

From: Douglas Otis <[email-masked]>
Date: Wed, 24 May 2006 18:29:21 -0700

,---
|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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 25 May 2006 07:36:35 +0100

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:
> :    in the response.  Responses beginning with a "v=" tag with any other
> ---------------------------------------------------------------------------
> 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.
> 
> their new signature might be "unsupported" will mean recipients will be 
> unable to differentiate a "spoofed" algorithm from that of a truly 
> "unsupported" algorithm.
> 
> 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 
> 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 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
>

---

From: Russ Housley <[email-masked]>
Date: Thu, 25 May 2006 09:29:23 -0400

[As an individual contributor]

I assume that the "deprecated keys" are stored in the DNS.  If so, 
the algorithm is an attribute of the key stored in the DNS.

The "Other Algorithms" section seems like an odd place in the 
document to talk about the mechanism for deprecating keys.

If the DNS contains two keys and one is deprecated and the other is 
not, then the verifier should only make use of the non-deprecated 
key, regardless of the algorithm associated with each of the keys.

Russ

---

From: Douglas Otis <[email-masked]>
Date: Thu, 25 May 2006 07:03:24 -0700

> key, regardless of the algorithm associated with each of the keys.

During a transition, many verifiers will not recognize a newer
algorithm.  Many signing domains will not wish to appear to offer no
signatures, as would occur during such an abrupt transition without two
signatures being usable.  When there is a deprecated key algorithm, the
verifier must not ignore all unknown algorithms, but instead must verify
that a non-deprecated key algorithm is being offered by the signing
domain, even when the algorithm may be unimplemented by the verifier.
This check prevents algorithm spoofing.

This text allows the use of the deprecated signature only when the other
signature is not implemented:
 
: 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."

-Doug