Subject: Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

From: "Siegel, Ellen" <[email-masked]>
Date: Mon, 1 Jun 2009 11:41:23 -0400

> 
> >    TXT RR tags
> 
> >      k: Key type
> >
> > Much the same as h=, with the added issue that there's only one
> > possible key type right now, and if there were a need for k= in the
> > future it could be added in the same RFC that adds support for
> > anything other than RSA.
> 
Dropping this to remove clutter seems like a reasonable idea, but it would be necessary to meet a couple of conditions to prevent breakage due to the number of existing records with this tag. 

	- implementations would have to ignore any tags they don't recognize (this should already be required, so should be no problem)

	- if this functionality is added back in later, it needs to be done in a way that breaks neither records with k tags nor records without a key type specifier (again, backwards compatibility requirements should make this obvious, but if enough time elapses it's possible people will forget about the existing k tags). 

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Steve Atkins <[email-masked]>
Date: Mon, 1 Jun 2009 09:38:30 -0700

On Jun 1, 2009, at 8:41 AM, Siegel, Ellen wrote:

> Dropping this to remove clutter seems like a reasonable idea, but it  
> would be necessary to meet a couple of conditions to prevent  
> breakage due to the number of existing records with this tag.
>
> 	- implementations would have to ignore any tags they don't  
> recognize (this should already be required, so should be no problem)
>
> 	- if this functionality is added back in later, it needs to be done  
> in a way that breaks neither records with k tags nor records without  
> a key type specifier (again, backwards compatibility requirements  
> should make this obvious, but if enough time elapses it's possible  
> people will forget about the existing k tags).

I would assume that if it were added back it would look exactly like it
does now, but with some additional options other than "rsa".

Adding k= back or extending it to support other options would
both require RFC level effort, so I'd expect anyone doing that
would do the research on the history (or, more likely, be on
this mailing list right now :) ).

Cheers,
   Steve

---

From: Michael Thomas <[email-masked]>
Date: Tue, 26 May 2009 03:52:11 -0700

> 	- if this functionality is added back in later, it needs to be done in a way that breaks neither records with k tags nor records without a key type specifier (again, backwards compatibility requir…

This argument is a great example of "people who ignore history are 
doomed to repeat it".

The reason that all of the k= h= etc exist was a carefully crafted 
compromise with the rest
of the security community and the IESG to deal with algorithm agility. 
If we strip it all
out, we're either dooming ourselves to having this argument again, or 
hoping that community
is asleep at the switch because they didn't know what they were talking 
about the first time
around.

       Mike

---

From: Eliot Lear <[email-masked]>
Date: Mon, 01 Jun 2009 20:47:13 +0200

> this mailing list right now :) ).

The problem is that it is almost a certainty that it won't be "if" but 
"when".  Why make work?  This goes to Russ' point about algorithm 
agility.  On the other hand, I agree that having options with only one 
value invites hardcoding and improper processing.  Perhaps Russ would 
like to comment further?

Eliot

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 01 Jun 2009 12:43:41 -0700

> value invites hardcoding and improper processing.  Perhaps Russ would 

Let's make sure everyone is in synch about what is being proposed:

      The suggestion is to drop a tag from the *DNS record*, /not/
      from the *DKIM-Signature* header field.

What is the benefit of having the DNS record list possible algorithms?

A protocol like this has specification language that says "everyone MUST support 
algorithm P and MAY support other algorithms.  When the data arrive, they 
contain an indication of what algorithm has been used for this data."

The "MUST" ensure basic interoperability.  The "MAY" permits extensibility, 
based on mutual agreement.  Requirements for supported algorithms can be 
extended by enhanced specifications "MUST support algorithms P, Q and R".

It does not really matter how many algorithms are referenced in the 
specification or how many might be in the future.  The list is in the 
specification.  And the arriving data declare which algorithm has been used this 
time.

But what utility is there in having a signer list in an external record the 
algorithms they might choose to use?  Absent this justification, there is not 
"when" for needing the feature.

As I recall, the argument in favor of this tag in the DNS was a security concern 
that a message might arrive with an "unauthorized" algorithm.  For myself, I was 
never quite clear what actual threat this represented, in terms of feasibility, 
likelihood or severity.

d/
-- 

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

---

From: [email-masked] (Wietse Venema)
Date: Mon, 1 Jun 2009 17:00:04 -0400 (EDT)

Dave CROCKER:
> A protocol like this has specification language that says "everyone
> MUST support algorithm P and MAY support other algorithms.  When
> the data arrive, they contain an indication of what algorithm has
> been used for this data."
> 
> The "MUST" ensure basic interoperability.  The "MAY" permits
> extensibility, based on mutual agreement.  Requirements for
> supported algorithms can be extended by enhanced specifications
> "MUST support algorithms P, Q and R".
> 
> It does not really matter how many algorithms are referenced in
> the specification or how many might be in the future.  The list
> is in the specification.  And the arriving data declare which
> algorithm has been used this time.
> 
> But what utility is there in having a signer list in an external
> record the algorithms they might choose to use?  Absent this
> justification, there is not "when" for needing the feature.
> 
> As I recall, the argument in favor of this tag in the DNS was a
> security concern that a message might arrive with an "unauthorized"
> algorithm.  For myself, I was never quite clear what actual threat
> this represented, in terms of feasibility, likelihood or severity.

