OK than it should be mentioned in the issue. “however there might be no support on the Boulder side at all yet.” sound for me Like an Boulder/Server issue.
1 Like
Yes, at that moment there wasn’t support in Boulder yet. But now that there is support, one could implement it in the client.
And no, why should it be mentioned in the issue? It’s clearly an issue in the letsencrypt / letsencrypt section, not in letsencrypt / boulder or somewhere else 
1 Like
I hope you’ll expand the supported elliptic curves to better ones like Curve25519 when they are finally support in current Browsers, because currently only some curves from the NSA Suite B are supported and they may be a bit flawed. If you follow these links and click a it through you can also find the specific tracking issues about this (at least for Firefox).
1 Like
From the Let’s Encrypt side of things, they’ll have to wait until the CA/B Forum permits other curves to bring them live. Right now section 6.1.5. of the Baseline Requirements limit all compliant CAs to the NIST curves. This is also reiterated in Let’s Encrypt’s CPS.
3 Likes
Okay. But when the curves are supported in the browser I assume it might not take long until it is also included in the CA/B Baselines.
3 Likes
6.1.5 Page 29 here are three EC types listed namely P‐256, P‐384 and P‐521
But the P-521 was rejected currently be LE.
And from the link (openssl - Which elliptic curve should I use? - Information Security Stack Exchange) you mentioned
I'd say stick to secp521r1 - even DJB says P-521 is pretty nice prime, and it's also supported in every modern crypto library.
So maybe this could be enabled at least ?
1 Like
It’s not supported in Chrome, though.
Speaking of, to quote rlb, “We need a caniuse.com for crypto.”
1 Like
secp521r1 is also the only ECC curve which has equal strength to 256 bits AES…
As encryption is only as strong as its weakest link, by disabling secp521r1, the use of 256 bits symmetric ciphers isn’t optimal: secp384r1 only provides security equal to a symmetric cipher of 192 bits. In effect, you’re loosing 64 bits of security… Which would be quite regrettable IMHO…
1 Like
Chrome isn't the only browser out there as far as I've checked. 
1 Like
The first thing we'd need there would at least be a listing of supported TLS protocol versions.
Afterwards we can think about elliptical curves:
2 Likes
Currently, the specification for EdDSA certificates (and Curve25519 ECDH for TLS) is under development by the IETF CURDLE WG. It’s going to be a long road until it’s ready for deployment; first the specification needs to get, well, not necessarily done, but stable enough that it can be implemented (consider that the ACME spec isn’t even finalized yet, but we have live implementations).
Then you need to add support to probably at least two TLS implementations (OpenSSL is more commonly used on the server side, and NSS more commonly on the client side; if you consider how long it took NSS to support TLS1.2…), and get a resolution in the CA/Browser forum allowing it to be used, and get support into Boulder (which will in turn require support in Go’s crypto libraries and CFSSL – so actually three TLS implementations), and clear whatever other policy hurdles will be in the way.
If you want Ed25519 account keys that will also require the Ed25519 for JOSE specification to become reasonably stable and support to be added to the Go implementation of it. If you want Ed25519 intermediates (as opposed to just ECDSA-signed Ed25519 subjects) you’d also need to procure HSMs which support Ed25519 signing, and it’ll probably be a long time before any such HSMs are even available. (Edit: I would also suspect that Let’s Encrypt won’t be able to source Ed25519 cross-signatures from their existing cross-signer, so the most expedient route would be to get an Ed25519 root installed in all root programs, which itself takes time, and that in turn assumes that root programme operators will by then have reached a resolution regarding inclusion of Ed25519 roots.)
TLDR: It is going to be a long time before Ed25519 is available, even assuming Let’s Encrypt has the desire to support it.
4 Likes
Thanks for the information… Now we can just hope for the future. 
1 Like
That’s really a great idea.
I just moved from self-signed ECC to letsencrypt’s RSA. Hope I can use ECC again!
1 Like
As mentioned you can already do.
1 Like
It's currently not yet in production, only in staging
Besides, it'll be a RSA signed ECC public key containing cert 
1 Like
well it is signed by RSA but your server only has to sign using ECC which is good and for the client it is not much of a matter whether to verify RSA or ECC, because unlike a server a client usually doesnt handle many concurrent requests.
1 Like
from now this is included on standard
https://www.rfc-editor.org/rfc/rfc7748.txt
1 Like
okay this quote from the RFC is epic.
The ~224-bit security level of curve448 is a trade-off between
performance and paranoia. Large quantum computers, if ever created,
will break both curve25519 and curve448, and reasonable projections
of the abilities of classical computers conclude that curve25519 is
perfectly safe. However, some designs have relaxed performance
requirements and wish to hedge against some amount of analytical
advance against elliptic curves and thus curve448 is also provided.
I hope they get implemented in browsers and CAs soon.
p521 might not be in any serious standard like nist yet, but 25519 and 448 are in the rfcs and that looks like I can use some epic security.
1 Like
- http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf so NIST contain the curve.
- Also many (~75%) browsers have support for it. (see: https://www.ssllabs.com/ssltest/analyze.html?d=suche.org&latest)
- "NSA were only interested in 192-bit security for Suite B"
Maybe the point to which some agency are able to break the cipher ?
I would not say that it have todo with https://letsencrypt.org/documents/LE-USG-SA-Amendment-Sept-22-2015.pdf that would only say tinfoil people
1 Like
wow finally I see a software that automatically checks for ) and removes it from the link.
but chrome killing 521 and a yet active bug on Firefox from people trying to kill 521 doesnt make it look good.
1 Like