Re: [Cfrg] big-endian short-Weierstrass please

[Phillip Hallam-Baker <[e-mail]>]

On Wed, Jan 28, 2015 at 5:30 PM, Daniel Kahn Gillmor <[e-mail]>
wrote:

> On Wed 2015-01-28 16:23:27 -0500, Dan Brown wrote:
> > For example, RFC 4492 allows curves to be specified in Weierstrass
> > form, not just as named form.  I don't know if any TLS implementations
> > support the specified curve option, but if they do, then it would be
> > nice if the new implementations could talk to them, using the new
> > curves.
>
> Over in the TLS WG, we're working on actively deprecating the custom
> curve selection mechanism and moving strictly toward pre-named curves
> (this is true for finite-field DH as well).  Custom curve and FFDHE
> group selection will be gone in TLS 1.3.
>

Right. The objective here is to dump all the existing code in the trash and
start again. Because we want the implementations to have constant time
implementations and to preclude the possibility of malicious point attacks
by choosing curves that allow us to easily compute y from an x, and only
sending the x.

What we want to avoid at all costs is patent encumbrances. Dumping
Weierstrass is a pretty good start because that was the favorite curve of
the folk who applied for most of the patents.


The only area where I did have concerns is that to be able to deploy crypto
on these platforms I have to be able to buy FIPS certified hardware or
equivalent. But I think we can probably put pressure on our vendors to
deliver in time. Before the new curves can be used in browsers for certs,
the browser providers are going to have to be satisfied.

In the near term, the application for this will be to make the use of an
ECDH ephemeral essentially cost free and the certified hardware issue is
not a show stopper. But I don't want to do that in a way that makes it
difficult to move to EC certificates in the future.

I don't accept that big endian is more error prone. The existing code for
X.509v3 crypto is all big endian. Changing that will introduce a new code
path and opportunity for error.





> oThe over-flexibility in EC group selection isn't widely used, and when
> it is used, there is no clear way for a receiving implementation to have
> confidence in the structure of the arbitrary curves provided (even
> simple primality-testing is probably too expensive for most to do at
> runtime), or to have a reasonable (efficient, constant-time)
> implementation.
>
> I don't think this is a particularly useful half-measure.  I'd rather
> see implementations pick up new, reasonably-vetted curves than try to
> muddle through supporting arbitrary curves provided by the peer.
>

I don't see how we can reasonably use custom groups in IETF protocols
because both sides have to agree to use the same group. And when one side
can propose the use of a malicious curve, the opportunity for perfidy is
created.


The Web PKI has never permitted the use of arbitrary curves in certs:

[https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf]

CAs SHALL confirm that the RSA Public Key is at least 2048 bits or that one
of the following ECC curves is used: P-256, P-384, or P-521.


Now it should be quite easy to add the new curves to the list. I suspect
that unless the browser providers are feeling really generous, they will
expect us to end of life our existing ECC certs to get the new ones added.