Reasons to drop this feature from the DNS record:

1) It assumes that the domain owner is giving the private key to
"rogue" signers that are willing to use "unauthorized" algorithms.

2) It requests that receivers ignore signatures from "rogue" signers
when they use these "unauthorized" algorithms.

3) It won't stop "rogue" signers from sending mail that is signed
with an "unauthorized" algorithm anyway.

	Wietse

---

From: Jon Callas <[email-masked]>
Date: Mon, 1 Jun 2009 14:59:10 -0700

On May 30, 2009, at 10:15 AM, Dave CROCKER wrote:

> Please discuss arguments for and against dropping this.

The argument against dropping it is that we *will* have to put it back  
in, eventually to support ECDSA. RSA will eventually be phased out.  
There will also be a strong desire to put it back in before there is a  
need. Thus, why remove something that we know will be needed, even if  
it is not presently needed?

The argument in favor of dropping it is that if we do everything, then  
our grandchildren will be fat and lazy. We need to bequeath them a  
reason for being. After they solve the world hunger, global warming,  
and world peace issues, it would be nice for them to do something easy.

	Jon

---

From: Eliot Lear <[email-masked]>
Date: Tue, 02 Jun 2009 09:54:17 +0200

> What is the benefit of having the DNS record list possible algorithms?

It's not a matter of possible algorithms, but which algorithm is to be 
used to interpret p=.  This having been said, I think your major point 
is that you do not see a benefit in stating the algorithm in the key 
record when it has already been stated in the header, that perhaps there 
is some nebulous potential downgrade attack.  Is that right?

Eliot

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 02 Jun 2009 04:17:42 -0700

Eliot Lear wrote:
>    ... you do not see a benefit in stating the algorithm in the key

Yes.

And it's not "the" algorithm in the DNS record; it's a list of possible 
algorithms.  The list does not help the receiver know which algorithm is used 
for a particular message.

d/
-- 

   Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Tue, 2 Jun 2009 10:00:43 -0700

On Jun 2, 2009, at 4:17 AM, Dave CROCKER wrote:
>> record when it has already been stated in the header, that perhaps  
>> there is some nebulous potential downgrade attack.  Is that right?
>
> Yes.
>
> And it's not "the" algorithm in the DNS record; it's a list of  
> possible algorithms.  The list does not help the receiver know which  
> algorithm is used for a particular message.

The list allows a recipient, during transitions to new algorithms, to  
recognize whether it might be used by the domain, even when a receiver  
has not yet implemented the algorithm.  This feature should limit the  
range of exploits that might otherwise prove successful during a  
transition in algorithms that may take long periods before full  
adoption.

-Doug

---

From: Murray Kucherawy <[email-masked]>
Date: Tue, 2 Jun 2009 10:41:06 -0700

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Dave CROCKER
> Sent: Tuesday, June 02, 2009 4:18 AM
> To: Eliot Lear
> Cc: Russ Housley; [email-masked]; DKIM WG
> Subject: Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type
> 
> Eliot Lear wrote:
> algorithms.  The list does not help the receiver know which algorithm
> is used for a particular message.

I'm neutral on dropping k= from key records, but I would also volunteer that "k=rsa" doesn't really tell me much when the published key is an RSA key.  It would be pretty amazing to me for some other key mechanism to come into common use which would actually work with RSA functions, so incompatibility will take care of this anyway.

So if a=rsa-sha256, then the key I get from issuing a query based on s= and d= will be an RSA key, or it will fail to verify.  What k= offers is somewhat redundant except for the fact that I can avoid the crypto overhead if I can detect early on that it won't work anyway.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 02 Jun 2009 11:32:01 -0700

> So if a=rsa-sha256, then the key I get from issuing a query based on s= and d= will be an RSA key, or it will fail to verify.  What k= offers is somewhat redundant except for the fact that I can av…

The main reason I can tell is that if you get k=megadeath, you'll not bother to
try to run the rsa verify on the message. If we drop k= and then latter add it back
in because rsa is botched, the verifier will then have to go through the motions
of doing the rsa verify (possibly exposing programming errors too) since it won't
know about the resurrected k= (or whatever it might be in the future).

Seems like a bad idea to me. It's not like k= is hurting anything.

	Mike

---

From: Eliot Lear <[email-masked]>
Date: Tue, 02 Jun 2009 19:59:30 +0200

> So if a=rsa-sha256, then the key I get from issuing a query based on s= and d= will be an RSA key, or it will fail to verify.  What k= offers is somewhat redundant except for the fact that I can av…

That's an important point, in the case of a DOS attack.  The next 
question is whether anybody implements it as such?

---

From: Jon Callas <[email-masked]>
Date: Tue, 2 Jun 2009 14:38:49 -0700

On Jun 2, 2009, at 4:17 AM, Dave CROCKER wrote:

>> there
> possible

Okay. I misunderstood. If it's a DNS-level list of all possible  
algorithms, it has very limited use, and can go.

The only use I can see of it is the case where you have many live  
messages out there, some of them with (e.g.) RSA and others with  
(e.g.) ECDSA and you want to make all RSA messages start failing now,  
and yet for some reason want to keep the RSA keys still in the DNS.

Pull it.

