Re: [TLS] Empty ClientKeyExchange

Mohamad Badra <badra@enst.fr> Wed, 31 May 2006 13:05 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlQOI-0006hc-Vl; Wed, 31 May 2006 09:05:38 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlQOH-0006hP-2z for tls@lists.ietf.org; Wed, 31 May 2006 09:05:37 -0400
Received: from revol2.enst.fr ([137.194.2.14] helo=smtp2.enst.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlQOE-0002RO-Oj for tls@lists.ietf.org; Wed, 31 May 2006 09:05:37 -0400
Received: from localhost (localhost.enst.fr [127.0.0.1]) by smtp2.enst.fr (Postfix) with ESMTP id B94801A88; Wed, 31 May 2006 15:05:33 +0200 (CEST)
X-Virus-Scanned: amavisd-new at enst.fr
Received: from smtp2.enst.fr ([127.0.0.1]) by localhost (revol2.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOJ3U6nff9pJ; Wed, 31 May 2006 15:05:32 +0200 (CEST)
Received: from enst.fr (mechmech.enst.fr [137.194.164.56]) by smtp2.enst.fr (Postfix) with ESMTP id 24B555AE; Wed, 31 May 2006 15:04:45 +0200 (CEST)
Message-ID: <447D9466.9050901@enst.fr>
Date: Wed, 31 May 2006 15:04:38 +0200
From: Mohamad Badra <badra@enst.fr>
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
To: Pasi.Eronen@nokia.com
Subject: Re: [TLS] Empty ClientKeyExchange
References: <B356D8F434D20B40A8CEDAEC305A1F2402B5D8D2@esebe105.NOE.Nokia.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Cc: tls@lists.ietf.org
X-BeenThere: tls@lists.ietf.org
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." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

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