Subject: [TLS] Using ECC Brainpool curves with TLS

From: Johannes Merkle <[email-masked]>
Date: Fri, 06 Jul 2012 10:43:27 +0200

Hello all,

in RFC 5639, we have specified a new set of elliptic curve parameters for use in cryptographic applications. Meanwhile,
support for these ECC Brainpool Curves has been included in some crypto libraries as openssl (recently) and crypto++.
However, in order to use the Brainpool Curves with TSL (for authentication and/or key agreement), still some
specifications and IANA registry updates are needed. Therefore, an RFC specifying the usage of the ECC Brainpool Curves
with TLS has to be written.

In order to go forward with this, we would like to discuss some questions and potential issues. We would appreciate any
feedback on the following.

[Question 1] According to the update policy of the IANA registry EC Named Curve for TLS, such an RFC would have to be
shepherded by the TLS WG. Therefore, our first and most important question is: Is the WG willing to shepherd this RFC?

[Question 2] What category will be preferred for this RFC, Standards Track or Informational RFC?

[Question 3] Actually, we also plan to prepare analogous specifications for IKE, so an option may be to write a common
RFC for TLS and IKE analogously to RFC 5114. Would this be a good idea, in particular as this would imply shepherding by
two WGs, or would it be better to prepare separate RFCs for IKE and TLS?

[Question 4] In RFC 5639, for each of the bit lengths 160, 192, 224, 256, 320, 384, 512 two curves are defined, one
being the "quadratic twist" of the other having the same algebraic structure (and hence, security level), but one of
them allows particular efficient arithmetic. In order to leave the choice of the curve for a given bit length to the
implementation we propose to register IANA values (for EC Named Curve) for both curves for each bit length. Of course,
this doubles the number of number assignments. Does anyone consider this a problem?

[Question 5] No IANA registries are required for DTLS. However, authors have to specify whether new identifiers for TLS
are suitable for DTLS as well. This should be done for the ECC Brainpool curves. Any comments on this?

Johannes
--
Johannes Merkle
secunet Security Networks AG
[email-masked]
www.secunet.com

---

From: Douglas Stebila <[email-masked]>
Date: Fri, 6 Jul 2012 21:31:37 +1000

> this doubles the number of number assignments. Does anyone consider this a problem?

One alternative would be to use an extension, similar to the Supported Points Format Extension, to indicate whether to use the twisted form or the original form.  Or in fact define the twisted form as just another ECPointFormat.

But you could also ask the question: if the quadratic twist is more efficient, will anyone ever use the untwisted version?  If not, then perhaps you could just standardize the twisted version alone, reducing the number of combinations to be tested and supported.

Douglas

---

From: Johannes Merkle <[email-masked]>
Date: Mon, 09 Jul 2012 19:20:54 +0200

Douglas,

> One alternative would be to use an extension, similar to the Supported Points Format Extension, to indicate whether to use the twisted form or the original form.  Or in fact define the twisted form…
An extension would work, but although these curves are isomorphic (mathematically equivalent), there parameters and
arithmetic are different. So my feeling is that they should not be assigned to the same curve values.

A point format is even less suitable as this has nothing to do with EC point representation.

We have approx 65000 assignments left. So the question is if saving 7 numbers is worth defining extra syntax and
semantics. My personal opinion is that it is not.

> But you could also ask the question: if the quadratic twist is more efficient, will anyone ever use the untwisted version?  If not, then perhaps you could just standardize the twisted version alone…

The reason why some people might prefer the "normal" curves is that for these it is easier to avoid patents. This is
always a big issue with ECC. While the Brainpool curves avoid special primes to facilitate patent-free implementations,
we still wanted to leave the implementors a choice between "fast" and "slower but more patent-safe" by introducing the
quadratic twist.

Johannes

---

From: "Michael Staubermann" <[email-masked]>
Date: Thu, 26 Jul 2012 09:31:01 +0200

Hello,

i see the need for additional named ECC Curves like Brainpool Curves within
the next months. Therefore it makes sense have NamedCurves for ECC Curves
currently not present in RFC5639. 

