Re: [TLS] TLS and KCI vulnerable handshakes

[Clemens Hlauschek <[e-mail]>]

On 08/11/2015 07:59 PM, Martin Thomson wrote:
> On 11 August 2015 at 16:38, Clemens Hlauschek
> <[e-mail]> 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