Incidentally, someone told me yesterday that the NIST schedule for  
deprecating RSA-2048 is 2017. While that is a bit early for  
cryptographic reasons, it's not horribly bad for the bureaucratic push  
toward EC. That means that my snotty remarks about grandchildren are  
inaccurate. We're going to be folding ECDSA into DKIM five years or  
less, so it might as well be now. We need to make sure that *that* is  
on the work list for -bis.

	Jon

---

From: Douglas Otis <[email-masked]>
Date: Tue, 2 Jun 2009 15:17:03 -0700

On Jun 2, 2009, at 2:38 PM, Jon Callas wrote:
> (e.g.) ECDSA and you want to make all RSA messages start failing  
> now, and yet for some reason want to keep the RSA keys still in the  
> DNS.

This does not represent the intended use the key's algorithm list.

While currently most receivers recognize rsa-sha256, they may not  
recognize ecdsa-md6. Removing indications of currently used algorithms  
by the key for a particular domain will allow bad actors to take  
advantage of a transition period.  Receiving MTAs may make exceptions  
for ADSP when ecdsa-md6 is recognized as a valid, albeit unsupported  
algorithm.  Rather than rejecting the message, it might be marked as  
having an unsupported signature algorithm.  By having the key indicate  
specifically which algorithms are in current use, then algorithm  
exceptions do not need to extend across all domains.  Just domains  
indicating the use of the newer algorithm should receive an exception  
indication.  Just as in the days of base64 encoded messages, a post- 
process can be used to confirm the validity of messages having a newer  
algorithm signature.  This post process check could even be offered as  
a web based service.

Without this feature, people may soon find their inbox flooded by  
bogus messages indicating the use of new algorithm, that could have  
been mitigated extensively by having the key feature.

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 2 Jun 2009 15:36:42 -0700

> been mitigated extensively by having the key feature.

As opposed to what?  What would you expect a verifier or assessor to do if the hash used to sign was not in the key's approved hash list?  Wouldn't it get delivered anyway, but perhaps with a slightly different annotation?

I don't see any value here other than disabling verification using a known-compromised hash algorithm.  But even that wouldn't inhibit delivery, only change annotation.

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 02 Jun 2009 16:16:27 -0600

> algorithms, it has very limited use, and can go.

+1

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jon Callas <[email-masked]>
Date: Tue, 2 Jun 2009 15:55:05 -0700

On Jun 2, 2009, at 3:17 PM, Douglas Otis wrote:

> recognize ecdsa-md6. Removing indications of currently used  
> algorithms by the key for a particular domain will allow bad actors  
> to take advantage of a transition period.  Receiving MTAs may make  
> exceptions for ADSP when ecdsa-md6 is recognized as a valid, albeit  
> unsupported algorithm.  Rather than rejecting the message, it might  
> be marked as having an unsupported signature algorithm.  By having  
> the key indicate specifically which algorithms are in current use,  
> then algorithm exceptions do not need to extend across all domains.   
> Just domains indicating the use of the newer algorithm should  
> receive an exception indication.  Just as in the days of base64  
> encoded messages, a post-process can be used to confirm the validity  
> of messages having a newer algorithm signature.  This post process  
> check could even be offered as a web based service.
>

Help me understand. Describe the use case where someone will use it.

As a cryptographer, I do not understand how the sketch you give above  
can happen. If the cryptography works, I don't see how the situation  
you describe can occur at all.

Signatures are either valid or invalid. There are many ways it can be  
invalid and only a few it can be valid. By that I mean among other  
things that a signature might be syntactically valid but by policy  
invalid; e.g. in the case of SHA1 collisions.

If an MTA decides that an invalid signature is for some reason  
acceptable anyway -- well, that's daft, but it's *their* MTA. People  
have the right to be stupid.

I don't get it, Doug.

However -- I just wrote a note about the meta-issue. If you want to  
say that you think it should be there because you like it and that  
should be good enough, I'll support you. It's the burden of people to  
convince others why something should go, not why it should stay.

	Jon

---

From: Douglas Otis <[email-masked]>
Date: Tue, 2 Jun 2009 17:30:23 -0700

On Jun 2, 2009, at 3:36 PM, Murray S. Kucherawy wrote:

> As opposed to what?  What would you expect a verifier or assessor to  
> do if the hash used to sign was not in the key's approved hash list?

It would be reasonable to assume the lack of a matching algorithm  
within the key record would be a strong indication of a spoofed  
signature.  The duration before new algorithms are universally  
supported could be fairly long.

>  Wouldn't it get delivered anyway, but perhaps with a slightly  
> different annotation?

It would be preferred to have "Unsupported Signature Algorithm"  
reserved for domains that indicate they actually use the unsupported  
algorithm.  Without the key being able to make this indication, all  
such messages might then receive the same indication, or be rejected  
where the recipient could have taken steps that check the signature's  
validity independently from the non-updated MTA.

> I don't see any value here other than disabling verification using a  
> known-compromised hash algorithm.  But even that wouldn't inhibit  
> delivery, only change annotation.

Huh? This is not about known compromised hash algorithms.  This is  
about asserting the proper annotation for new algorithms not yet  
supported by the receiver.

When a message is received that has the signature:
   DKIM-Signature: v=1; a=ecdsa-md6;  d=example.com; s=sel; ...

