[Cfrg] MAY use specified curves

[Dan Brown <[e-mail]>]

Dear CFRG,

 

In addition to CFRG responding to the TLS request for recommending one or
two curves per security level, possibly as mandatory-to-implement, I think
CFRG should make a further recommendation to permit a MAY for IETF
implementations to specify elliptic curves.  

 

My understanding is that many IETF WGs have applied a MUST NOT to the
ANSI/SECG mechanisms of specifying an elliptic curve.  I do not know recall
the rationale for this MUST NOT, but I presume it was to improve
interoperability.   But this seems to _force_ users of the protocols to use
certain curves.  By contrast, ANSI and SECG recommended certain curves, but
they did not require them.

 

The main justification for allowing specified curves is that all _known_
attacks on the ECDLP and ECDHP are fairly easy to avoid, either by users
checking the parameters, or trusting them via some authentication channel,
e.g. in a certificate.  So, there's no fundamental security concerns with
specified curves.  Side channels must be listed as an important security
consideration for implementation of specified curves.

 

Allowing users to specify their own curves, instead of forcing particular
curves upon them, appears to have the following minor security benefits:

+1) resistance certain types of _suspected_ attacks, e.g. maliciously
generated curves, since users can select their own curves, or their friend's
curves.

+2) algorithm agility: in the unlikely event that the named curves are
discovered to be compromised (some breakthrough attack on the named curves),
then users can switch over to a specified curve quite quickly if using
implementations that support specified curves.  

+3) the effort spent to solve one ECDLP can be re-used to solve another the
ECDLP on the _same_ curve, whereas, for a different curve, almost all of any
previous effort is not useful.

 

Specified curves add the costs:

-1) decreased interoperability and efficiency: 

-2) complicated negotiation: extra bandwidth to convey the curves details,
and extra effort (for implementations or CAs) to verify the curve
parameters.

-3) difficulty to achieve side channel resistance, etc.

This cost appears to be the inherent price for the whatever security benefit
of specified curves.  Whether or not is an acceptable cost should perhaps be
left to the implementer, except perhaps the side channel resistance problem.

 

Securing the ensuing negotiation of the specified curves might be done with
the MTI curves, again expensive but not abnormal.  For example, a relying
party has to trust the CA's choice of algorithm used in the root
certificates, say ECDSA with a named curve, but then builds on this trust
(of the CA and of the named curve) to accept the algorithm indicated in the
issued certificate, say some specified curve.   I think that that this would
be an instance of the principle that authentication requires only short term
security, making the named curve adequate, while confidentiality requires
long-term security, and thus much greater caution, perhaps warranting a
specified curve.

 

Regarding the risk that specified curves can be misinterpreted as something
else, e.g. some weak non-EC DH or some weak RSA key, that should be
correctible by unambiguous formatting (in conjunction with secured
negotiation).

 

To make this proposal more specific to TLS without client authentication, if
a client specifies a curve, the server must validate the curve, which
especially includes checking that it is not vulnerable to Pohlig-Hellman, by
doing a primality check on the large subgroup order.  This could be costly
for the server.  The TLS protocol itself must ensure that such a client will
not allow client curve proposals to be substituted: but this is an issue
with the named curves, not just specified curves.  On the other hand, if the
server specifies the curve, the server's authentication can be added onto
the specified curve.  If the specified curve itself is used for the
authentication, e.g. for the server signatures, then it will be the CA's
signature from which the client derives trust of the specified curve.  In
addition, the client could validate the specified curve.

 

ANSI and SECG already provide mechanisms to specify curves, but perhaps
these could be updated for other types of curves.

 

Best regards,

 


Daniel Brown


Research In Motion Limited