Subject: [ietf-dkim] Base-02 //Deprecated Signature Version & New List

From: Douglas Otis <[email-masked]>
Date: Thu, 22 Jun 2006 07:18:34 -0700

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

---

From: Eric Allman <[email-masked]>
Date: Thu, 22 Jun 2006 10:45:06 -0700

There are many reasons I don't like this proposal.  Let me start with 
the easily fixed ones:

(1) Overloading existing tags to add new functionality is absurd. 
Adding "d" to the end of the version has nothing to do with the 
version; this should be a flag.  Similarly, changing the n= tag 
(which is supposed to be nothing more than human-readable "note" 
text) to have additional semantics is bizarre; it should be a new tag.

(2) I'm getting a bit tired of seeing new terms used that have never 
been defined.  What's a VAQ value?  Based on Google it seems to mean 
"Value Added Quest" (a competition for all West Australian students). 
Or maybe Soctiabank's "Value Added Quarterly".  It's also a military 
abbreviation for "Naval Tactical Electronic Warfare Squadron" 
(derivation unclear).  Oh wait, maybe it means the values of the v=, 
a=, and q= tags.  Now why not just say that in the first place?

And the more basic issue:

(3) Wasn't the issue of downgrade attacks discussed in Dallas and 
resolved on the list?  In specific, it was issue 1196 (Upgrade 
indication and protection against downgrade attacks).  As near as I 
can tell, the exact same issues that Doug is raising were discussed 
in this issue, and a frankly much more elegant approach was proposed. 
Why is this issue alive again?

eric

---

From: Michael Thomas <[email-masked]>
Date: Thu, 22 Jun 2006 11:11:09 -0700

Eric Allman wrote:

> can tell, the exact same issues that Doug is raising were discussed in 
> this issue, and a frankly much more elegant approach was proposed. Why 
> is this issue alive again?

That was my recollection too. Mark proposed something a long while back
which seemed like it would work, but the consensus was that we didn't need
the complexity, etc, given the threats so the entire subject was dropped.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Thu, 22 Jun 2006 12:13:26 -0700

On Jun 22, 2006, at 10:45 AM, Eric Allman wrote:

> There are many reasons I don't like this proposal.  Let me start  
> with the easily fixed ones:
>

The version of the signature (when something changes that breaks  
compatibility with existing verifiers) is really what is being  
declared deprecated.  It seems modifying version ensures this feature  
remains upwardly compatible, as the intent is to condition use of a  
deprecated version of DKIM.  Modification of the v= and n= could be  
combined with a c= flag that indicates a requirement for a concurrent  
version during a two signature transition.  This could be  
c=<signature version of concurrent key>.  To be more complete, it  
could also cover v= a= q= separated by "|".

> (2) I'm getting a bit tired of seeing new terms used that have  
> never been defined.  What's a VAQ value?  Based on Google it seems  
> to mean "Value Added Quest" (a competition for all West Australian  
> students). Or maybe Soctiabank's "Value Added Quarterly".  It's  
> also a military abbreviation for "Naval Tactical Electronic Warfare  
> Squadron" (derivation unclear).  Oh wait, maybe it means the values  
> of the v=, a=, and q= tags.  Now why not just say that in the first  
> place?

This was described in the suggested text and in the review.  With an  
assurance that all non-compatible changes must cause Version to  
change, then what needs to be exchanged to prevent spoofing would be  
just the next acceptable version.  It seemed safer to assume this may  
not occur in every case, and to ensure non-compatible extensions that  
might be declared via the a= and q= parameters rather than properly  
reflected by the version value.

> in this issue, and a frankly much more elegant approach was  
> proposed. Why is this issue alive again?

This issue still needs review. This proposal offers a means to ensure  
a transition can occur while minimizing spoofing.  This could be  
changed to simply adding a new key tag that indicates the  
concurrently acceptable version.  This could be defined as a  
indication the signer considers such a signature using a key with  
this tag as deprecated.  You should notice that the base draft is  
using the term deprecated incorrectly.  There still needs to be a way  
to properly handle deprecated signatures without immediately  
declaring them obsolete as is the case in the current draft.