Annotation A "Signature algorithm not supported by receiver" can be  
noted when the key record is:
  sel._domainkey.example.com. TXT "k=edcsa\;. h=md6\; ...

Annotation B "Signature algorithm not supported by either the sender  
or the receiver!" can be noted when the key record is:
  sel._domainkey.example.com. TXT "k=rsa\;. h=sha256\; ...

By being able communicate what a sender supports for a specific key  
limits the number of domains that might receive the Annotation A  
notation or some ambiguous signature failure indication.

When the message receives the annotation: "Signature algorithm not  
supported by either the sender or the receiver!" this should cause the  
message to be treated with prejudice where users will know that  
additional verification steps will prove futile.

Not having this feature will mean users are unable to differentiate  
between the Annotation A or Annotation B cases.  Being unable to  
communication this significant difference allows bad actors to benefit  
by the confusion thereby created.

Without this feature being in place, there will be a greater  
reluctance to upgrade DKIM algorithms due to the potential for  
confusion.

-Doug

---

From: hector <[email-masked]>
Date: Tue, 02 Jun 2009 23:18:14 -0400

I also expected to offer added value to our customers who are more 
exclusive in their communications.  A vendor when signing up a new user 
or customer,  if have a  DKIM mandate in their Vendor/User 
communications and may want to quickly verify what level of DKIM  
support the user's email domain has.   When DKIM is peppered with terms 
like security and "domain responsibility,"   sending out DKIM mail to a 
user base they know might fail puts the organization at risk. 

K= provides value for software vendors to offer advanced managed mail 
features to their DKIM  operators.

---
HLS

---

From: Eliot Lear <[email-masked]>
Date: Thu, 04 Jun 2009 07:53:24 +0200

>> algorithms, it has very limited use, and can go.

It's not a list.  Dave got it wrong.  Please look at RFC 4871:

    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 ASN.1 DER-encoded [ITU.X660.1997] RSAPublicKey
        [RFC3447] (see 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.)

        ABNF:

        key-k-tag        = %x76 [FWS] "=" [FWS] key-k-tag-type
        key-k-tag-type   = "rsa" / x-key-k-tag-type
        x-key-k-tag-type = hyphenated-word   ; for future extension

The basic question is simply this: is it sufficient to list the key 
algorithm in the header?  I don't see a plausible attack, so I'm okay 
with that.  But let's at least have the debate based on facts.

Eliot

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 03 Jun 2009 23:12:43 -0700

> It's not a list.  Dave got it wrong.  Please look at RFC 4871:

I did, indeed.

+1

> with that.  But let's at least have the debate based on facts.

yup.

d/
-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 4 Jun 2009 09:06:06 -0700

> Sent: Wednesday, June 03, 2009 11:13 PM
> To: [email-masked] >> DKIM IETF WG

+1

+1

---

From: "Siegel, Ellen" <[email-masked]>
Date: Thu, 4 Jun 2009 12:13:27 -0400

+1

Ellen

---

From: [email-masked] (Wietse Venema)
Date: Thu, 4 Jun 2009 13:35:26 -0400 (EDT)

> > > > with that.  But let's at least have the debate based on facts.

Enlightened by the facts,

+1

	Wietse

---

From: Jon Callas <[email-masked]>
Date: Thu, 4 Jun 2009 11:34:21 -0700

> with that.  But let's at least have the debate based on facts.

It is in fact sufficient to list the key algorithm in the header.

Let us suppose for the sake of argument that the DNS contained an  
undifferentiated bag of bits. There is no plausible attack against  
that. You can't lie to someone and get them to get a false positive.  
Or to phrase that another way, if you could do it, then there's a Best  
Paper award waiting for you at the next CRYPTO and you'll be  
catapulted into the limelight for your crypto-fu. It would likely also  
be a new fundamental result in core mathematics, as well.

	Jon

---

From: Douglas Otis <[email-masked]>
Date: Thu, 4 Jun 2009 14:18:30 -0700

On Jun 4, 2009, at 11:34 AM, Jon Callas wrote:
>> algorithm in the header?  I don't see a plausible attack, so I'm  
>> okay with that.  But let's at least have the debate based on facts.
>
> that. You can't lie to someone and get them to get a false  
> positive.  Or to phrase that another way, if you could do it, then  
> there's a Best Paper award waiting for you at the next CRYPTO and  
> you'll be catapulted into the limelight for your crypto-fu. It would  
> likely also be a new fundamental result in core mathematics, as well.

This non-issue overlooks the intended goal of the k= parameter within  
the key that is not being discussed.  When is it safe to decide  
algorithm agility is not improved by assertions that allow senders to  
explicitly indicate their supported the algorithm which may differ  
form an unverifiable DKIM signature?  Clearly, such messages should be  
outright rejected, whereas the alternative would require the recipient  
to wonder why the signature failed.

What problem might be created when this feature remains as currently  
defined?

Why are we going over this again?

-Doug

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 04 Jun 2009 15:24:56 -0600

> Enlightened by the facts,

+1 again, in case the facts overrode my previous.

---

From: Jon Callas <[email-masked]>
Date: Thu, 4 Jun 2009 15:46:46 -0700

On Jun 4, 2009, at 2:18 PM, Douglas Otis wrote:

