Subject: [ietf-dkim] DKIM using old RSA padding?

From: Hanno Böck <[email-masked]>
Date: Mon, 28 Feb 2011 10:53:49 +0100

Hi,

I'm currently researching about the usage of RSA-PSS, an improved
padding method for RSA signatures (specified in PKCS #1 2.1/RFC 3447).

I saw that domainkeys in RFC 4871 is hard-bound to the old PKCS #1 1.5
method. RFC 4871 was developed years after IETF approved PKCS #1 2.1 in
RFC 3447, so I wonder what was the reason for that decision?

Also, in the current draft of an RFC obsoleting 4871, still there is
only PKCS #1 1.5 padding allowed. Wouldn't it make sense to use that
update to provide a gradual transition?

Regards,
-- 
Hanno Böck		mail/jabber: [email-masked]
GPG: BBB51E42		http://www.hboeck.de/
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 28 Feb 2011 10:45:28 +0000

> update to provide a gradual transition?

That'd be a backwards-incompatible change so isn't really on the
table for this WG at this point.

AFAIK pkcs#1v1.5 signatures are still what's most easy to find
in terms of code support etc. and that was what drove us to choose
that for 4871.

In future, someone might want to define a DKIM sig alg that uses
PSS, but I've not heard that there's demand for that.

S.

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 28 Feb 2011 09:44:25 -0500

> PSS, but I've not heard that there's demand for that.

Just for archive completeness (and to comfort folks like me who lack crypto 
clue) could you offer a very brief summary of the difference between what DKIM 
currently uses and what is being suggested, especially in terms of how the newer 
one is better and why that might be important?

Thanks.

d/

-- 

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

---

From: Hanno Böck <[email-masked]>
Date: Mon, 28 Feb 2011 15:59:19 +0100

Am Mon, 28 Feb 2011 09:44:25 -0500
schrieb Dave CROCKER <[email-masked]>:

> Just for archive completeness (and to comfort folks like me who lack
> crypto clue) could you offer a very brief summary of the difference
> between what DKIM currently uses and what is being suggested,
> especially in terms of how the newer one is better and why that might
> be important?  

The difference is merely protection against hypothetical weaknesses in
the padding scheme. Old padding schemes have been made more or less in
a naive way (usually hash-then-sign), while PSS (specified in PKCS #1
2.1) provides provable security properties under certain model
asumptions.

There are no known flaws in the old padding scheme. But in theory,
there could be flaws which can be excluded by using PSS.

For details, the research papers this is based on can be found here:
http://www.cs.ucdavis.edu/~rogaway/papers/exact.html

So yes, this is nothing in any way urgent. Citing RFC 3447 / PKCS #1
2.1:
"RSASSA-PKCS1-v1_5 is included for compatibility with existing
applications, and while still appropriate for new applications, a
gradual transition to RSASSA-PSS is encouraged."

cu,

---

From: Michael Thomas <[email-masked]>
Date: Mon, 28 Feb 2011 07:09:48 -0800

> 2.1) provides provable security properties under certain model

Thanks for the explanation. I've always approached these kinds of problems
for dkim with a test like "if I could exploit a weakness at great expense,
would dkim signatures be on the short list?" The answer is invariably no.
It's similarly why the SHA1 brouhaha wasn't _that_ big a deal, IMO.

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 28 Feb 2011 09:48:22 -0800

But while we're on the topic...

Elliptic curve cryptography has been getting more and more attention lately.  Does anyone have a good feel for adoption rates?  Should we (or maybe another group, or an individual submission) look into registering a new signing algorithm and key storage specification for that technology?

-MSK

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 28 Feb 2011 18:34:38 +0000

> Elliptic curve cryptography has been getting more and more attention lately.  Does anyone have a good feel for adoption rates?  Should we (or maybe another group, or an individual submission) look…

I think that'd be a fine thing for someone to do. However, I
don't think its really useful until we need it, so one idea
might be to wait for sha-3 and then do a bunch of 'em at the
same time?

I think we will eventually want ECC instead of veeery loooong
RSA keys.

The time to switch for DKIM is likely to be when you no longer
want to sign with an RSA key that fits a DNS response nicely.
Not sure off the top of my head what exactly that would be in
terms of RSA modulus size.

But if there's demand now (e.g. for suite-B conformance or
something) maybe earlier than that would be better. I've not
heard that that's needed myself.

S.

PS: No hats on for this of course:-)

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 28 Feb 2011 10:52:34 -0800

> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Monday, February 28, 2011 10:35 AM
> To: Murray S. Kucherawy
> Cc: Michael Thomas; Hanno Böck; [email-masked]
> Subject: Re: [ietf-dkim] ECC (was RE: DKIM using old RSA padding?)
> 

Based on the work I did on resolver truncation handling, I believe that's 2048-bit RSA keys, but I don't recall exactly at the moment because it was a while ago.

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 28 Feb 2011 14:47:31 -0500

On 2/28/2011 1:34 PM, Stephen Farrell wrote:
> The time to switch for DKIM is likely to be when ...

Just to be entirely pedantic:

1. This topic is out of scope for the wg at this time.

2. There is no industry view that we need to stop using the current DKIM crypto 
algorithms anytime soon.  There's nothing wrong with adding to the repertoire of 
algorithms if someone is motivated, but there is no industry urgency.

Yes?

d/

-- 

   Dave Crocker

---

From: "Mark Delany" <[email-masked]>
Date: 28 Feb 2011 11:02:54 -0800

On 28Feb11, Murray S. Kucherawy allegedly wrote:
> > Cc: Michael Thomas; Hanno B?ck; [email-masked]

In theory EDNS0 will give us plenty of extra payload to play with.

Mark.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 28 Feb 2011 20:27:53 +0000

> 1. This topic is out of scope for the wg at this time.

Asking is fine IMO, but yes, we're not chartered for that as I said earlier. (Though admittedly not directly when responding to Murray.)

> 
> 2. There is no industry view that we need to stop using the current DKIM crypto algorithms anytime soon.  There's nothing wrong with adding to the repertoire of algorithms if someone is motivated, but there is no industry urgency.
> 
> Yes?

Absolutely. Later is plenty soon enough.

S

---

From: Jon Callas <[email-masked]>
Date: Mon, 28 Feb 2011 12:07:32 -0800

> Elliptic curve cryptography has been getting more and more attention lately.  Does anyone have a good feel for adoption rates?  Should we (or maybe another group, or an individual submission) look…

My opinions:

The obvious reasons for ECC is shorter keys, and secondarily faster algorithms. There are so many variables on speeds that it's a complex decision.

The obvious reason not to use ECC is intellectual property. There are a number of patents that surround ECC, but they're all around optimizations. The core mathematics itself is not patented. This is why part of why the speed issue is complex.

There are a number of ECC implementations that are believed to be IP-free, and the major patents start expiring this summer. Let me summarize by saying that each of the statements "Don't worry about it, the IP issue is a canard" and "Don't go anywhere near ECC for the next few years" have situations when they're the reasonable reaction to the IP issue.

For DKIM itself, it makes sense to define the parameters to do signing with ECDSA because you want to get ahead of the issue. Until the parameters are defined, no one's going to implement it. If it's not implemented widely, it's not going to be deployed. If verifiers are not implemented and deployed with ECC, there's not going to be widespread signing.

I believe that even if you're an IP paranoid who doesn't think ECC should be used before 2020+ for whatever reason, it's good to define things now so that when 2020 rolls around, people might go there. I suggest defining ECDSA with the P-256 and P-384 curves (which are Suite B curves), myself. You could even pick suites with SHA3 now, ahead of selection.

Protocol-wise, DKIM as a protocol has a number of features that make it agile. It's completely trivial to change keys in DNS, which means that it's easy to plan a DKIM deployment system that increases RSA key size over time. I believe it's completely reasonable to use 1024 bit RSA keys that are regularly rolled over monthly (yearly most likely too, but that's debatable, and I'm not interested in the debate). But if you don't like 1024, why not 1280, or 1536? Those are also fine for DKIM, and not much more costly than 1024. RSA will be a reasonable algorithm (up to ~4K keys) for the next half-century. Sometime after about a decade, the argument for why not ECC starts to go away. Small keys -- 1536 bits or smaller -- are completely reasonable until then and will be fast enough, especially with a reasonable rotation policy.

The bottom line of my opinion is that ECC isn't needed, but it's easy to add into a deployment strategy, and defining the parameters now so they can be used later is wise.

	Jon

---

From: Sean Turner <[email-masked]>
Date: Mon, 28 Feb 2011 19:53:19 -0500

On 2/28/11 3:27 PM, Stephen Farrell wrote:
>
>
> On 28 Feb 2011, at 19:47, Dave CROCKER<[email-masked]>  wrote:
>
>>
>>

There's also more to it than just the padding.  You'd need to convey the 
additional parameters needed to verify the signature.

spt