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