On 08/11/2015 07:59 PM, Martin Thomson wrote: > On 11 August 2015 at 16:38, Clemens Hlauschek > <[email protected]> wrote: >>> Maybe I should have been clearer. The certificate might not include a >>> (strong) signal that allows the client to distinguish between ECDSA >>> and fixed ECDH, but the client might be configured with that >>> knowledge. >> >> There is no difference between an ECDH and an ECDSA, apart from >> (possibly) the KeyUsage Extension. > > I'l try again. Even if the certificate does not include that signal, > the software that accepts that signal might make assumptions or have > configuration that cause it to only be used in one way or another. > See NSS.
NSS does not support rsa_fixed_ecdh ecdsa_fixed_ecdh rsa_fixed_dh dh_fixed_dh, although it supports ECDH_ECDSA and ECDH_RSA (if I remember correctly) so your point is moot. Anyway, the only client implementations we found that were actually vulnerable to the attack (Safari/Mac OS X -- supporting (EC)DH_* key exchange and *fixed_(ec)dh client authentication) did not make these assumption you are talking about, and I can not see why they should. We are currently working on a video showcasing an actual attack (Safari -- Facebook). > >>> NSS (incorrectly) adopts the posture that _ECDH_ suites are >>> half-static: the server share is in the certificate, but the client >>> side is fully ephemeral. This is clearly in violation of RFC 5246, >>> Section 7.4.7 and RFC 4492, Section 3.2. I'm not going to worry about >>> that right now :) >> >> Please elaborate. I do not see how this half-static behaviour >> constitutes any violations of the mentioned RFCs. > > Both the above cited sections say very clearly that for fixed (EC)DH > cipher suites the client where the client has a fixed (EC)DH > certificate, the client MUST send an empty ClientKeyExchange. Yes, that is correct. But for fixed (EC)DH client authentication. > > Of course, you might say that this is simply a consequence of not > supporting fixed (EC)DH for client authentication, and then it's not > technically in violation. The value of the ClientCertificateType from > the CertificateRequest is likely important here, but that field is > systematically ignored in practice (NSS ignores it). I could find nowhere in the spec that a (non-ephemeral) (EC)DH key agreement necessary implies fixed (EC)DH client authentication to be used. The other direction (fixed (EC)DH client authentication requires a (EC)DH key agreement, is insinuated by the spec, but still left ambiguous (a conclusion I came to after discussing exactly that with the OpenSSL developers). Regards, Clemens _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
