Subject: [ietf-tls] Some questions about tls handshake

From: "imran badr" <[email-masked]>
Date: Wed, 18 Jul 2001 13:42:54 -0700

Hi,

I am studying TLS1.0. I have some questions about handshake, rehandshake,
session resumption etc. I looked at many resources (rfc, books, internet
links) but couldn't find answer to the following questions. I apologize to
interrupt everyone with this mesage but unfortunately I couldn't thought of
any other way than to ask for help from the ietf woking group. I will be
grateful if anyone helps.

* On a TLS session resumption, partial handshake hashes doesnot include the
handshake messages from the prior full handshake. Is that true?

* Suppose that a renegotiation/rehandshake occurs after a full handshake.
Does the handshake hash for the renegotiation/rehandshake have to include
the handshake messages of the prior full handshake?

* What if another renegotiation/rehandshake occurs? Does the handshake hash
include both the prior full handshake and renegotiation/rehandshake?

* Same question when a renegotiation/rehandshake occurs after a resume. Does
the renegotiation/rehandshake then include the handshake messages from the
prior resume? What if another one happens?

Thanks,
Imran Badr.

---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: 18 Jul 2001 14:01:27 -0700

> handshake messages from the prior full handshake. Is that true?
Correct. The handshake hashes for any given handshake only include
the data from that handshake.

> the handshake messages of the prior full handshake?
No.

> include both the prior full handshake and renegotiation/rehandshake?
No.

> prior resume? What if another one happens?
No.

-Ekr

---

---

From: "Rene G. Eberhard" <[email-masked]>
Date: Wed, 18 Jul 2001 23:11:11 +0200

> handshake messages from the prior full handshake. Is that true?

Yes. 

> the handshake messages of the prior full handshake?

No. Renegotiation is similar (equal) to a full (new) handshake.

> include both the prior full handshake and renegotiation/rehandshake?

No, just the handshake messages of the current (latest) renegotiation.

> prior resume? What if another one happens?

No. Just hash everything from the client hello up to (but not
including) the finished message. (See also RFC 2246 7.4.9. Finished)

Regards Rene

--
Rene G. Eberhard <[email-masked]>
keyon > the PKI experts
Herrenberg 35, CH-8640 Rapperswil, Switzerland
Phone +41 (0)55 220 71 63, Fax +41 (0)55 220 71 61
See www.keyon.ch, www.tess.ch and www.freecerts.com

---

---

From: "David Taylor" <[email-masked]>
Date: Thu, 19 Jul 2001 18:58:09 +1000

> prior resume? What if another one happens?

As Eric said, no in all cases. Something else to note is that the mechanism
for reusing session information for a new connection and renegotiating the
keys in use on an existing connection (resumption and
renegotiation/rehandshake) are exactly the same mechanism.

Regards,
David Taylor.

---

---

From: "imran badr" <[email-masked]>
Date: Thu, 19 Jul 2001 13:20:50 -0700

Thanks for all your resplies.

It looks like that there is no need to include server finish ( on a server )
in the partial handshake hashes and to remember the states of SHA1 and MD5
handshake hashes once you have sent out server finish. But some
implementations like openSSL include server finish to handshake hashes
although there is no protocol requiremenet to do so. Is that right? Does
these rules apply to SSL3.0 also?

Best regards,
Imran Badr.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of David
Taylor
Sent: Thursday, July 19, 2001 1:58 AM
To: IETF Transport Layer Security WG
Subject: [ietf-tls] Re: Some questions about tls handshake

Regards,
David Taylor.

---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to
[email-masked]

---

---

From: Eric Rescorla <[email-masked]>
Date: 19 Jul 2001 13:37:21 -0700

> these rules apply to SSL3.0 also?
In normal mode the client's Finished message must be included in
a handshake hash but the server's Finished is not. In resumed
mode the server's Finished message gets hashed and the client's does
not.

However, as a matter of programming convenience, some implementations
might simply choose to digest all the handshake messages--even though
the digest may be thrown away without being used. E.g. rather than
having:
	if(certain conditions){
	 hash_update(message);
	}

one just does:
	 hash_update(message);

Note that even if an implementation behaves in this way the data that
it transmits will remain the same.

As far as this goes, SSLv3 has the same semantics as TLS.

-Ekr

---