RE: [TLS] Empty ClientKeyExchange

<Pasi.Eronen@nokia.com> Tue, 30 May 2006 14:06 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl4rX-0003Q4-Qx; Tue, 30 May 2006 10:06:23 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl4rW-0003Pz-W9 for tls@lists.ietf.org; Tue, 30 May 2006 10:06:22 -0400
Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl4rV-0005JU-Go for tls@lists.ietf.org; Tue, 30 May 2006 10:06:22 -0400
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4UE6JTl003006; Tue, 30 May 2006 17:06:19 +0300
Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 May 2006 17:06:19 +0300
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 May 2006 17:06:19 +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: Tue, 30 May 2006 17:06:20 +0300
Message-ID: <B356D8F434D20B40A8CEDAEC305A1F2402B5D8D2@esebe105.NOE.Nokia.com>
In-Reply-To: <447C36EF.8030308@enst.fr>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Empty ClientKeyExchange
Thread-Index: AcaD6MzQjB7yXldMTvmOgOiabwQJ7QAB1uNw
From: <Pasi.Eronen@nokia.com>
To: <badra@enst.fr>
X-OriginalArrivalTime: 30 May 2006 14:06:19.0050 (UTC) FILETIME=[392220A0:01C683F2]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
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,

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