RE: [TLS] Empty ClientKeyExchange

<Pasi.Eronen@nokia.com> Wed, 31 May 2006 16:10 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlTGu-0002vn-WB; Wed, 31 May 2006 12:10:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlTGt-0002vE-6g for tls@lists.ietf.org; Wed, 31 May 2006 12:10:11 -0400
Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlTGr-00047U-Ne for tls@lists.ietf.org; Wed, 31 May 2006 12:10:11 -0400
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4VGA0w6025971; Wed, 31 May 2006 19:10:05 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 19:10:05 +0300
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 19:10:04 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [TLS] Empty ClientKeyExchange
Date: Wed, 31 May 2006 19:10:03 +0300
Message-ID: <B356D8F434D20B40A8CEDAEC305A1F2402B8FDAC@esebe105.NOE.Nokia.com>
In-Reply-To: <447D9466.9050901@enst.fr>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Empty ClientKeyExchange
Thread-Index: AcaEszUYi8npxRfVQC2fPsM0mKvboAAF/6sQ
From: <Pasi.Eronen@nokia.com>
To: <badra@enst.fr>
X-OriginalArrivalTime: 31 May 2006 16:10:04.0656 (UTC) FILETIME=[AD8D6F00:01C684CC]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
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

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