-Doug

---

From: Dave Crocker <[email-masked]>
Date: Thu, 22 Jun 2006 16:02:40 -0400

> resolved on the list?  

yes.

d/

-- 

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 22 Jun 2006 22:21:54 +0100

Douglas Otis wrote:
>> version; 

Eric's right there IMO.

 >> indication and protection against downgrade attacks).  As near as
 >> I can tell, the exact same issues that Doug is raising were discussed
 > This issue still needs review.

We have consensus that 1196 [1] is closed. One voice doesn't change
that.

Stephen.

[1] https://rt.psg.com/Ticket/Display.html?id=1196

---

From: Douglas Otis <[email-masked]>
Date: Thu, 22 Jun 2006 15:25:23 -0700

> [1] https://rt.psg.com/Ticket/Display.html?id=1196

There remains the issue describing a deprecated algorithm as being  
ignored, which is identical to treatments for obsolete algorithms  
(signature versions).  Perhaps there could be few minutes placed on  
the agenda to allow an attempt to explain why this could become a  
problem.  The solution could be as simple as defining an optional c=  
tag (concurrent requirement) in the key.

-Doug

---

From: Barry Leiba <[email-masked]>
Date: Sat, 24 Jun 2006 15:00:11 -0400

Douglas Otis said:
> (signature versions).  Perhaps there could be few minutes placed on the 
> agenda to allow an attempt to explain why this could become a problem.  
> The solution could be as simple as defining an optional c= tag 
> (concurrent requirement) in the key.

No, I'm not convinced we need to spend more time on it, I see no support 
for the idea that we should, and I see several people saying we shouldn't.

We decided a long time ago:
1. If a signer doesn't want to use an algorithm any more, it should 
simply not use it, and should cease publishing the keys that were used 
for it before.

2. If a verifier doesn't want to accept an algorithm any more, it should 
simply not accept it, and treat signatures with that algorithm as absent 
or invalid, depending upon how it chooses to interpret things.

3. We're left with the case where an algorithm is sufficiently 
compromised that an attacker can insert a valid signature with that 
algorithm, and yet the signer wants to keep publishing the public keys 
for a while because it's still within the reasonable verification time 
for some already-sent messages.  No one thinks this is a problem worth 
solving because the likelihood is low, the window is small, and the 
signer CAN resolve it by not publishing the key and letting the 
legitimate signatures that remain fail.

Unless there's more support for spending time on this again, it seems 
that Stephen and I agree that the issue is closed.

Barry

--
Barry Leiba, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave Crocker <[email-masked]>
Date: Sat, 24 Jun 2006 21:11:10 +0200

Barry Leiba wrote:
> Douglas Otis said:
>> There remains the issue...
> 

In fact, at this point, raising the issue further is somewhere between sour
grapes and a DOS attempt.

Either way, it needs to be filtered from the list.

d/
-- 

  Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Sun, 25 Jun 2006 05:46:30 -0700

> grapes and a DOS attempt.

This is not sour grapes, nor should the effort describing the concern
within an I-D be considered a type of DoS attack on the list.  The
intent was just the opposite. This next I-D offers a much simpler
solution from the prior suggestion.

http://www.sonic.net/~dougotis/id/draft-otis-dkim-security-concerns-01.html
http://www.sonic.net/~dougotis/id/draft-otis-dkim-security-concerns-01.txt

There does appear to be an important error that describes the handling
of a deprecated signature as that of an obsolete signature.  This makes
for a rather sharp and pronounced transition.  Full upgrade of SMTP will
require years.  How does this provision accommodate this possible need?

This is a security related work group.  A few messages that explain how
this is handled does not seem to be asking too much.  I agree the WG has
not recognized the need for this.  Because it was not done before with
S/MIME or OpenPGP does not seem to actually be offering a solution.  Am
I right about the possible problem ahead with a transition?