What is unclear to me is, why the decision was taken to have an additional
NamedCurve IANA assigned Registry for TLS, while RFC5480 (2.1.1.1) and
RFC5753 (e.g. 3.1.1) already use namedCurves with ObjectIdentifiers. Was the
intention to select a "more secure" recommended subset or "only" to have a
compact representation for the identifiers (instead of ASN.1 BER Encoded
OIDs)?

>From RFC4492:

struct {
            ECCurveType    curve_type;
            select (curve_type) {
                case explicit_prime:
                    opaque      prime_p <1..2^8-1>;
                    ECCurve     curve;
                    ECPoint     base;
                    opaque      order <1..2^8-1>;
                    opaque      cofactor <1..2^8-1>;
                case explicit_char2:
                    uint16      m;
                    ECBasisType basis;
                    select (basis) {
                        case ec_trinomial:
                            opaque  k <1..2^8-1>;
                        case ec_pentanomial:
                            opaque  k1 <1..2^8-1>;
                            opaque  k2 <1..2^8-1>;
                            opaque  k3 <1..2^8-1>;
                    };
                    ECCurve     curve;
                    ECPoint     base;
                    opaque      order <1..2^8-1>;
                    opaque      cofactor <1..2^8-1>;
                case named_curve:
                    NamedCurve namedcurve;
            };
        } ECParameters;

namedcurve:   Specifies a recommended set of elliptic curve domain
      parameters.  All those values of NamedCurve are allowed that refer
      to a specific curve.  Values of NamedCurve that indicate support
      for a class of explicitly defined curves are not allowed here
      (they are only permissible in the ClientHello extension); this
      applies to arbitrary_explicit_prime_curves(0xFF01) and
      arbitrary_explicit_char2_curves(0xFF02).

>From RFC5480:
ECParameters ::= CHOICE {
       namedCurve         OBJECT IDENTIFIER
       -- implicitCurve   NULL
       -- specifiedCurve  SpecifiedECDomain
     }
       -- implicitCurve and specifiedCurve MUST NOT be used in PKIX.
       -- Details for SpecifiedECDomain can be found in [X9.62].
       -- Any future additions to this CHOICE should be coordinated
       -- with ANSI X9

>From RFC5753 3.1.1:
If the parameters are ECParameters, then they MUST be namedCurve.

Instead of duplicating the already existing NamedCurves of the OID-Tree used
in RFC5480 2.1.1.1 and RFC5753 (e.g. 3.1.1 Use of ECC Algorithms in CMS) i
propose to add a new ECCurveType to the RFC4492 enum ECCurveTypes:

enum { explicit_prime (1), explicit_char2 (2),
               named_curve (3), identified_curve (4), reserved(248..255) }
ECCurveType;

struct {
            ECCurveType    curve_type;
            select (curve_type) {
                case explicit_prime:
                    opaque      prime_p <1..2^8-1>;
                    ECCurve     curve;
                    ECPoint     base;
                    opaque      order <1..2^8-1>;
                    opaque      cofactor <1..2^8-1>;
                case explicit_char2:
                    uint16      m;
                    ECBasisType basis;
                    select (basis) {
                        case ec_trinomial:
                            opaque  k <1..2^8-1>;
                        case ec_pentanomial:
                            opaque  k1 <1..2^8-1>;
                            opaque  k2 <1..2^8-1>;
                            opaque  k3 <1..2^8-1>;
                    };
                    ECCurve     curve;
                    ECPoint     base;
                    opaque      order <1..2^8-1>;
                    opaque      cofactor <1..2^8-1>;
                case named_curve:
                    NamedCurve namedcurve;
                case identified_curve:
                    opaque CurveOID<3..15> ;
                        
            };
        } ECParameters;

Of course - for security reasons - there must be an exclusive-or for the
curve_type choice in the RFC to remove reduncancy, i.e. only NamedCurve or
identified_curve must be used.
 
To answer your questions:

Q1: Additionally to the above: Yes, we should have IANA Registry assigned
CurveIDs for Brainpool ECC
Q2: Currently RFC5639 is informational, it seems this we be sufficient.
Q4: From your latest post it think it is worth to have to have to different
IDs for the quadratic twisted and untwisted version (it would stretch the
semantics of the point format to much to put it there)
Q5: That surprises me a little bit. Shouldn't RFC 4492 be also used for
DTLS?