>>> The basic question is simply this: is it sufficient to list the  
>>> key algorithm in the header?  I don't see a plausible attack, so  
>>> I'm okay with that.  But let's at least have the debate based on  
>>> facts.
>>
>> you'll be catapulted into the limelight for your crypto-fu. It  
>> would likely also be a new fundamental result in core mathematics,  
>> as well.
>
> This non-issue overlooks the intended goal of the k= parameter  
> within the key that is not being discussed.  When is it safe to  
> decide algorithm agility is not improved by assertions that allow  
> senders to explicitly indicate their supported the algorithm which  
> may differ form an unverifiable DKIM signature?  Clearly, such  
> messages should be outright rejected, whereas the alternative would  
> require the recipient to wonder why the signature failed.
>

Again, forgive me, Doug, but what is the issue that's not being  
discussed? I genuinely don't understand what you're trying to say.

I don't mean to put words in your mouth, but are you saying describing  
this use case:

* Sender puts a key K_1 into the DNS. K_1 is of algorithm A_1, but the  
DNS entry does not note this fact.

* Sender creates an email E_1 that is signed with K_1 and sends it to  
Receiver.

* Attacker creates a key K_2 that is of algorithm A_2.

* Attacker creates an email E_2 that is forged from sender, and signed  
with K_2, but refers to the DNS entry for K_1. Attacker sends this  
email to Receiver.

* Receiver verifies E_1 and accepts it as having a valid signature.  
This is normal, expected DKIM operation.

* Receiver verifies E_2 and accepts it has having a valid signature.  
This is erroneous behavior because it was verified with A_1 despite  
having been generated by A_2.

Is this the scenario you're describing as being undiscussed?

	Jon

---

From: Douglas Otis <[email-masked]>
Date: Thu, 4 Jun 2009 17:00:20 -0700

On Jun 4, 2009, at 3:46 PM, Jon Callas wrote:

>>> undifferentiated bag of bits. There is no plausible attack  
>>> against  that. You can't lie to someone and get them to get a  
>>> false positive.  Or to phrase that another way, if you could do  
>>> it, then there's a Best Paper award waiting for you at the next  
>>> CRYPTO and you'll be catapulted into the limelight for your crypto- 
>>> fu. It would likely also be a new fundamental result in core  
>>> mathematics, as well.
>>
>> What problem might be created when this feature remains as  
>> currently defined?
>>
> I don't mean to put words in your mouth, but are you saying  
> describing this use case:
>
> * Sender puts a key K_1 into the DNS. K_1 is of algorithm A_1, but  
> the DNS entry does not note this fact.
>
> * Sender creates an email E_1 that is signed with K_1 and sends it  
> to Receiver.
>

First assume there is a _real_ transition to different DKIM algorithms  
sporadically occurring.  Perhaps based upon being targeted by bot-net  
resources.

An attacker spoofs a K_2 signature referencing a sender's K_1 key.   
Due to the lack of key assertions, the reference creates an appearance  
that the signature might be "unverifiable" rather than "invalid" or  
"spoofed".

> * Attacker creates an email E_2 that is forged from sender, and  
> signed with K_2, but refers to the DNS entry for K_1. Attacker sends  
> this email to Receiver.

The attackers know recipients have found _some_ signatures are not  
supported by their provider.  Due to the lack of key assertions,  
attackers will not need to use untrusted key domains, or to only spoof  
the domains using new algorithms.

> This is normal, expected DKIM operation.

Recipients now see many spoofed unverifiable signatures, in which some  
are legitimate messages.  They may even be aware of the situation in  
the news.  Being able to confirm whether the purported signer employs  
a new algorithm would reduce the level of this type of spoofing, since  
it would work against only a few select domains, of which many  
recipients may not care about, or might know how to identify through  
some other means, such as selected pass-phrases.  One might also  
expect that transitioning legitimate signers could offer utilities to  
confirm their signature whenever a provider might not.

> having been generated by A_2.

Again, this issue is about algorithm agility.  A means to transition  
while avoiding confusion.  When a domain becomes targeted, it might  
become necessary to abandon widely adopted algorithms.

> Is this the scenario you're describing as being undiscussed?

No.

-Doug

---

From: Jon Callas <[email-masked]>
Date: Sun, 7 Jun 2009 01:58:36 -0700

On Jun 4, 2009, at 5:00 PM, Douglas Otis wrote:

>>
>
> First assume there is a _real_ transition to different DKIM  
> algorithms sporadically occurring.  Perhaps based upon being  
> targeted by bot-net resources.
>
> Due to the lack of key assertions, the reference creates an  
> appearance that the signature might be "unverifiable" rather than  
> "invalid" or "spoofed".

But signatures are a mathematical operation that ultimately come down  
to comparing two numbers to see if they are equal.

They're either equal (valid) or not equal (invalid). There isn't a  
third state.

Within the framework of DKIM, there are other ways you can get to an  
invalid signature. For example, if I pull K_1 from the DNS, the  
signature is invalid because the key is gone. If I pull a key, all the  
messages I signed go instantly (modulo TTL, etc.) invalid.

But the only way the condition you describe can happen is for there to  
be a failure of cryptography in ways that are nearly completely  
unimaginable.

