Shepherd writeup
rfc8734-07

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


Back