On 08/11/2015 05:06 PM, Martin Thomson wrote: > On 11 August 2015 at 12:05, Ilari Liusvaara <ilari.liusva...@elisanet.fi> > wrote: >>> I don't see how that would work. A client that understands the cert >>> to be ECDSA won't pair the key with the server's ECDH share, they will >>> sign the session transcript with it. >> >> a) ECDSA certs are usable for ECDH (modulo KeyUsage) because there is >> no ECDSA-specific keytype in X.509. > > 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 checked NSS and there doesn't seem to be any way that it could be > coerced into using the (EC)DH pair from a client certificate in a key > exchange. Even though it supports some fixed (EC)DH suites. To the best of our knowledge, NSS does not support fixed ECDH client authentication. I checked the code manually. Prof Matt Green also verified with EKR at Mozilla during the pre-public disclosure phase that NSS is not vulnerable. > > 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. I would say half-static ECDH handshake is not only fully spec conforming, but *the* way to do an ECDH handshake when client authentication (*_fixed_(ec)dh) is not requested by the server. OpenSSL, as well as other implementations, do the same. Clemens _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