I say that because first of all, keys are of different sizes. You  
aren't going to cross-sign an ECC key to an RSA key because the  
signature isn't going to be right even with basic things like its  
size. You'll never confuse a 256-bit EC signature with a 2048-bit RSA  
signature. And if you do, then the software is so broken that you  
might as well ask what we do here if someone writes a DKIM  
implementation that always verifies a signature, even if it's bad. In  
that case, the software has a very bad bug.

If you look at key type where K_1 and K_2 are the same type, you're  
effectively saying, let's assume that the public key cryptography is  
completely broken. (Or again, there's some massively stupid error in  
the software.)

While it is not outside the realm of possibility that some major form  
of cryptography will get a massive break to it, it is highly unlikely  
to be overnight. And no matter how it happened, there are bigger  
issues than DKIM. Sure, it's in trouble, but so is every SSL cert out  
there.

But that doesn't necessarily mean that the key type flag should go.  
There's a much better reason to keep it, which I'll describe here:

The flag is there are part of the rough consensus we got when we  
finished DKIM Base. Because it represents part of that rough  
consensus, the burden should be on the people who want to remove it as  
to why it should be removed, not on the people who want to keep it.  
There are several purposes the flag serves:

* It provides a consistency check on the keys and the signatures. It  
is easier for the software to determine that they've been cross- 
threaded if there's a tag, as well as for the administrators. If you  
see that a signature that should be working is actually referring to  
the DNS for a different type, it will save effort.

* The signature checking mechanism is going to have to error-check the  
key parameters anyway, so why not have an easy pre-flighting via the  
type check.

* If you consider the case of an attacker who is trying to exploit a  
bug in cross-threaded keys, this gives a way for the attempt to easily  
be thwarted as opposed to some checks buried deep in the cryptography.

* A lot of what we call trust is the users believing in the software.  
Despite the fact that it is indeed essentially impossible for there to  
be a cryptographic error, crypto is hard to understand. Look at how  
ill-understood the SHA1 issues are. This is an easy way to give  
explainable, understandable warm fuzzies to administrators everywhere,  
and as I said above, it even simplifies error-checking and makes it  
more reliable.

There, that's a much better set of reasons to keep it.

	Jon

>> signed with K_2, but refers to the DNS entry for K_1. Attacker  
>> sends this email to Receiver.
>
> attackers will not need to use untrusted key domains, or to only  
> spoof the domains using new algorithms.
>
> Recipients now see many spoofed unverifiable signatures, in which  
> some are legitimate messages.  They may even be aware of the  
> situation in the news.  Being able to confirm whether the purported  
> signer employs a new algorithm would reduce the level of this type  
> of spoofing, since it would work against only a few select domains,  
> of which many recipients may not care about, or might know how to  
> identify through some other means, such as selected pass-phrases.   
> One might also expect that transitioning legitimate signers could  
> offer utilities to confirm their signature whenever a provider might  
> not.
>
>> * Receiver verifies E_2 and accepts it has having a valid  
>> signature. This is erroneous behavior because it was verified with  
>> A_1 despite having been generated by A_2.
>

---

From: John Levine <[email-masked]>
Date: 7 Jun 2009 10:32:20 -0000

>and as I said above, it even simplifies error-checking and makes it  

Another way to look at it is that k= is useless, but it's not harmful,
so it'd be more productive to argue about the warts that are both
useless and harmful.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 07 Jun 2009 13:01:17 +0200

> so it'd be more productive to argue about the warts that are both

To be a bit pedantic:

While components of the specification that are openly acknowledged to be 
actively problematic obviously ought to take priority, it's not quite true to 
say that "useless" is not "harmful".

Every piece of a specification carries costs.  If a piece does not also carry 
benefits, then it is a net negative, and that's harmful.

Implementation and debugging are expensive and they are opportunities for bugs. 
  If these costs and risks are not balanced by any discernible (current) 
benefit, then the "harmless" piece adds to the risk of problems with the protocol.

d/
-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 8 Jun 2009 02:41:50 -0700

> so it'd be more productive to argue about the warts that are both

I don't know that it's completely useless, but I'll defer to Jon on this point:

Is the actual cost of parsing "k=rsa" from the key and "a=rsa-blah" from the signature substantially less than trying to feed a non-RSA-key blob into an RSA function only to have it error out?

If detecting that the key and the signature are incompatible before actually trying to use the crypto functions involved actually saves substantial compute cycles then I'd say it's not useless.  Otherwise I believe it's redundant and can be removed.

I thought for a while that this had the same purported attack vector as has been claimed for "h=", but now I'm convinced otherwise.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 9 Jun 2009 22:03:10 -0400

> Help me understand. Describe the use case where someone will use it.

Here's what I remember from the original discussion of h= and k= in
the key record.

First, part of the idea was to have them both there, to make things
parallel: "This key is used for this crypto suite."

Now, as I remember -- and it's been a long time, and I've killed many
brain cells since then -- at least one scenario we discussed was this:

1. Crypto suite X had been seriously cracked, such that an attacker
could, at least in some cases, create a valid suite-X signature on his
own.  Perhaps there was a badly broken hash algorithm, perhaps there
was a way to reverse-engineer it from a bunch of collected real
signatures, or whatever.

2. Signer A, knowing that, will never, ever sign with suite X, and
exclusively uses suite Y.  Smart signer.

3. Verifier B, however, continues to support suite X.  Maybe they're
not as smart, or maybe they just want to keep verifying the suite-X
signatures from less-smart signers.

