Subject: [TLS] Empty ClientKeyExchange

From: Mohamad Badra <[email-masked]>
Date: Tue, 30 May 2006 14:13:35 +0200

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: <[email-masked]>
Date: Tue, 30 May 2006 17:06:20 +0300

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:[email-masked]] 
> Sent: 30 May, 2006 15:14
> To: Eric Rescorla
> Cc: [email-masked]
> Subject: [TLS] Empty ClientKeyExchange
> 
> Hi Eric and all,
>

---

From: Mohamad Badra <[email-masked]>
Date: Wed, 31 May 2006 15:04:38 +0200

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

---

From: <[email-masked]>
Date: Wed, 31 May 2006 19:10:03 +0300

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

> Sent: 31 May, 2006 16:05
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: [email-masked]
> Subject: Re: [TLS] Empty ClientKeyExchange
> 
> Dear Pasi,
> 
> 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.
> 
http://www.infres.enst.fr/~badra/draft-urien-badra-eap-tls-identity-prot
ection-00.txt

---

From: Mohamad Badra <[email-masked]>
Date: Wed, 31 May 2006 18:52:18 +0200

Hi Pasi,

> message always contains explicit Diffie-Hellman public value").

I agree. This is what I tried to say in my last mail.

> sessions by the same client.)

That's correcte. Identity protection must not be used in this case. But 
it can be used if the client and the server agree on using signed 
ephemeral Yc (DHE_RSA or DHE_DSS).

Best regards,
Badra