Comment by jfindley

Indeed, I think that might be viable: it certainly was for CloudFlare! And good ECC certainly is "modern security techniques and best practices". I would however be OK with RSA-2048 using SHA-256, I guess; it's what many other CAs currently use (and this is partially a lowest-denominator problem).

Comodo definitely has an ECC root available now, a cross-signed ECDSA root with secp384r1, signing a secp256r1 intermediate. (I had heard there were 3 others deployed out there, although off the top of my head I'm not clear about which they are, perhaps they're also cross-signed?)

Why is ECC so poorly deployed in TLS? I've heard indications Certicom had formerly aggressively asserted patents, hence the lack of ECC-supporting CAs; but I don't know which ones. I highly doubt they're still extant, however: many have since expired.

Do be aware however that ECDSA can present a huge hazard if the k value needed for every signature is even partially predictable and varies. Officially, it should be random, and very strongly random (even the first two bits being consistently predictable is cumulatively disastrous; using the exact same k to sign two different things is absolutely catastrophic and is how the Sony PS3 root keys were calculated!). If you have a strong PRF for your RNG, you should be fine (e.g. LibreSSL uses ChaCha20); if you want some insurance just in case, you can use a more-auditable and less fragile deterministic process with a strong PRF so the same signature always gets the same, unpredictable k (see RFC 6979), or a combination of the two approaches (e.g. BoringSSL). DSA also had this issue. If you haven't audited your RNG and know it's strong, maybe you should check it before you deploy ECDSA: if your system's headless, its entropy is running on empty and your idea of a mixing function is RC4, it might not be such a hot idea.

It'd be fantastic to have the option available to have an ECC root around, and let us have RSA or ECC certs. (Yes, you can cross-sign across algorithms.) Perhaps have ECDSA off by default for a while in light of the above, but it can provide very good performance for people who use modern software and turn it on!

I'd suggest using secp256r1 (aka NIST P-256). It's already deployed and 256-bit curves lie at about RSA-3072 strength (stronger than most deployed CAs now, which typically use RSA-2048). A few others have deployed secp384r1, but that was following the NSA's Suite B lead; I'm not sold on that being relevant at all. secp256r1 is also fairly fast, with some very well-optimised constant-time routines available in OpenSSL if you enable a flag or even faster ones if you're using 1.2 beta (expect something like a 200%-250% performance boost over the generic elliptic curve routines); it's not quite Curve25519 speed, but it isn't bad.

I do however acknowledge the extreme murkiness surrounding the generation of the NIST/SECG/X9.62 curves. That does present some concern to me. I tried to get to the bottom of that (see my posts on CFRG) and I can summarise what I found out as basically (now-expired/irrelevant) patent-related shenanigans. I'm not super-comfortable with that degree of opacity in my curves - however, I also don't know of any actual security problems with secp256r1 (or secp384r1) as they stand, providing they are properly implemented (very big proviso!). I don't think they're backdoored, but make sure you check the hinges on the front door, and I'd prefer a house with better foundations!

More transparently-produced curves (such as the Brainpool curves) do exist, but Brainpool is sadly very slow in software (less than half the speed than a good P256 routine, and no scope for optimisations).

So looking forward, CFRG (at IRTF) were asked by the TLS Working Group to recommend even better new curves: most probably Curve25519 in my opinion as that seems to admirably satisfy all the criteria for a fast strong mainstream curve, and probably one larger "extra paranoid" curve will be recommended which I really don't know what it'll be at this stage. These hopefully will be/are even faster, strong, and rigidly-explained, without murky origins. And hopefully there will be better algorithms than ECDSA (perhaps a Schnorr-based algorithm such as Ed25519, now the patent expired?). I very much doubt if all the supporting infrastructure for that like HSMs and widely-deployed software support will all be "ready" for this project, however, in the timeframe we'd like, however, so in the meantime, P256 or RSA-2048 I guess is OK.

In general: This is absolutely wonderful news. It, and the efficiency of TLS 1.2 (and later, TLS 1.3) will enable people to run TLS everywhere. I am very probably going to use it myself.

While the Israel-based CA StartCom do already offer free TLS certificates and I have previously lauded them for that, they pulled an absolutely unforgivable move detrimental to internet security as a whole in refusing to revoke and rekey certificates for free even exceptionally in the immediate wake of Heartbleed (and I do think they should have their CA status reviewed very harshly as a result or revoked, because I do not think that is compliant with CA/B guidelines: they definitely still have live signatures on compromised keys that have not been revoked, which is totally unacceptable). If this initiative means we can replace and dump bad CAs, it's even better news.

Hm? The overhead reduction is on the server. Verification IIRC is somewhat slower.

There are CAs that issue them, uh... someone managed to get one issued during the TLS WG meeting at IETF last week. I'd have to listen to the audio to find out what CA they used.

I can help get a ECDSA cert for you - my (personal) email is on my profile.