I agree with a P-384 root, the cost of a slightly longer chain is a small price to pay compared to the risk of a weaker curve being rendered obsolete in 15 years.
In my opinion I wouldn’t get cross signs, I think just having the old RSA root with a cross sign should be enough for legacy devices. I intentionally configure my systems to only support the latest and most secure crypto standards.
One downside I can think of for P384 is that the implementations are often not optimized, which would affect handshake speed and overall CPU usage for servers and clients. On my laptop (OpenSSL 1.1.1f):
@_az I’m curious, how many times do TLS clients actually verify the chain up to the root certificate? I can imagine this is something that’s cachable: verify the first time the client comes across a certain intermediate/root combination, do the costly asymmetric verification and cache this result. Afterwards, it can use this cached result for future chains during a certain lifetime.
Also, does the size over the wire actually increase when using a larger key? The root certificate isn’t send over the wire and the signature hash stays the same right? So the signature on the intermediate stays the same size, even when using a larger key? Or am I missing something here?
I believe that in practice the size on the wire will increase yes, the hash chosen will be larger for the bigger key in order not to unnecessarily introduce a weak point. SHA-384 would be used with the P-384 whereas SHA-256 could be allowed for P-256. So the signatures will be (on average) perhaps 50% larger.
I don’t know if clients such as web browsers remember that a particular intermediate checked out as signed etc. previously but certainly if it was an important optimisation they could consider doing that.
So that’s like, “semi” mandatory. I.e., Mozilla wants it that way, but not really mandated by the CA/Browser Forum Baseline Requirements. At least, I can’t find anything regarding these rules in the BR. Only a basic set of allowed digest algorithms and ECC curves, but not the forced combination Mozilla shows here.
Let’s Encrypt is part of the Mozilla root program, and intends to remain so, so Mozilla’s requirements apply to us regardless of whether those requirements are in the BRs. CAs have to follow the requirements for all root programs they’re a member of, and all of the major root programs incorporate the BR requirements in addition to their own.
You’ve hit on an interesting topic. The CA/Browser Forum actually has an in-development “Browser Alignment ballot” which incorporates some of the root program-specific requirements into the BRs: https://github.com/sleevi/cabforum-docs/pull/10.
I would prefer to see a 256 remain for at least 10 years as a fallback, with a strong recommendation that implementers use the 384 if possible.
While everyone here has a reasonably fast computer or smartphone, this is not a global phenomena. Older devices and low-end devices popular in non-US/EU markets are often much slower. Browser performance can be further degraded when used within another app (for example, the web-browsing experience within the Facebook or Twitter iOS apps vs Safari on the same device) or when there is https content from multiple servers on a single web page.
Perhaps this is unnecessary now, but this has caused a lot of headaches for me in the past (including needing to offer HTTP content, because HTTPS was painful on a lot of target hardware/os profiles). While 384 is a great idea for our market, 256 might be best for a global one.
Thanks for the numbers! It’s worth noting that the performance difference actually goes the other way for the hash algorithm. SHA-384 is a truncated version of SHA-512, which surprisingly is actually faster than SHA-256:
Just answered this on twitter, but repeating here:
Your argument for a full ECDSA chain is chain size. The savings of ECDSA vs RSA are around 200 bytes.
If you care about size savings in this ballpark you could also consider shortening strings. It seems pretty much all URLs in the existing intermediate (CPS, OCSP, CRL) could be shorter, also you could just use “Let’s Encrypt Y3” or even “LetsEncryptY3” instead of “Let’s Encrypt Intermediate Y3”.
This saves you ~100 bytes.
@hannob ECDSA is faster in terms of signing compared to RSA. This would lower the load on Let’s Encrypts HSMs. Not sure if that’s really necessary though.
Unfortunately, verification of ECDSA is much slower. P-256 verification is about comparable to 4096 bits RSA, but P-384 is more than 10 times slower. 2048 bits RSA verification is massively faster though.
i thought the new version of the APIs suggest that you get the intermediate from the API call rather than hard coding it. This was always a challenge with client implementations hard coding intermediates.
ACME has always specified that clients get the intermediates via API call. However, ACMEv1 required additional API requests to get the intermediates, leading some clients to hard-code it instead. In ACMEv2, the certificate is delivered as part of a PEM response that also includes any intermediates needed. Hopefully this has made getting intermediates via the API the “easy path.”
This is a good idea, thanks. We’re discussing internally our options for shorter URLs, and I’ll also think about options for naming improvements. One thing to note here is that organizationName is required per BRs § 22.214.171.124.1, and that will contain “Let’s Encrypt,” so including that string a second time in commonName is redundant - the commonName could be just “Y3.”
Thanks to everyone on the feedback about P-256 vs P-384. I’m convinced to go with P-384 for the root and all intermediates, and will update the top post correspondingly.