4. An attacker fakes a suite-X signature from signer A, and sends it
to verifier B.

The argument I remember was that if signer A had a way to say "This
key is only used with suite Y," then verifier B would know that the
signature was bogus.  Lacking that statement, the signature will
verify and appear fine, even though it came from an attacker.

That could provide a transition period, until "all" verifiers had
stopped accepting suite-X sigs.

Does anyone else remember anything vaguely similar to what I've said?

(Note that I'm not arguing to keep h= and k=, here... I'm just trying
to recall the discussion that led to their inclusion in the first
place.)

Barry

---

From: hector <[email-masked]>
Date: Wed, 10 Jun 2009 14:08:21 -0400

Barry,

I don't recall the reason for them in the base spec, but as I recall 
there were exchanges to explore the compatibility idea via policy.  The 
I-D policy proposal (DSAP)l I wrote was based on  these discussions:

    http://tools.ietf.org/html/draft-santos-dkim-dsap-00#page-15

   The main purpose of the a= tag is to allow domain signers the design
   and implementation opportunity to determine the highest strength
   possible by a particular target verifier by looking the DSAP DNS
   record for the target recipient domain host.  If this query results
   with no a= tag information, the default should be rsa-sha1 is the
   highest strength possible.

   Essentially, this is a negotiation and backward compatibility
   concept.  It is quite possible earlier pre-standard DKIM
   implementations supporting only rsa-sha1 may still exist.  The domain
   DKIM message signer's desire is to achieve the highest protection
   possible.  Instead of signing mail with a particular algorithm and
   hoping for the best, the signer can predetermine what the receiving
   system can handle in terms of hashing strength.

and I believe Doug's own proposal also touched base with it.

But as I recall, the push back was that it was would another lookup 
which to me is a non-issue for domains who will be thinking  to maximize 
secure exchanges knowing 100% that any strength upgrade will put them  
into a compatibility problem.  So if they really wanted to see if an 
important target domain supported XYZ, they can  lookup it up.

==

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 10 Jun 2009 13:00:41 -0700

>Does anyone else remember anything vaguely similar to what I've said?

Yes.  That matches my recolloection.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 11 Jun 2009 02:18:39 -0700

> [...]

I'm neutral on either keeping or removing this one.  It seems to me an RSA key is invalid input to any other crypto mechanism, so those functions will do the validation implicitly.

Since "h=" doesn't have the same benefit, I'd rather keep it.

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 11 Jun 2009 11:21:39 +0200

> could, at least in some cases, create a valid suite-X signature on his

Is there any experiential basis to motivate our having to worry about this 
attack vector?  In other words, do we have good reason to believe that this 
threat vector is significant?

Is there a history of worrying about this attack vector, among other efforts to 
do standards work with similar technology?  In other words, are we the only ones 
worrying about it, or is this a common concern amongst experts?

Is the mechanism for "protecting" against this attack vector in DKIM anything 
like the mechanisms used in those other, similar technologies?  In other words, 
if other experts have worked on this, have they solved in a similar way?

If the above 3 questions do not have a clear "yes" answer, then we ought to 
treat DKIM's effort on this topic as highly suspect.

Anything other than 3 yes' means that we're attempted to solve a problem that 
other experts do not see as a problem, or that they have not tried to solve 
before or that they have solved in a different way.  In other words, to some 
potentially high degree, we are hanging out entirely on our own.

My own sense of security work by a crew of folk that have some security 
expertise, but is not dominated by it, is that it should aggressively avoid 
being creative...

d/
-- 

   Dave Crocker

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 11 Jun 2009 10:46:50 +0100

> threat vector is significant?

I think this one's a yes - given the developments with hash collisions
in the last few years. While DKIM signatures are much more ephemeral
than other kinds (e.g. signatures on certificates) I think we should
still be concerned about this. There's also a non-security reason here,
the NIST recommendations and hash competition (that various folks will
follow) do mean that we are very likely to want to migrate from
rsa-sha256 to rsa-sha3 (or maybe something ECC based) within the next
few years. So we should try to make that transition easy (or at
least not make it hard).

> worrying about it, or is this a common concern amongst experts?

Yes. TLS authenticates the ciphersuite negotiation via the final
handshake message. Less convincingly, there was a huge effort to
get negotiation right for GSSAPI with SPNEGO and S/MIME has
its capabilities stuff. Bidding down attacks are things that
folks do want to prevent or detect.

> if other experts have worked on this, have they solved in a similar way?

Sort-of. I think DKIM differs in this in that our default
key management is less secure, but were DNSSEC to happen, then I
think that inclusion of the k= & h= fields in key records wouldn't
be that conceptually different from how TLS handles ciphersuite
negotiation.

> treat DKIM's effort on this topic as highly suspect.

I don't think 4871 is highly-suspect in this (or actually any)
respect.

> expertise, but is not dominated by it, is that it should aggressively avoid 

Totally agree there.
S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 11 Jun 2009 11:08:43 +0100

> I'm neutral on either keeping or removing this one.  It seems to me an RSA key is invalid input to any other crypto mechanism, so those functions will do the validation implicitly.

