Original text:
The "extension_data" field of this extension SHALL contain a "NamedGroupList" value: <del> %%% Named Group Extension enum { // Elliptic Curve Groups.  sect163k1 (1), sect163r1 (2), sect163r2 (3), sect193r1 (4), sect193r2 (5), sect233k1 (6), sect233r1 (7), sect239k1 (8), sect283k1 (9), sect283r1 (10), sect409k1 (11), sect409r1 (12), sect571k1 (13), sect571r1 (14), secp160k1 (15), secp160r1 (16), secp160r2 (17), secp192k1 (18), secp192r1 (19), secp224k1 (20), secp224r1 (21), secp256k1 (22), secp256r1 (23), secp384r1 (24), secp521r1 (25), </del>  <del> Indicates support of the corresponding named curve The named curves defined here are those specified in SEC 2 [13].  Note that many of these curves are also recommended in ANSI X9.62 X962 and FIPS 186-2 DSS.  Values 0xFE00 through 0xFEFF are reserved for private use.  Values 0xFF01 and 0xFF02 were used in previous versions of TLS but MUST NOT be offered by TLS 1.3 implementations.  [[OPEN ISSUE: Triage curve list.]] </del>  Indicates support of the corresponding finite field group, defined <del> in </del>  Items in named_curve_list are ordered according to the client's preferences (favorite choice first). <del> As an example, a client that only supports secp192r1 (aka NIST P-192; value 19 = 0x0013) and secp224r1 (aka NIST P-224; value 21 = 0x0015) and prefers to use secp192r1 would include a TLS extension consisting </del>  of the following octets.  Note that the first two octets indicate the extension type (Supported Group Extension):

Reviewer comments:
Not sure if the deprecation cutoff will be at 224 bits (~112 bit security level) or 255 bits (~128 bit security level) yet, so I've just done the former for now. This drops the old curves under 224 bits, updates the extension example bytes, and deprecates MD5.
As noted on-list, SHA1 can't be as easily dealt with here, so that'll be a topic for a separate changeset.
Here's a PR for this: Question: Are we dropping all curves <224 bits or <255 bits? (was consensus ever called on this specific number?)
There was not a specific WG consensus call on this point. I hope we don't need one and that we should keep the curves in that are used and trim the ones that aren't.
Good. In that case, I'll slash everything other than secp256r1 (prime256v1 / NIST P-256), secp384r1 (NIST P-384), secp521r1 (NIST P-521), and sect571r1 (NIST B-571). (plus, of course, new CFRG curves yet to be added) PR updated. URL URL
Based on the fact that apparently precisely zero servers actually use SHA-224 for signatures, can we drop that too while we're at it? (not an exaggeration; the scan cited in the last comment shows none)
I would drop it. spt On Jun 17, 2015, at 20:09, Dave Garrett EMAIL wrote:
OK. PR updated.
NAME This can be closed now that PR has been merged.

Revised text:
The "extension_data" field of this extension SHALL contain a "NamedGroupList" value:  <ins> %%% Named Group Extension enum { // Elliptic Curve Groups. obsolete_RESERVED (1..13), sect571r1 (14), obsolete_RESERVED (15..22), secp256r1 (23), secp384r1 (24), secp521r1 (25), </ins>  <ins> Indicates support of the corresponding named curve.  Note that some curves are also recommended in ANSI X9.62 X962 and FIPS 186-2 DSS.  Values 0xFE00 through 0xFEFF are reserved for private use. </ins> Indicates support of the corresponding finite field group, defined  <ins> in I-D.ietf-tls-negotiated-ff-dhe.  Values 0x01FC through 0x01FF are reserved for private use. Values within "obsolete_RESERVED" ranges were used in previous versions of TLS and MUST NOT be offered or negotiated by TLS 1.3 implementations. </ins> Items in named_curve_list are ordered according to the client's preferences (favorite choice first).  <ins> As an example, a client that only supports secp256r1 (aka NIST P-256; value 23 = 0x0017) and secp384r1 (aka NIST P-384; value 24 = 0x0018) and prefers to use secp256r1 would include a TLS extension consisting </ins> of the following octets.  Note that the first two octets indicate the extension type (Supported Group Extension):