TLS 1.2 and TLS 1.3 need Curve25519 and Curve448 SSL certificates

Issuance Policy
1

EdDSA algorithms officially replaced DSA on February 3rd 2023:

Federal Register :: Announcing Issuance of Federal Information Processing Standard (FIPS) 186-5, Digital Signature Standard

EdDSA browser and certificate support is on hold from CA|B Forum inaction to do anything besides include EdDSA in S/MIME:

Baseline Requirements Documents (SSL/TLS Server Certificates) – CAB Forum

CAs and browsers worldwide may be out of compliance come FIPS 186-4 sunset on February 4th 2024 leaving the Internet unprepared without two of the five Elliptic Curve Groups critical to initial key exchange in TLS 1.3. Let alone replacement algorithms for all those lost in TLS 1.2. What happens if an RSA or ECDSA vulnerability is discovered?

All of the necessary RFCs and standard libraries implementing EdDSA have been provided for TLS 1.2 and TLS 1.3 to support Curve25519 and Curve448 SSL certificates (below are snippets from three interrelated RFCs all released in August 2018):

The Transport Layer Security (TLS) Protocol Version 1.3

4.2.7. Supported Groups

When sent by the client, the "supported_groups" extension indicates

the named groups which the client supports for key exchange, ordered

from most preferred to least preferred.

Note: In versions of TLS prior to TLS 1.3, this extension was named

"elliptic_curves" and only contained elliptic curve groups. See

[RFC8422] and [RFC7919].

Elliptic Curve Cryptography (ECC) Cipher Suites

for Transport Layer Security (TLS) Versions 1.2 and Earlier

5.3. Server Certificate

When this message is sent:

This message is sent in all non-anonymous, ECC-based key exchange

algorithms.

Meaning of this message:

This message is used to authentically convey the server's static

public key to the client. The following table shows the server

certificate type appropriate for each key exchange algorithm. ECC

public keys MUST be encoded in certificates as described in

Section 5.9.

NOTE: The server's Certificate message is capable of carrying a chain

of certificates. The restrictions mentioned in Table 2 apply only to

the server's certificate (first in the chain).

+-------------+-----------------------------------------------------+

| Algorithm | Server Certificate Type |

+-------------+-----------------------------------------------------+

| ECDHE_ECDSA | Certificate MUST contain an ECDSA- or EdDSA-capable |

| | public key. |

| ECDHE_RSA | Certificate MUST contain an RSA public key. |

+-------------+-----------------------------------------------------+

Table 2: Server Certificate Types

5.9. Elliptic Curve Certificates

X.509 certificates containing ECC public keys or signed using ECDSA

MUST comply with [RFC3279] or another RFC that replaces or extends

it. X.509 certificates containing ECC public keys or signed using

EdDSA MUST comply with [RFC8410]. Clients SHOULD use the elliptic

curve domain parameters recommended in ANSI X9.62, FIPS 186-4, and

SEC 2 [SECG-SEC2], or in [RFC8032].

Algorithm Identifiers for Ed25519, Ed448, X25519, and X448

for Use in the Internet X.509 Public Key Infrastructure

3. Curve25519 and Curve448 Algorithm Identifiers

Certificates conforming to [RFC5280] can convey a public key for any

public key algorithm. The certificate indicates the algorithm

through an algorithm identifier. An algorithm identifier consists of

an OID and optional parameters.

RFC Proposed Standard
August 2018
View errata Report errata

Updated by RFC 9295

Browsers aside, Internet infrastructure will have fully supported SSL based EdDSA for five years come September:

/docs/man1.1.1/man7/Ed25519.html (openssl.org)

In SSH, EdDSA will have been utilized for ten years come January:

Comparing SSH Keys - RSA, DSA, ECDSA, or EdDSA? (goteleport.com)

2

Related topic:

2 Likes
3

While this statement isn't wrong, I find it a bit misleading. The good old Digital Signature Algorithm over finite fields has long been known to be fairly weak and has been banned from root programs for years. CAB Baseline Requirements v1.7.1 (2020) and newer explicitly forbids DSA keys from usage in publicy trusted certificates. So a DSA removal shouldn't come as a surprise to anyone - I don't know of any even half-modern application that takes security seriously and uses DSA keys.

It's important to recall here that DSA != ECDSA. ECDSA is alive and well and to my knowledge, no deprecation is planned by any agency.

Now we're mixing things.

First of all, FIPS standards primarily apply to USA government agencies and contractors. The worldwide PKI community is much larger and isn't entirely reliant on FIPS. That said, I acknowledge that many PKI systems (including Let's Encrypt and many HSM hardware vendors) are based in the USA and very much care about FIPS. That's fine, though the DSA removal doesn't mean that they are out of compliance. The (upcoming) standard says to use either RSA, ECDSA, or EdDSA. The CAB uses two out of three - that's the status quo, as we're not currently using DSA either.

Next, since you mention key exchanges: Nothing prevents you from using x25519, x448, brainpoolXYZ or whatever in key exchanges today. In fact all major browsers already do x25519. What's currently prohibited is the usage of Ed25519 (and Ed448) in certificates. That's not directly related to key exchange, but authentication.

About the security vulnerabilities: Well, what are your assumptions here? That RSA and ECDSA are both broken at the same time, while EdDSA is just fine? That's highly unlikely.

