Re: [TLS] Empty ClientKeyExchange

Mohamad Badra <> Wed, 31 May 2006 13:05 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1FlQOI-0006hc-Vl; Wed, 31 May 2006 09:05:38 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1FlQOH-0006hP-2z for; Wed, 31 May 2006 09:05:37 -0400
Received: from ([] by with esmtp (Exim 4.43) id 1FlQOE-0002RO-Oj for; Wed, 31 May 2006 09:05:37 -0400
Received: from localhost ( []) by (Postfix) with ESMTP id B94801A88; Wed, 31 May 2006 15:05:33 +0200 (CEST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cOJ3U6nff9pJ; Wed, 31 May 2006 15:05:32 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTP id 24B555AE; Wed, 31 May 2006 15:04:45 +0200 (CEST)
Message-ID: <>
Date: Wed, 31 May 2006 15:04:38 +0200
From: Mohamad Badra <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: fr-fr, fr
MIME-Version: 1.0
Subject: Re: [TLS] Empty ClientKeyExchange
References: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

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 

Finally, I don't know any implementation of TLS1.0 that sends Yc again
in ClientKeyExchange.

Best regards,

[1] we sent a draft to the IETF secretariat, and it is disponible at 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 []
  >>Sent: 30 May, 2006 15:14
  >>To: Eric Rescorla
  >>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, second paragraph:
  >>           In this case, the client key exchange message will be
  >>           sent, but it MUST be empty.
  >>In RFC2246, Section, 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?
  >>Best regards,

TLS mailing list