Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS) Version 1.3
draft-bruckert-brainpool-for-tls13-07

(Via drafts-eval@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-bruckert-brainpool-for-tls13-05. If any part of this review is inaccurate, please let us know.

We understand that when this document is sent to us for processing, we will need to update the descriptions and references associated with six existing registrations at https://www.iana.org/assignments/tls-parameters.

In the TLS Supported Groups registry, we'll make the following changes:

OLD:

31 brainpoolP256r1 Y N [draft-bruckert-brainpool-for-tls13]
32 brainpoolP384r1 Y N [draft-bruckert-brainpool-for-tls13]
33 brainpoolP512r1 Y N [draft-bruckert-brainpool-for-tls13]

NEW:

31 brainpoolP256r1tls13 Y N [draft-bruckert-brainpool-for-tls13]
32 brainpoolP384r1tls13 Y N [draft-bruckert-brainpool-for-tls13]
33 brainpoolP512r1tls13 Y N [draft-bruckert-brainpool-for-tls13]

In the TLS SignatureScheme registry, we'll make the following changes:

OLD:

0x081A ecdsa_brainpoolP256r1_sha256 N [draft-bruckert-brainpool-for-tls13]
0x081B ecdsa_brainpoolP384r1_sha384 N [draft-bruckert-brainpool-for-tls13]
0x081C ecdsa_brainpoolP512r1_sha512 N [draft-bruckert-brainpool-for-tls13]

NEW:

0x081A ecdsa_brainpoolP256r1tls13_sha256 N [draft-bruckert-brainpool-for-tls13]
0x081B ecdsa_brainpoolP384r1tls13_sha384 N [draft-bruckert-brainpool-for-tls13]
0x081C ecdsa_brainpoolP512r1tls13_sha512 N [draft-bruckert-brainpool-for-tls13]

These changes have been approved by the designated experts.

Thank you,

Amanda Baber
Lead IANA Services Specialist

draft-bruckert-brainpool-for-tls13 has been presented for publication as an Informational RFC on the Independent Stream.

ECC Brainpool curves were available for use in TLS 1.2, but were left out of the TLS 1.3 suite because of perceived lack of use and lack of interest. However, the authors of this document see some interest in using some of those curves in TLS 1.3. This document provides the necessary protocol mechanisms for using ECC Brainpool curves in TLS 1.3. 

The document is clear that this approach is not endorsed by the IETF.

The document makes requests for IANA action in section 5. It requests that six codepoints that have already been allocated and assigned to this draft (and are marked as not recommended) be updated to refer to the RFC when it is published. Note that the codepoints already exist for use of these curves with TLS 1.2, but because they were assigned by an IETF consensus document, it was considered better to use new code points for TLS 1.3.

Along the way, this document was reviewed by the Designated Experts from the registries. They (specifically Rich Salz) approved the allocations against the draft and also the publication as an RFC.

Dan Harkins did a review for me as shown below, and the ISE also did a review. The document was updated to address these points.

== Dan Harkins

There aren't any submerged rocks I can see. I know that the TLS WG
decided to deprecate these curves so there is consensus to not use these.
They are generated in a more verifiable manner than the NIST curves that
are recommended so there's that. Publication would not be bad for the IETF
or the Internet.

It would allow for people that want to use these (I believe it is mostly
the German government although I know some Wi-Fi Alliance protocol that
defines their use too) without hacking up TLS proprietorially so that
might even help the Internet.

After reading the draft I do have 2 comments. The first is that I'm glad
they are only asking for 3 curves to be defined (RFC 5639 defines 7 of
them in both random and twisted form for a total of 14 curves), and I'm
glad they chose the 256-bit, 384-bit, and 512-bit curves. Those can
generate keys suitable for modern cryptographic primitives. My second
comment concerns the last sentence of the 2nd paragraph of section 5:

  with the same bit length as the order of the group generated by
  the base point G and with approximately maximum entropy."

I think I understand what they're trying to say but I think it is poorly
worded.

An implementer may read that and exclude a private key whose random
generation ends up with enough leading zeros to lop off (a) whole byte(s)
from the resulting bignum (some crypto libraries will automatically reduce
the size of a bignum if it is preceded with enough zeros). Such a reading
would eliminate half the possible values and reduce the strength of the
resulting secret by half which is not the
right behavior. Also, it doesn't say anything about a random private key
whose value is the same bit length but has a value greater than the order.
I think they should say that the Diffie-Hellman private key should be
generated from a random keystream whose length is the length of the order
of the group and the value of the private key must be less than the order.
Or something like that.

Also they should reference RFC 5639 in that sentence because that's
where the order, q, is defined. Can you please check with them on that or
pass my comment on? If you prefer I can engage Leonie myself.

== ISE

My main concern with this document is that we should make clear that the
IETF decided to deprecate the use of these curves as they moved to TLS
1.3, and say why. We can then say that, nevertheless, some people want
to use them in TLS 1.3 and that, although this is not endorsed by the
IETF, this document enables them. People should, obviously, be
cogniscent of the strengths and weaknesses of all security measures that
they employ.

Soooo, here are two suggestions...

Abstract

OLD
  This document specifies the use of several ECC Brainpool curves for
  authentication and key exchange in the Transport Layer Security (TLS)
  protocol version 1.3.
NEW
  ECC Brainpool curves were an option for authentication and key
  exchange in the Transport Layer Security (TLS) protocol version 1.2,
  but were deprecated by the IETF for use with TLS version 1.3 because
  of concerns about the robustness of the key generation. Nevertheless,
  there is some interest in using several of these curves in TLS 1.3.

  This document provides the necessary protocol mechanisms for using
  ECC Brainpool curves in TLS 1.3. This approach is not endorsed by the
  IETF. Implementers and deployers need to be aware of the strengths
  and weaknesses of all security mechanisms that they use.
END

Introduction

OLD
  In [RFC5639], a new set of elliptic curve groups over finite prime
  fields for use in cryptographic applications was specified.  These
  groups, denoted as ECC Brainpool curves, were generated in a
  verifiably pseudo-random way and comply with the security
  requirements of relevant standards from ISO [ISO1] [ISO2], ANSI
  [ANSI1], NIST [FIPS], and SecG [SEC2].

  [RFC8422] defines the usage of elliptic curves for authentication and
  key agreement in TLS 1.2 and earlier versions, and [RFC7027] defines
  the usage of the ECC Brainpool curves for authentication and key
  exchange in TLS.  The latter is applicable to TLS 1.2 and earlier
  versions, but not to TLS 1.3 that deprecates the ECC Brainpool Curve
  IDs registered for the use of ECC Brainpool Curves in earlier TLS
  versions.

  The negotiation of ECC Brainpool Curves for key exchange in TLS 1.3
  according to [RFC8446] requires the definition and assignment of
  additional NamedGroup IDs.  Analogously, the negotiation of ECC
  Brainpool Curves for authentication requires the definition and
  assignment of additional SignatureScheme IDs.  This document
  specifies such values for three curves from [RFC5639].
NEW
  In [RFC5639] specifies a set of elliptic curve groups over finite
  prime fields for use in cryptographic applications.  These groups,
  denoted as ECC Brainpool curves, were generated in a verifiably
  pseudo-random way and comply with the security requirements of
  relevant standards from ISO [ISO1] [ISO2], ANSI [ANSI1], NIST [FIPS],
  and SecG [SEC2].

  [RFC8422] defines the usage of elliptic curves for authentication and
  key agreement in TLS 1.2 and earlier versions of TLS, and [RFC7027]
  defines the usage of the ECC Brainpool curves for authentication and
  key exchange in TLS.  The latter is applicable to TLS 1.2 and earlier
  versions, but not to TLS 1.3 that deprecates the ECC Brainpool Curve
  IDs registered for the use of ECC Brainpool Curves in earlier TLS
  versions.

  The negotiation of ECC Brainpool Curves for key exchange in TLS 1.3
  according to [RFC8446] requires the definition and assignment of
  additional NamedGroup IDs.  This document provides the necessary
  definition and assignment of additional SignatureScheme IDs for using
  three ECC Brainpool curves from [RFC5639] in TLS 1.3 because there is
  some interest in using them for authentication.

  This approach is not endorsed by the IETF. Implementers and deployers
  need to be aware of the strengths and weaknesses of all security
  mechanisms that they use.
END

---

idnits says...

  == Unused Reference: 'RFC2119' is defined on line 208, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC3279' is defined on line 262, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC5480' is defined on line 267, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC6090' is defined on line 271, but no explicit
    reference was found in the text

---

In Appendix A, could you change

OLD
  This section provides some test vectors for example Diffie-Hellman
  key exchanges using each of the curves defined in Table 1 .  In all
  of the following sections the following notation is used:
NEW
  This non-normative Appendix provides some test vectors for example
  Diffie-Hellman key exchanges using each of the curves defined in
  Table 1.  In all of the following sections the following notation is
  used:
END