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-protection-00.txt

Pasi.Eronen@nokia.com a écrit:
  > Hi Mohamad,
  >
  > Both versions of this sentence seem to say exactly the same thing:
  > when you do client authentication with DH_DSS or DH_RSA ciphersuites,
  > the client certificate already contains Yc (the client's public DH
  > value), and the same value is not sent again in ClientKeyExchange.
  > (And sending a different value would not make any sense.)
  >
  > The RFC2246 version states this as a simple fact; RFC4346 prefers
  > a RFC2119 keyword. IMHO neither version leaves much room for
  > interpretation...  but it seems that you have a different opinion?
  > Are you aware of existing TLS 1.0 implementations that do send
  > Yc again in ClientKeyExchange?
  >
  > Best regards,
  > Pasi
  >
  >
  >>-----Original Message-----
  >>From: ext Mohamad Badra [mailto:badra@enst.fr]
  >>Sent: 30 May, 2006 15:14
  >>To: Eric Rescorla
  >>Cc: tls@lists.ietf.org
  >>Subject: [TLS] Empty ClientKeyExchange
  >>
  >>Hi Eric and all,
  >>
  >>May you please clarify the need of replacing the *will be* with the
  >>*MUST* in the following text:
  >>
  >>In RFC4346, Section 7.4.7.2, second paragraph:
  >>
  >>           In this case, the client key exchange message will be
  >>           sent, but it MUST be empty.
  >>
  >>In RFC2246, Section 7.4.7.2, second paragraph:
  >>
  >>            In this case, the Client Key Exchange message
  >>            will be sent, but will be empty.
  >>
  >>I don't think that *will be* is equivalent to "MUST*, isn't it?
  >>
  >>Thanks
  >>Best regards,
  >>
  >>Badra
  >
  >
  >
  >

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