If quantum computers ever get powerful enough, all current algorithms are lost. That includes RSA, ECDSA and EdDSA - neither of them is safe against them. So if that's our main concern, EdDSA won't help us. A major flaw in both RSA and ECDSA algorithm classes is very remote, because they've been studied for decades. Now suddenly breaking them both at once sounds more like a movie than real world. Also, it's not like the CAB couldn't react if that were to happen.

That said, I'm definetly not against allowing EdDSA in X.509. However, my reasoning is a bit different:

  • Ed25519 is faster than the comparable P-256 NIST ECDSA curve (source). The difference isn't gigantic, but on a small embedded system it can make all the difference
  • Both Ed25519 and Ed448 are very reasonably designed, with all parameters openly documented, unlike their NIST counterparts. This reduces the risk of backdoors.
  • Curve25519 is generally constant time by default (source). In many (common) implementations, no extra precautions are required to harden the base algorithm. This is unlike the NIST curves, where constant time requires some considerations. Constant time is required to prevent timing side channel attacks.
  • The curve has no edge cases or special precautions to be considered when choosing or calculating curve points.
  • Easy implementation with little room for errors.
  • Security level is roughly identical to P-256 for Curve25519 and more or less similar to P-512 for Curve448 (theoretical security level is a bit lower here).

To sum up, Ed25519 (and Ed448 in a similar way) is superior to the NIST curves in all ways. So my question would be: Why not use the superior algorithms?

13 Likes
4

Several root programs have stated they're not interested in expanding the supported algorithm set, so there's no path towards pushing this, and nothing Let's Encrypt can do.

Ed25519 does have one big disadvantage, which is that it's not a prime-order curve, so there's risks around low-order points. The NIST curves have good complete addition formulas now, and there's high quality implementations that exist. Thus there's not any significant advantage to switching curves, and compatibility problems would stay for many years.

The big interest for new algorithms is in post-quantum algorithms, which represents a significant new research and development area.

4 Likes
5

Puts on aluminium hat

Because they're payed by the NSA

Puts off aluminium hat :stuck_out_tongue:

I'm pretty sure the risk for low-order points can probably be mitigated?

Personally I'd very much like to use Ed25519. I'd also rather use Ed448-Goldilocks. But if EdDSA is going to get used in practice, I'm sure browsers will refuse to add Ed448-Goldilocks support as they decide for their users "it's unnecessary" et cetera.. :confused:

Also, Let's Encrypt is "bound" to the features offered by their HSMs, so I don't even know if LE could support EdDSA, even if they wanted to..

vvv I trust neither of those.

4 Likes
6

I trust the NSA much more than the FAANGs of the world.

1 Like
7

If they were to generate a full EdDSA hierarchy, yes. But just for signing EdDSA leaf certificates (with a different intermediate key type) the CA doesn't need HSM support.

I'm not aware of any subgroup attack that works against Ed25519. If I'm wrong, (anyone) please correct me here. The potential issue is that there may be undiscovered attacks. However, that applies to each and every algorithm, so I'm not seeing how Ed25519 is in danger here.

Another nice thing is that the author of Curve25519 is Daniel J. Bernstein who has zero relationship to big tech companies. Curve448's author is Mike Hamburg.

6 Likes
8

How do you mean, a HSM is not required for signing leaf certs? I believe that's exactly what the HSMs are being used for?

See Preparing to Issue 200 Million Certificates in 24 Hours - Let's Encrypt for more info.

Cool, I retract my previous statement: the Thales Luna HSMs already support Ed25519:

  • Asymmetric: RSA, DSA, Diffie-Hellman, Elliptic Curve Cryptography (ECDSA, ECDH, Ed25519, ECIES) with named, user-defined and Brainpool curves, KCDSA, and more

(source: Luna Network Hardware Security Modules (HSMs) | Thales)

5 Likes
9

Yep; and that is great! Business wants all your money, an governments want world domination and control.

2 Likes
10

The HSM performs signing using the intermediate's private key (and probably another [offline] HSM using the root's private key).

The intermediate and the leaf do not have to have the same key type. Let's assume an RSA intermediate and an Ed25519 leaf:

  • In such a case, the HSM gets fed a to-be-signed certificate. This is just a bunch of bytes, nothing more. This happens to include an Ed25519 key, but the HSM neither knows this, nor does it need to care - all it sees is a bunch of bytes it has to perform a signature on. This signature has to be done using the algorithm from the private key. In our case this was RSA, so the HSM performs a RSA signature using an RSA private key. At no point is Ed25519 involved, even though we've now signed a certificate using it!

That's because there is no relationship between the key in the leaf and the key of the signing certificate. However, the HSM doesn't need to understand the certificate it is signing: Otherwise it would have to understand all X.509 extensions as well. For the HSM, certificates are just strings of bytes it has to sign, nothing more.

9 Likes
11

Ah yes, I didn't grasp your post correctly, had a weekend shift and I'm pretty tired :stuck_out_tongue:

But in any case, there's no limitation to the HSMs it seems. Unless those HSMs provided by Thales to Let's Encrypt aren't the same Luna 7 HSMs as I linked above.

5 Likes
12

And an older topic here has some discussion about the Curves When choosing an elliptic-curve look for a safe curve

2 Likes
13

Like, they won't permit CAs to sign certificates referencing subject public keys other than RSA and NIST EC curves?

4 Likes
14

That’s what I hear. This is all second-hand.

6 Likes
15

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.