ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] ECC (was RE: DKIM using old RSA padding?)

2011-02-28 14:46:56
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Feb 28, 2011, at 9:48 AM, Murray S. Kucherawy wrote:

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?


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
-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.10.0 (Build 554)
Charset: us-ascii

wj8DBQFNbACHsTedWZOD3gYRAp9iAKDT8N+be7oICaMbRHloX/SRhiGv9QCgvJQ1
4EXrf6WGzGvPJLA3paWkr3Y=
=0diH
-----END PGP SIGNATURE-----

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