Considering more broadly than just Let's Encrypt, are you developing your clients to default to ECC keys now? Are they compatible enough with the various ACME CAs and relying parties to be worthwhile?
To clarify, I'm talking about certificate keys, not account keys.
When we released Certify The Web v6.0 we defaulted to ECC keys but discovered later that versions of windows (server) upgraded from older versions often didn't have the right config enabled and would break themselves trying to use the new keys.
Broadly though, it's still just little bit early to tell on compatibility as I'm not sure absolutely everyone previously on an EC leaf is now on the full EC chain. We have seen some reports of compatibility issues here and there e.g. Mac RDP not able to connect to E5 wildcard - #35 by webprofusion
Hard (for me) to tell how the experience would fair with other CAs, I don't really follow their chain of trust story as closely, mostly because they have little or no community and don't talk to us
I do think it's probably too early for "broad internet" websites to switch to X2 as their only trust anchor, unfortunately, so we're going to have an RSA trust anchor for a while yet.
I do think defaulting to ECDSA keys at this time is reasonable for most ACME Clients. The biggest compatibility hazard I've seen in the wild is webservers which blindly expect to load an RSA key from a configuration file, which could probably be easily adapted to ECDSA if needed.
If you want forward-secret cipher suites with older versions of windows, for some reason they only allowed ECDHE with ECDSA keys for some reason (iirc, like Windows Server 2012 era?).
There are definitely some TLS clients that only support RSA, though I think they're far and few between now. Cloudflare's free tier I believe only supports ECDSA certificates, for example, so there's a bit of evolutionary pressure to supporting ECDSA.
Certbot now defaults to ECDSA, and I haven't seen a lot of people needing to switch on this forum at least.
From Let's Encrypt perspective, ECDSA uses less disk and signing resources for us, so it's advantageous to us for more people to switch to ECDSA.
I think most people, who don't know what kind of key type to use, will be fine if the default is ECDSA, since that will work for most normal user-facing web sites.
The tricky bit is that if they do need to integrate with some old system that doesn't know what ECDSA is, they're likely to get a vague, confusing error message like "Server error", or their incompetent hosting provider will just say "the cert is invalid", which doesn't really give them an indication that they need to check the RSA box in their ACME client configuration in order for their system to work.
I think it's definitely still worth ECDSA being the default, though. While there have been a few times on the forum since certbot 2 switched to ECDSA by default that we've needed to direct people to just add --key-type RSA to their certbot command, compared the number of new certs being added out there it's a really small percentage.
For as close to an "official" recommendation as I think there is, the Mozilla Guidelines recommend ECDSA for not just "Modern" (TLS 1.3 only) sites, but also for "Intermediate" compatibility. That's for web sites, though, and people using TLS for other applications like email servers really still need to have an RSA cert (even if it's in parallel with an ECDSA cert) to deal with all the random old email servers out there.
This is still primarily an Audience question that has a different answer for every Registered Domain or Subscriber.
IMHO, I think the best option for an ACME Client is to default to RSA but advocate ECDSA and streamline a change (e.g. a single global value or checkbox to switch to the new default).
There are still many demographics and markets that do not have broad ECDSA support.
EDIT:
I think another good option is to use the Hybrid Approach. Nginx supports this, and I think a few other servers do too. The server can be configured with both RSA and ECDSA, and the appropriate key/cert is selected during the TLS Handshake - just like ciphers are negotiated.
I think it is good for ACME clients to default to creating ECDSA keys for their end entity certificates. Certbot does this now, and I believe it has done more good (in terms of reduced handshake sizes) than harm (in terms of site operator pain).
I think there are two key steps you can take to make the transition less painful:
Have clearly documented, simple, and persistent ways to switch back to RSA. Once someone says "wait no ECDSA doesn't work for me" once, believe them and switch back to RSA for that certificate permanently.
Don't switch over RSA certificates that already exist and are just being renewed. Only use ECDSA keys for brand new certificates. This cam be a tough heuristic to figure out, but it saves a lot of surprise.
Additionally: For ACME clients with any sort of "certs on demand" feature, you can always issue certificates based on what cipher suites your clients negotiate, since they're tied to the leaf key type. I believe the x/crypto/acme/autocert package in Go does this: prefer ECDSA, but will issue an RSA cert if a client that doesn't support ECDSA connects.
(I think we shouldn't count RSA and ECDSA as duplicate certs to enable that workflow with less "duplicate cert" rate-limit risk, but that's not something we've decided on yet)
Yep, it's something I'd like to do as well. Unfortunately it's also technically quite difficult, because the duplicate certificate rate limit is enforced when new orders are created, but we don't know the pubkey type until finalization. Obviously there are possible fixes, but it's nontrivial.
Feel free to add to the ACME-bis ideas allowing an order to submit multiple CSRs/keys of different types all at once to get multiple certificates for the same set of names all at once.
When I consider a security/protocol upgrade, I always consider the engineering student in Hyderabad, India, who is trying to run an occupant crash analysis on my web site, using a donated Windos whatever computer. So, I'll be sticking to RSA for a while longer.
I don't know what version of Windows your imagined student is running, but IE7 on Windows Vista supports ECDSA. Firefox supports it even on very old versions, including on Windows XP. In many cases, for older windows versions, ECDSA increases compatibility, because some old versions of windows only support ECDHE with ECDSA certificates.
My actual idea is to let pubkeys be submitted as "identifiers" in the new-order request, alongside DNS names and IP addresses. That way there can also be challenges to prove you control the corresponding private key (e.g. sign a data structure containing a nonce, or just do a TLS handshake) which comes with several nice properties.
That engineering student could/should use, even on old donated hardware, an open source OS that is up-to-date with today's security standards.
In practice virtually every client today supports ECDSA. The few remaining issues are rather, like @mcpherrinm said, with silly server deployment tools that make assumptions on RSA keys.
