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