Re: [TLS] TLS and KCI vulnerable handshakes

[Clemens Hlauschek <[e-mail]>]

On 08/11/2015 05:06 PM, Martin Thomson wrote:
> On 11 August 2015 at 12:05, Ilari Liusvaara <[e-mail]> 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