Re: [Cfrg] ECC reboot

[Watson Ladd <[e-mail]>]

On Thu, Oct 23, 2014 at 3:43 AM, Rob Stradling <[e-mail]> wrote:
> On 20/10/14 14:05, Alyssa Rowan wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA512
>>
>> On 20 October 2014 10:40:47 BST, Rob Stradling <[e-mail]>
>> wrote:
>>
>>> When we generated our ECC root CA keys in 2008, secp384r1 seemed like the
>>> best choice.  secp521r1 wasn't in Suite B, and it seemed likely that Suite B
>>> compliance would be a requirement for some of our customers.
>>
>>
>> Why not secp256r1? (I'm guessing the big reason was because the TS profile
>> required ≈WF192 and you wanted one root to be suitable for both profiles if
>> you could?)
>
>
> That was certainly part of the reason.  The other part was that a competitor
> had already chosen secp384r1, so it seemed safest to follow suit.  :-)
>
>> It's a bit early to say, but (open question to all) if we picked one curve
>> at ≈WF128, would you in principle be comfortable with having roots of that
>> strength?
>
>
> In principle, yes, but...
>
>> What about if we picked two: one fast secure curve at 128 and one at some
>> higher "paranoid" grade (be it 384, 448, 480, 512, 521, 607...)? Which would
>> you perhaps consider using when? Would you have one root at each level, or a
>> shared root at the paranoid level?
>
>
> I'm inclined to agree with my colleague PHB, who wrote recently:
> "The Web PKI will almost certainly be based exclusively on the ~512
> level curve. The roots certainly will."

Previously, when given a choice of curves, the one with size 384 or
thereabouts was picked. Now you are saying you want the biggest
possible curve, regardless of the performance impact. I've heard
complaints that P384 is already painfully slow to verify on mobile.
It's a lot more sensible to pick Goldilocks: just as fast as what you
have now, but a few hundred bits bigger.

If you really needed 512, you would have already done it. So the fact
that you haven't tells me that you don't actually need a 512 or 521
length root key and are perfectly fine with anything above 384 in
length. The performance of verification is an issue for some clients
already: we don't need to make it worse.

>
> The various browser root programs place limits on the total number of roots
> per CA.  So whilst a ≈WF128 root could be useful, I think there's a very
> good chance that we won't have the option to embed both ≈WF128 and
> ≈WF<paranoid> roots.
>
>> What kinds of things would you need to be able to have such a root? I'm
>> guessing, bringing it back home to the weekly topic, that 'high-assurance'
>> crypto hardware of some form would be highly desirable for that. But what
>> does that mean to *you*?
>
>
> Yes, we would need at least one HSM that can generate keys and signatures on
> the new curves.  The speed of the implementation won't matter much.  If the
> new curves are to be used with ECDSA (unlikely?) then I think it might even
> be possible to persuade existing HSMs to do the job.  PKCS#11 supports ANSI
> x9.62 "EC domain parameters" as well as named curves, for example.

There is a technical issue here. While you could express the curve in
Weierstrass form for signatures, that won't give the same results as
using Edwards form. So if you wanted to reuse HSMs, that means that we
would need to have Weierstrass form keys for signing, and would need
to continue the use of a signature algorithm that isn't batchable and
is painful because it requires arithmetic modulo the group order.

How long do you think it would take to make an HSM that supports our
choice? Is this a matter of grab an ARM chip, add some custom
firmware, bypass caps, and epoxy (say ~ 6 months), or is it a more
involved process?

(I'm also unsure of how ECDSA handles cofactors. Will check this)
>
>> I say this because I don't think the initial target market for these new
>> curves necessarily includes those mandated to use Suite B (although never
>> say never!), I don't think government approval will drive adoption this
>> time, and also the assurances people ask of Web PKI CAs in particular seem
>> to be strengthening considerably relative to where they were (cf:
>> Certificate Transparency, et al).
>
>
> Agreed.
>
>>> TLS clients commonly don't specify RSA/SHA-512 and ECDSA/SHA-512  in the
>>> TLS signature_algorithms extension.  Some servers respond by refusing to
>>> serve certs with SHA-512 signatures.
>>
>>
>> Thanks for that note. The TLS WG and user-agent participants should
>> probably bear this in mind, down the line, if whatever we come up with is to
>> be accepted and used.
>>
>> - --
>> /akr
>> -----BEGIN PGP SIGNATURE-----
>> Version: APG v1.1.1
>>
>> iQI3BAEBCgAhBQJURQiIGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE
>> jtkWi2t6lFAP/04NXnjKWHI34cZ2OYIs+qCP4q35hKFvbtAX+7MECPmlF+4lrpbS
>> /Hzu8bjjsLVphsTWbXo8bW7sXCLWzHGkcL4QuvZM56ArngvP17EK3tZIgkFiOjKY
>> D+hlGskjcAgXDhRvyaEvimuUHQ9BVWmGft0XPnMSucBckq634Bbw3VSdzhq+0yAV
>> 5awXzKeTkrI9sYrwSXZ/P9TN/ejVjfI0t3KU+RxdMPWTY8psbmXsuaMT8ny4EkOi
>> PhskwFNb5rndfRBEq/rnenhXAgTnUJVf51vBhU8YOKZLy2NojcZ2Wjy5YOQuDepQ
>> GE3phWRqxCA4hnhbnNHcguxnlh5B6y5OzEYd/9/Iaia/brj7H3eYvc84RnG1H9Fl
>> VTkBrAZUUmtcmdnTlNnEBQQ/pmSlGWZsIhLYPueXD43yAggMvP8YffURKADFfm6J
>> Om5BmI2JVWjFpDjQA7e9NKL6niTJUccqUkHNjm54wEwIuh0zcKJCBzZ4P4cUU+vk
>> T5BDy3AoVLFT9uVOXV/vXkTA3xcOtlLaUgnTa3CzRR9IuoIewPncK1MurP6I37jA
>> XzcupAFmTgiDcITjKAm2xzaVzJwWByBbtuvaMBKRFbA1UK++y9/YWnhalwsEmNYf
>> lo5LnvTuJa/SvmPcpLHqtqeTIIV3rWVdn5GVbZOx5jxao5KK19b/7kMF
>> =tB0e
>> -----END PGP SIGNATURE-----
>>
>> _______________________________________________
>> Cfrg mailing list
>> [e-mail]
>> http://www.irtf.org/mailman/listinfo/cfrg
>>
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
> Office Tel: [phone]
> Office Fax: [phone]
> www.comodo.com
>
> COMODO CA Limited, Registered in England No. 04058690
> Registered Office:
>   3rd Floor, 26 Office Village, Exchange Quay,
>   Trafford Road, Salford, Manchester M5 3EQ
>
> This e-mail and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the sender by
> replying to the e-mail containing this attachment. Replies to this email may
> be monitored by COMODO for operational or business reasons. Whilst every
> endeavour is taken to ensure that e-mails are free from viruses, no
> liability can be accepted and the recipient is requested to use their own
> virus checking software.
>
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin