339393 - Five ANSI X9.62-1998 elliptic curves are disallowed in ANSI X9.62-2005.

Status: NEW

(NSS :: Libraries, defect, P3)

Description

[Wan-Teh Chang]

The following five elliptic curves in ANSI X9.62-1998
are disallowed, not "even under an exception for
backwards compatibility, in the 2005 edition of the
standard because they "do not meet the security requirements
of this Standard" (quoted from ANSI X9.62-2005 Annex F,
p. 72):

- c2pnb176w1, former J.4.2, example 1 (note that this
  curve is misnamed in NSS as c2pnb176v1),
- c2pnb208w1, former J.4.4, example 1,
- c2pnb272w1, former J.4.6, example 1,
- c2pnb304w1, former J.4.7, example 1, and
- c2pnb368w1, former J.4.9, example 1.

X9.62-2005 also says something about three other curves,
which is beyond my understanding of ECC:

  Certain other sets of elliptic curve domain parameters
  named in the 1998 edition of this Standard do not use
  the basis required in this edition of this Standard.
  Using the notation above, these curves are:
  - c2pnb163v1, former J.4.1, example 1
  - c2pnb163v2, former J.4.1, example 2, and
  - c2pnb163v3, former J.4.1, example 3.

Comment 1

[Douglas Stebila]

(In reply to comment #0)
> X9.62-2005 also says something about three other curves,
> which is beyond my understanding of ECC:
> 
>   Certain other sets of elliptic curve domain parameters
>   named in the 1998 edition of this Standard do not use
>   the basis required in this edition of this Standard.
>   Using the notation above, these curves are:
>   - c2pnb163v1, former J.4.1, example 1
>   - c2pnb163v2, former J.4.1, example 2, and
>   - c2pnb163v3, former J.4.1, example 3.

All binary fields on the same number of bits are isomorphic (i.e., there exists an invertible mapping between them).  So you could use any irreducible to represent the field.  However, the lower-level ECC standards (e.g., IEEE 1363) specify that you should always use the irreducible with the fewest number of terms, and then with the smallest terms.  For field sizes of interest, there is always either a trinomial ("tnb") or pentanomial ("pnb") irreducible.  For 2^163, the smallest pentanomial is x^163+x^7+x^6+x^3+1, I believe.  However, the irreducible for the curves listed above is different: x^163+x^64+x^2+x^1+1.  These don't use the proper irreducible, so they shouldn't be used in practice.

Comment 2

[Douglas Stebila]

Attachment: Remove curves listed in comment #1

Patch to remove the curves listed in comment #1.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 236014 [details] [diff] [review]
Remove curves listed in comment #1

Douglas, Thanks for the patch.   However ... 

NSS has a policy about backwards binary compatibility that doesn't allow 
us to change the numbers in "public" enumerations after they've appeared 
in an official NSS release.  That's the reason why we explicitly define 
the enumerated values with "= nnn" (a constant).  It's to ensure that 
the value doesn't accidentally change by the insertion or removal of a 
value from the enumeration.  

The enumeration in secoidt.h is one of those public enumerations.  
Many of the ECC symbols in that enumeration were added in NSS 3.9.0
Now, as we're developing NSS 3.11.3, it's way too late to remove them
or change them.  So, we have to leave them in secoidt.h, and leave
definitions for them in secoid.c.  We may wish to add comments to those
files, indicating that they've become disallowed, and are deimplemented.
We also have to save the corresponding table entries in secoid.c,
although we may wish to modify them slightly, e.g. by modifying the 
name strings to include "deprecated" or "disallowed" or "deimplemented".

We'll have to decide how to handle what happens when a program calls 
an NSS public API specifying one of those (if we have any such APIs).
We *may* have to return a success indicator, saying that we've done
whatever it asked us to do, even though we cannot (since it's no 
longer implemented).  This is often one of the most difficult parts 
of API binary compatibility to get right.  

I will continue to go through your patch, to try to figure out what 
we must keep and what we needn't keep.  I'm not certain at the moment
whether we can remove support for the curve names from the tables of 
recognized curve name strings in the commands.  

There's a certai sense in which we don't necessarily have to remove 
anything at all.  It may suffice to output warnings whenever a user
or administrator attempts to configure or use a deprecated curve name.

There will probably be some discussion in this bug about what we can 
keep and what we cannot. Once the dust has settled, we can determine 
how much of this patch we can use, and what else (if anything) needs 
to be done.  Your patch gives us a good check list with which to start.
The thanks for it is sincere.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

More thoughts on this subject.  

1. If the deprecated curves include any of the 25 curved named in RFC 4492, 
then there will be changes needed to libSSL in order to support the removal 
of those curves.  Recall then when a TLS client negotiates an ECC cipher 
suite and does NOT send a client hello extension declaring which curves it 
supports, the server may assume that that client supports any or ALL of the 
25 curves named in the RFC.  If a client does not support all 25 named 
curves, then it MUST send a supported curves hello extension, or else it 
must NOT attempt to negotiate any ECC cipher suites.  So, if our client 
code changes such that it can no longer support all 25 of the curves named 
in that RFC, then it must change its behavior with repsect to curve 
negotiation slightly. 

2. Some of the curves we support have been given multiple names, one by 
each of several standards bodies.  Presently some NSS commands accept ANY
of those different names for the supported curves.  This has created a 
misunderstand among users (and QA folks) concerning how many curves NSS
really supports.  To correct that misunderstanding, I believe we need to 
reduce the set of supported curve names to no more than 1 per supported 
curve.  The output of "help" or "usage" commands should not list any curve
by more than one name.  Choosing that one name may be painful.

3. NSS supports more curves than the 25 named in RFC 4492.  This creates a
situation wherein people create certs using curves that simply aren't 
supported with TLS (aren't in RFC 4492).  Our command line tools for 
creating certs and cert requests should warn users when they're about to 
request a cert with a curve that cannot be used for TLS.  

Personally, I'd vote for eliminating the non-TLS curves alltogether to 
reduce the support costs we will certainly bear over this issue (and have
already begun to bear).

4. Somehow, the huge table that matches supported curve names to SEC_OID
enumeration symbols has been duplicated, in its entirety, in THREE separate
NSS utility commands.  We really need to eliminate that duplication, by 
factoring that table out into a separate header file, where it can be 
maintained in a single file, not in three files.  

Since this patch touches on all these things, this would be a good time to
kill all these birds with a single stone.  

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

ecl-exp.h is a "exported" public header file, ergo the enum ECCurveName is 
a public enum and its values are subject to the binary compatibility rules.
I think.  Occasionally we convince ourselves that exported files aren't 
really public and their contents aren't really subject to binary compatiblity.
So, there may be some debate on this particular file.  However, if we do 
conclude that it is public, then we should fix the values for enum ECCurveName
with "= nnn" on every line, to clearly signify its immutability.

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

I'm soliciting advice on which name to keep and which names to discard, for 
the cases of curves with multiple names.  

Comment 7

[Robert Relyea]

> 2. Some of the curves we support have been given multiple names, one by 
> each of several standards bodies.  

The problem is these curves have multiple names in the wild. We do have a reduction 'point' for the curve names, which is the OID table. There is only one oid for each curve, even if more than one standard supports it.

If we only understand the one name from the programmer's or user's perspective, then we can still generate confusion. NIST curves, for instance, are not named explicitly in the OID table.

> 3. NSS supports more curves than the 25 named in RFC 4492. This creates a
> situation wherein people create certs using curves that simply aren't 
> supported with TLS (aren't in RFC 4492)

Agreed.