igrigorik
commented
3 years ago Thanks for the detailed analysis and recommendation. It's been a while since that text was written, definitely open to updating it to account for any changes in the ecosystem since. Would you be willing to put together a PR to address this?
In the FAQ section, there is this statement:
But it lacks any reference.. This certbot discussion comment cites some rather old clients(along with their lack for SNI support which isn't uncommon today that'd fail with RSA as well), as does this June 2014 article.
ECDSA was first accepted as an ANSI standard in 1999, followed by IEEE and NIST standards in 2000. In 2006, it was added for TLS 1.0 and TLS 1.1 via RFC 4492, prior versions (SSL) aren't very common to encounter anymore, although early implementations of ECDSA support has been poor (such as Sony PS3 and Java 6, as well as OpenSSL 0.9.8 which has since been patched).
Here is a compatibility page on the subject from GlobalSign, they cite minimum versions where support for ECDSA became available and cite references to many of those. Perhaps linking to this page would be a good idea?
The likelihood of encountering a client that does not support ECDSA with modern issued certs of today seems rare. It would likely be from a platform that is EOL, or attempting to connect over old and insecure SSL/TLS protocols?
If the amount of clients lacking such support was a number worth supporting, I would think this would apply to a context where the admin would already be aware of such or giving it enough thought / analysis to put that extra effort into investigating. Such as an SMTP service (where port 25 may establish a secure connection between two MTAs via opt-in StartTLS, but this does not necessarily guarantee a secure transit to the end destination if there is multiple hops).
Such clients are less likely to be consumer based, for those that are, encountering a broken or insecure experience especially with websites online may be the norm, software would not likely be up to date.