RE: [TLS] Empty ClientKeyExchange

Hi Mohamad,

Since you're presumably negotiating this identity protection feature
with TLS extensions, you could negotiate different syntax for
ClientKeyExchange as well (along the lines "if the identity protection
feature is used with DH_DSS/DH_RSA ciphersuites, the ClientKeyExchange
message always contains explicit Diffie-Hellman public value").

(However, in the case of DH_DSS/DH_RSA ciphersuites with client
authentication, Yc is a permanent identifier for the client, so while
it's not human-readable, an eavesdropper could still correlate
sessions by the same client.)

Best regards, 
Pasi

> -----Original Message-----
> From: ext Mohamad Badra [mailto:badra@enst.fr] 
> Sent: 31 May, 2006 16:05
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: tls@lists.ietf.org
> Subject: Re: [TLS] Empty ClientKeyExchange
> 
> Dear Pasi,
> 
> Sorry for the late reply, my mail server had some problems...
> 
> In fact, Urien and I wrote a document (will be published by IETF
> secretariat) providing the client's identity protection. To do that,
> we propose to encrypt the certificate using a "symmetric key"
> derived from the master_secret [1] (please keep in mind the EAP-TLS
> handshake). Thus, if the client uses a DH_DSS or DH_RSA, the server
> will not be able to compute the premaster secret and the
> master_secret.
> 
> If the Yc will be sent again, it will break the TLS specs. Hence, I 
> think sending the Yc in an TLS extension when identity protection is 
> desired.
> 
> Finally, I don't know any implementation of TLS1.0 that sends Yc again
> in ClientKeyExchange.
> 
> Best regards,
> Badra
> 
> [1] we sent a draft to the IETF secretariat, and it is disponible at
>
http://www.infres.enst.fr/~badra/draft-urien-badra-eap-tls-identity-prot
ection-00.txt

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls