ECDSA Root and Intermediates

We could request a DST Root CA X3 cross-sign on ISRG Root X1, which would then pass on trust to the new ECDSA root. But details like these are a good reason to publish a draft before doing the ceremony. :slight_smile: I'm going to be focusing on SCT stuff today, but will circle back to this soonish.

2 Likes

Perfect!

I'm not sure it's technically/legally/contractually possible but a cross-sign from a Let's Encrypt intermediate already cross-signed by DST Root CA X3 should is probably another solution (but maybe not a good one, as it's add a level in the chain to send, which increase the handshake size, where one of the objective of ECDSA is to reduce it.)

Yes! Of course, it's the priority without any doubts. These questions just needed to be asked before it was too late and some irremediable steps took place.

Thanks a lot for these answers, and all the awesome work you all do, making the internet a safer place!

Do you have a estimated timeline about it? (As Upcoming Features - Let's Encrypt still indicate an ETA for "Q3 2018" and Chain of Trust - Let's Encrypt "March 2018" => "Chain of Trust" page still indicate "March 2018" for ECDSA root instead of "Q3 2018" · Issue #323 · letsencrypt/website · GitHub)

The CT, ACMEv2 and the TLS-SNI bug obviously has delayed your previsions. (Not a criticism, on the contrary, there is absolutely no reason to rush for ECDSA)

Hi, do you have any update on this topic? Upcoming Features page still lists ETA for Q3 2018, and it's already Q3 2018. :slightly_smiling_face: Thanks.

1 Like

Hi,

@jsha is cureently out for vacation… so I’m afraid he can’t answer anything until mid-auguest…

In the meantime, @josh might be able to help?

Thank you

1 Like

The ETA has been pushed back to Q1 2019:

2 Likes

Is the publication of the draft still planned?

Yep, still planned; thanks for the reminder!

1 Like

Hi @jsha, any update on a draft publication?

No update yet, sorry!

1 Like

Thank you, as long as Let’s Encrypt consults the community before signing the new roots I’m happy :smile:

I saw that the deadline was just pushed to Q2 2019:

Apparently it was just changed to Q3 2019: https://github.com/letsencrypt/website/commit/696b1005ab354b37a477e657fe5ad465108ab321

Is there any reason to rush ECDSA when there are already standards for Ed25519-based certificates? There are known issues with both ECDSA algorithm and secp256r1 curve, such as the possibility of key leakage if the server is low on entropy and dubious curve constant source (with Bruce Schneier specifically recommending against using this curve because of it).

Sources: [1] [2] [3]

I think EdDSA would first need to be approved in the BRs, whereas ECDSA is already approved and more widely supported by FIPS 140-2 HSMs.

2 Likes

Is it very likely that approval will happen in a year from now?

In my opinion, there is no urgent need to create a new root certificate, an intermediate could suffice, since it won’t require changes on client side and the only time the RSA signature on ECDSA intermediate will be verified is when it is first encountered. Also, ECDSA signature verification is more resource-intensive than verifying a RSA signature of a similar security level.

Overall I agree that ECDSA should be an available option, but I don’t think there is any point for generating a new root certificate and go through the process of getting it added to each browser.

No reason to rush it at all. And I'm glad they prioritized a CT log over it, I was just noting the new deadline :slightly_smiling_face:

I think I agree with you. I full chain seams more "clean" but may not be the most efficient thing to do. The lasts messages shows how important the discussion with the community could be important before LE signs new certificates. Those things shouldn't be rushed!

2 Likes

More information here about the ECDSA timeline change: https://letsencrypt.org/2018/12/31/looking-forward-to-2019.html

“We had planned to add ECDSA root and intermediate certificates in 2018 but other priorities ultimately took precedence. We hope to do this in 2019. ECDSA is generally considered to be the future of digital signature algorithms on the Web due to the fact that it is more efficient than RSA. Let’s Encrypt will currently sign ECDSA keys from subscribers, but we sign with the RSA key from one of our intermediate certificates. Once we have an ECDSA root and intermediates, our subscribers will be able to deploy certificate chains which are entirely ECDSA.”

1 Like

Increased security rarely adds efficiency.
In this case, I would trade the loss in efficiency for the increased security in the complete separation from RSA.
When completely separate, if/when ever there is a break in RSA it should not affect the ECDSA chain.

1 Like

I don’t see as much of a decrease on one system:
256 bit ecdsa (nistp256) 0.0000s 0.0001s 24702.2 10604.2
384 bit ecdsa (nistp384) 0.0002s 0.0008s 5288.4 1258.6
521 bit ecdsa (nistp521) 0.0005s 0.0010s 1957.2 982.2

But I do see a similar very significant difference on another:
256 bits ecdsa (nistp256) 0.0000s 0.0001s 26444.8 7264.5
384 bits ecdsa (nistp384) 0.0019s 0.0011s 534.0 930.4
521 bits ecdsa (nistp521) 0.0036s 0.0023s 275.8 425.7

Yeah, P-256 is often given a thoroughly optimized implementation on common platforms, whereas the other key sizes use slow/naive code.

e.g. in https://golang.org/src/crypto/elliptic/, you can see that only P-256 has an assembler version provided.

But I’m not sure who suggested that Let’s Encrypt would use P-384 to begin with???

1 Like