While that is probably true, I'd note that the rsa p= value is
a fairly simple construct (ASN.1 sequence of two integers) and
other algorithms have similar structures (e.g. Dss public key
in RFC 3279 is one integer and DSS-parms is an ASN.1 sequence
of three integers) so I guess I'd be a little concerned that
someone might define another key type (e.g. some ECC variant)
that was also two integers, or that someone's decoding code
might be suspect (e.g. accepting a DSS public key as an
RSA modulus and defaulting the exponent to 65537 or
something).

The putative attack would be to sign with foo-sha256 where
foo is some algorithm that a verifier supports and such
that the foo key encoding could accept an rsa p= value as
input and such that that combination allows the attacker
to forge signatures.

That's fairly theoretical, but there'd be a bit
of work to go check that there is in fact no realistic
situation where such confusion could arise. So on the
whole, for me, keeping the k= just makes it easier
to get things right now and in future.

S. (As participant, of course)

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 11 Jun 2009 16:05:39 +0200

Stephen Farrell wrote:
> The putative attack would be to sign with foo-sha256 where foo is some
> algorithm that a verifier supports and such that the foo key encoding could
> accept an rsa p= value as input and such that that combination allows the
> attacker to forge signatures.
> 
> That's fairly theoretical, but there'd be a bit of work to go check that
> there is in fact no realistic situation where such confusion could arise. So
> on the whole, for me, keeping the k= just makes it easier to get things right
> now and in future.

If out-of-band algorithm/key-type registration like this is not a regular 
"protection" mechanism provided in existing, related crypto-based schemes:

      1) Why should it be only in DKIM?

      2) Won't it need expert vetting by the security community to validate that 
the threat is real and the protection is sufficient?

I have been repeatedly taught by the security community to be extremely cautious 
about casual assumptions of what will fix a theoretical exposure.  So, for 
example, there have been cases where encrypting twice using the same algorithm 
reduces protection rather than raising it.  That ain't intuitive.

Same concern here.

Having this information maintained in the DNS isn't free and isn't certain to be 
safe.

d/
-- 

   Dave Crocker

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 11 Jun 2009 17:16:47 +0100

Dave CROCKER wrote:
> If out-of-band algorithm/key-type registration like this is not a
> regular "protection" mechanism provided in existing, related
> crypto-based schemes:

I think it is common mechanism. Normally its in a certificate for
PKI based applications or as part of negotiation in e.g. TLS etc.
XMLDSIG also includes the same information in its data structures.

>      1) Why should it be only in DKIM?

So I don't think that this is the case.

> 
>      2) Won't it need expert vetting by the security community to
> validate that the threat is real and the protection is sufficient?

Well, 4871 got last called, secdir review etc so it got as much
security review as most things. I don't think this is the kind of
thing where we'd need to get cfrg input.

> I have been repeatedly taught by the security community to be extremely
> cautious about casual assumptions of what will fix a theoretical
> exposure.  So, for example, there have been cases where encrypting twice
> using the same algorithm reduces protection rather than raising it. 
> That ain't intuitive.
> 
> Same concern here.

Well I guess both concerns are theoretical really. Personally,
I think having these fields in the key record reduces the need
for security analysis which is a good enough reason for me.
Of course, others might disagree, but I've not heard any
security concern about including them.

> Having this information maintained in the DNS isn't free and isn't
> certain to be safe.

Fair enough. Though I don't understand the additional expense
of k= and h= in key records - I'd have thought it might even
help maintaining those records, but since I don't maintain any
DNS stuff I may be wrong.

I do agree that key records being unsigned in the DNS is a risk,
but its one we accepted at the start of the WG.

S.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 11 Jun 2009 13:54:24 -0700

On Jun 11, 2009, at 7:05 AM, Dave CROCKER wrote:
> regular "protection" mechanism provided in existing, related crypto- 
> based schemes:
>

DKIM offers a domain's credentials to messages experiencing massive  
spoofing.

For DKIM, senders and receivers can indicate which algorithms are  
supported via DNS records.  After all, DKIM headers can not be trusted  
until the signature is verified.  When verification is not possible  
due to an unsupported algorithm, this algorithm may be refuted by the  
signing domain using their DNS record.  The ability to refute an  
algorithm defends against the types of exploits that Stephen  
mentioned, AND against a massive confusion for the disposition of  
messages when recipients are unable to determine which domains adopted  
a new algorithm.

DKIM signature analysis offers three conclusions that are supported  
and in current use:

a) Refuted
b) Invalid
c) Valid

The refuted state improves algorithm agility in the face of the  
massive spoofing.

> validate that the threat is real and the protection is sufficient?

It seems that has happened two years ago.  The changes now being  
suggested remove some of the protections in current use.

> I have been repeatedly taught by the security community to be  
> extremely cautious about casual assumptions of what will fix a  
> theoretical exposure.  So, for example, there have been cases where  
> encrypting twice using the same algorithm reduces protection rather  
> than raising it.  That ain't intuitive.
>
> Same concern here.
>

Indeed, some recent extensions to email threaten DNS security.   
Information published by a domain via DNS is often less expensive than  
when using HTTP or SMTP due to extensive caching of DNS.  Regardless  
of cost, or email's impact on DNS security, email still relies heavily  
upon DNS whenever deciding which servers receive messages, and in the  
case of DKIM, how to verify a domain's possession of a private key.   
Even PKI management is likely to have relied upon DNS at some point.

-Doug