-Doug

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 25 Jun 2006 09:40:50 -0700

At 5:46 AM -0700 6/25/06, Douglas Otis wrote:
>This next I-D offers a much simpler

No, it doesn't; it is more complex.

>Full upgrade of SMTP will

Making absurd statements does not make the WG want to revisit the 
problem. There is no need to "upgrade SMTP" in the case of an 
algorithm transition for some DKIM implementations.

>This is a security related work group.

Exactly. In a security working group, there needs to be a consensus 
about the threat model for the use case of the protocol. This WG has 
agreed on the threat model, and has designed the protocol around that 
threat model. No analysis of the protocol has shown that the proposed 
protocol does not match the agreed-to threat model.

The fact that one person disagrees with the agreed-to threat model, 
and repeatedly tries to get people interested in his threat model, is 
bothersome but irrelevant.

It is also worth noting that this part of the threat model (algorithm 
transition) agreed to by this working group is the same as the threat 
model used in other IETF security protocols.

>Am

It is not a question of right or wrong; it is a question of perceived 
threats. Yours differs from the rest of the working group, and from 
those of the people who designed most (all?) other significant 
security protocols.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Mon, 26 Jun 2006 07:26:22 -0700

On Jun 25, 2006, at 9:40 AM, Paul Hoffman wrote:

>> This next I-D offers a much simpler solution from the prior  
>> suggestion.
>

Rather than marking the 'v=' revision or using the 'n=' parameter,  
this uses a 'c=' parameter to both mark the signature specifics as  
"deprecated" by the signing domain and to qualify the required  
concurrent non-deprecated signature specifics.  This approach  
counters objections of modifying existing parameters.  In that sense,  
this is simpler.

>> Full upgrade of SMTP will require years.  How does this provision  
>> accommodate this possible need?
>

Once DKIM becomes entrenched, it will take years before an "upgrade"  
of SMTP servers incorporating DKIM become fully incorporated, in  
response to an intermittent problem.  Until it becomes practical to  
obsolete a problematic signature, there does not appear be a means  
for preventing a "downgrade" attack.  The current draft ignores  
"deprecated" signatures which effectively treats these signatures as  
"obsolete."  With the current draft, there is no difference between  
"deprecated" and "obsolete".  Until obsoleted by the verifier,  
deprecated status is best established by the signer.  Implementing  
the present draft as written imposes an abrupt reduction of  
protection during what is likely a lengthy transitional phase.  When  
the problem is intermittent, this approach is detrimental from a  
security standpoint.

> about the threat model for the use case of the protocol. This WG  
> has agreed on the threat model, and has designed the protocol  
> around that threat model. No analysis of the protocol has shown  
> that the proposed protocol does not match the agreed-to threat model.

The threat is anything related to DKIM. The question is about the  
specifics of signaling the status of the signing domain to preclude  
the "downgrade" scenario.  Currently none exist.  Abrupt obsolescence  
of a commonly used DKIM signature is sure to cause havoc. Until then  
there is little available to curtail an intermittent problem.

> and repeatedly tries to get people interested in his threat model,  
> is bothersome but irrelevant.

This is not about a specific threat, but a general one.  The current  
draft deals with change in an abrupt, disruptive, and ultimately  
dangerous fashion.  Deprecated is not the same as obsolete except as  
defined in the current base draft.

> It is also worth noting that this part of the threat model  
> (algorithm transition) agreed to by this working group is the same  
> as the threat model used in other IETF security protocols.
>>
>> Am I right about the possible problem ahead with a transition?
>
> It is not a question of right or wrong; it is a question of  
> perceived threats. Yours differs from the rest of the working  
> group, and from those of the people who designed most (all?) other  
> significant security protocols.

This does not speak to the specifics, and there is no desire to  
include past efforts and attempts to decide what is relevant.  Are  
you suggesting that it is okay that there is no signaling as a means  
to prevent a downgrade attack?

-Doug