So it enables a server to use non-ephemeral ECC DH, based on the certificate ECC public key? At least, that’s the conclusion I get from the part between the parentheses somewhere in the middle… But that can be prevented by choosing the right cipher suits, i.e.: not include any non-ephemeral suits in your SSLCipherSuite (or equivalent) directive.
I’m very interested in the research you mention 
[quote=“Osiris, post:21, topic:8809”]
So it enables a server to use non-ephemeral ECC DH, based on the certificate ECC public key?
[/quote]Yes, and in case of client-side static ECDH support + client certificate authentication for which the corresponding private key hasn’t been delivered securely impersonation is possible.
Here: https://kcitls.org/
Facebook was a perfect example due to DigiCert previously setting “key agreement”.
The paper specifies the following (section 5.1.2, page 8):
ECDSA certificates are structured identical to ECDH certificates, and can be used in the attack instead of ECDH certificates under certain circumstances: If the X509 Key Usage extension is used in the certificate, in principle, the KeyAgreement bit must be set so that these certificates can be used for the attack. The KeyAgreement bit is sometimes wrongly set in practice (e.g., it is set in the current ECDSA certificate for facebook.com).
If we look at section 4.2.1.3 of RFC 5280 (Key Usage), we can see that "Key Encipherment" (set in the LE certificate) and "keyAgreement" (KCI attack paper) are two distinct Key Usage purposes.
So I guess there isn't a problem after all?
OK, but this problem is a bit more complex. Content off the certificate is primary meant for the receiver.
To check if the usage is allowed, if it is valid etc.
So for example if the certificate is outdated most server will still deliver it.
If you tell your server use this certificate for keyAgreement i am not sure if all server check it.
So if the ciritical cipher suite is possible (your fault for this cert types)
and the client select it (can be forced by client)
since i think some server will not check the keyUsage your private key is disclosed.
Yes. As far as I understand, while Key Agreement is dangerous, Key Encipherment is just of no use.
Digital Signature is used for (EC)DHE key exchange. Key Encipherment is used for static RSA key exchange.
While TLS_RSA_… cipher suites exist, (EC)DSA is more complex by default. I mean, the cipher suites are already TLS_DHE_DSS_… and TLS_ECDHE_ECDSA…
Excuse me? 
The private key of the server is never disclosed in this attack.
The biggest problem with this attack is that the attacker has to install a pre-generated client certificate/private key combination into the clients system. And KeyEncipherment isn't used in this attack, KeyAgreement is.
Of no use, but not dangerous, correct? So in the end, it isn’t that big a problem that Boulder sets the KeyEncipherment key usage bit? Because KeyAgreement is not set
[quote=“tlussnig, post:24, topic:8809”]
Content off the certificate is primary meant for the receiver.To check if the usage is allowed, if it is valid etc.
[/quote]Yes. Certificate is for client to check it. For server there is the corresponding private key.
[quote=“tlussnig, post:24, topic:8809”]
So for example if the certificate is outdated most server will still deliver it.
[/quote]Yes, and why wouldn’t it? The security impact of an expired certificate is that its issuer no longer publishes its status, and it doesn’t necessarily mean it’s compromised. So the only thing that should stop working is OCSP Stapling.
[quote=“tlussnig, post:24, topic:8809”]
If you tell your server use this certificate for keyAgreement i am not sure if all server check it.
[/quote]Checking certificate key usage is a client’s business. A server doesn’t care.
[quote=“tlussnig, post:24, topic:8809”]
So if the ciritical cipher suite is possible (your fault for this cert types)
[/quote]This attack doesn’t require server-side static ECDH support.
Ok i got some parts wrong. I thought it was an problem similar to the PS4 hack there the NONCE was static and allowed to calculate the private key.
But at least this is an requirement that is still valid.
an attacker who is in possession of a client certificate's private key
So first the MiT person need the private key of one side. Which is already an security breach.
I know that firefox for example ask you if you like to use an client certificate for side X.
So if you got KEY and cert via social engeniering and accept it to be used for other side what shell i say?
If you get via social engineering or from your D*** computer supplier and CA that find its way into your truststore.
The MiT can also impersonate all pages. (Excpect EV)
Yes, but of no use => bloat.
Bloating certificates => bloating handshakes.
ECDSA usage is partially driven by smaller key and signature sizes. Making certificates bigger by setting an unnecessary key usage bit is illogical.
Actually, no… The Key Usage extension is just one byte large (actually, 9 bits, but I couldn’t find the 9th bit in the WireShark handshake certificate hex stuff 
) of which every bit is a 1 or 0 (i.e.: true/false or set/unset, whatever floats your boat) for each of the possible key usages. So it doesn’t matter if you switch a usage on or of: the certificate doesn’t grow larger. Only the usage of the Key Usage extension itself makes the certificate larger, but we’ll all agree we can’t let that one out.
But semantically ofcourse: if it isn’t needed in any way, as it is in RSA certificates (I assume), it’s prudent to not set it at all. Perhaps it might have ramifications we just don’t know yet.
After this works now on Staging. When will it be available in production ?
Offtopic: hopefully around the time the OCSP Must-Staple PR also has been merged with staging and tested 
I’m waiting for both these features actually…
so right now for ECSA testing we need to pass --test-cert flag (webroot ?) and then also pass the path to --csr /path/to/ecdsagenerated-csrfile ?
or can we let letsencrypt client generate the csr file too ?
there’s no equivalent to cli.ini setting for rsa-key-size ? is that ignored in a cli.ini if you pass the path to --csr /path/to/ecdsagenerated-csrfile ?
FYI: With a pull request from today letsencrypt.sh also supports prime256v1 and secp384r1.
This new feature (pull request #1298 for Boulder by @hlandau) is for the CA software of Let’s Encrypt (“Boulder”) only as of yet. As far as I know, the official client currently doesn’t have any ECDSA features of its own. There’s already an issue for the implementation of ECDSA subject keys in the official Let’s Encrypt client.
I see cheers @Osiris 
Sample result for an EC Certificate (T rating because of statging)
https://dev.ssllabs.com/ssltest/analyze.html?d=ec384.suche.org&hideResults=on
well old IE versions are junk in the first place and for legacy systems you have firefox.
but I wonder why P521 is not allowed