Best regards,
 Michael Staubermann

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Johannes Merkle
Sent: Friday, July 06, 2012 10:43 AM
To: [email-masked]
Subject: [TLS] Using ECC Brainpool curves with TLS

Hello all,

in RFC 5639, we have specified a new set of elliptic curve parameters for
use in cryptographic applications. Meanwhile, support for these ECC
Brainpool Curves has been included in some crypto libraries as openssl
(recently) and crypto++.
However, in order to use the Brainpool Curves with TSL (for authentication
and/or key agreement), still some specifications and IANA registry updates
are needed. Therefore, an RFC specifying the usage of the ECC Brainpool
Curves with TLS has to be written.

In order to go forward with this, we would like to discuss some questions
and potential issues. We would appreciate any feedback on the following.

[Question 1] According to the update policy of the IANA registry EC Named
Curve for TLS, such an RFC would have to be shepherded by the TLS WG.
Therefore, our first and most important question is: Is the WG willing to
shepherd this RFC?

[Question 2] What category will be preferred for this RFC, Standards Track
or Informational RFC?

[Question 3] Actually, we also plan to prepare analogous specifications for
IKE, so an option may be to write a common RFC for TLS and IKE analogously
to RFC 5114. Would this be a good idea, in particular as this would imply
shepherding by two WGs, or would it be better to prepare separate RFCs for
IKE and TLS?

[Question 4] In RFC 5639, for each of the bit lengths 160, 192, 224, 256,
320, 384, 512 two curves are defined, one being the "quadratic twist" of the
other having the same algebraic structure (and hence, security level), but
one of them allows particular efficient arithmetic. In order to leave the
choice of the curve for a given bit length to the implementation we propose
to register IANA values (for EC Named Curve) for both curves for each bit
length. Of course, this doubles the number of number assignments. Does
anyone consider this a problem?

[Question 5] No IANA registries are required for DTLS. However, authors have
to specify whether new identifiers for TLS are suitable for DTLS as well.
This should be done for the ECC Brainpool curves. Any comments on this?

Johannes
--
Johannes Merkle
secunet Security Networks AG
[email-masked]
www.secunet.com
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Johannes Merkle <[email-masked]>
Date: Tue, 31 Jul 2012 17:56:47 +0200

> currently not present in RFC5639. 

Do you mean that there are further curves that need to be used?

> propose to add a new ECCurveType to the RFC4492 enum ECCurveTypes:

Your idea would allow specifying in the Server KE message any curve by reference, which is much preferred over explicit
specification as explicitly specified parameters require validation to prevent certain attacks.

However, this would only solve part of the problem: In the client hello message, the client proposes the curves to be
used in the Supported Elliptic Curve Extension (RFC 4492). Due to the missing IANA assignments for the registry
namedCurve, a client can currently not propose the use of (one or several) Brainpool curves. He could use
arbitrary_explicit_prime_curves and hope that the server chooses a curve acceptable for him, but if the curve chosen by
the server does not meet its capabilities or policies, the client would have to end the handshake with an error alert.
This is not a nice way to negotiate the parameters, and since Supported Elliptic Curve Extension is the mechanism
intended for curve negotiation I would strongly advocate using this extension. This requires further assignments for
namedCurve.

I would very much welcome a mechanism that re-uses OIDs instead of defining (just another) identifier for each curve,
but I do not see how this can be incorporated in the Supported Elliptic Curve Extension.

> identified_curve must be used.

Agreed.

> CurveIDs for Brainpool ECC

For this, we need either a WG document or an AD-sponsored RFC. Given the lack of response to my posting I am not very
confident about getting the WG engaged in this.

> semantics of the point format to much to put it there)
I agree. Furthermore, the registry has 16 bits.

> Q5: That surprises me a little bit. Shouldn't RFC 4492 be also used for
RFC 6347 requires "When new identifiers are assigned for TLS, authors MUST specify whether they are suitable for DTLS."
My preference is to allow the Brainpool curves for DTLS as well.

-- 
Johannes