Subject: [TLS] Master Secret Computation

From: "Jim Schaad" <[email-masked]>
Date: Mon, 1 Sep 2014 16:18:58 -0700

This message applies to both the 1.3 TLS document and to the session hash
document.

I have not ever implemented TLS, so I have been spending some time reading
the documents to try and figure out how things are going to work.  Based on
mail see, I have assumed that 1.3 is going to adopt the extended hash
computation for the master secret and have created my table based on this.
(If this is not the case then I think it needs to be argued.)

As part of putting together the attacked picture, I read a number of
different TLS documents which are not part of the core spec.  It is possible
that some of these are no longer needed and should be ruled out as possible
extensions to the TLS 1.3 document, but would be relevant to the extension
for the 1.2 (and prior) documents.

Notes on the picture that I have included:

Items tagged with [1] are sent only in the event that the server does not
want to have a client certificate.
Items tagged with [2] are sent only in the event that the a) there is a
client certificate or b) the new session ticket extension is being used.
Items tagged with [3] are sent in the event that a restart is made because
of a mismatch of key agree groups.

I am not clear if the use of the Supplemental Data extension means that the
server Finish message cannot be sent before receiving the response from the
client.
The new session ticket extension requires that the client finish message be
validated before it can be sent to the client, thus it falls into the [2]
grouping.

The green means that the handshake message is part of the hash computation.
The yellow means that it would be part of the computation for [2] but not
for [1].  The "pink" is part of my assumption that a the hashing should
include the failed early handshake message.

The current hashing document says that the hash would not include the
CertificateVerify message (for the client).  I am assuming that this is
because there is a large presumption that the hash that is used for the PRF
function and the hash that the client would use in computing the
CertificateVerify message is going to same.  This presumption should
probably be documented. 

I am unsure what the correct behavior should be in the event that the
SupplementalData extension is used, but the client certificate message is
not used.  Should this be part of the master secret hash or not?

In looking at the sequence, doing a re-negotiation would seem to have a bad
property of going from the cipher suite which uses the hash of the handshake
to one that just uses the keys and the randoms part way through the
re-negotiation process.  This means that any application data sent between
the first and the second change_cipher_suite messages would potentially not
be as well protected.  This could be fixed by not having the first pair of
change_cipher_suite messages in the event of a re-negotiation as there is no
need to go from a NULL_NULL cipher suite to one which has encryption. 

Jim

---

From: Alfredo Pironti <[email-masked]>
Date: Wed, 3 Sep 2014 10:44:46 +0200

> CertificateVerify message is going to same.  This presumption should

The hash used for signature and the one used for the PRF can indeed be
different.
The reason why we left CertificateVerify out from the session_hash is that
the master_secret computation depends on session_hash. In turn, in SSL 3.0,
the computation of CertificateVerify depends on the master_secret.
This could be relaxed for later TLS versions, where the master_secret is
not used in the computation of the CertificateVerify message. However,
since CertificateVerify does not alter the state of the session, we left it
out for all TLS versions, to ease implementation of the extension.
This choice is documented in the implementation note of section 3 of the
current session-hash draft. But if the text doesn't read clear enough, we
can try to improve it.

> need to go from a NULL_NULL cipher suite to one which has encryption.

As discussed in the session-hash call for adoption thread [1], the
session-hash extension is mainly intended as a fix for TLS <= 1.2; whereas
the fix should be an integral part of TLS 1.3 (and how this is precisely
achieved is still under design).

Best,
Alfredo

[1] http://www.ietf.org/mail-archive/web/tls/current/msg13173.html

>
>
> Jim
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 9 Sep 2014 19:18:48 -0700

As I said in my message, I believe that these issues apply both the TLS 1.3 document and to the session hash document.  The questions that I would have for the session hash document are:

1.        Why is there not a justification of stopping the hash before the CertVerify handshake message rather than before the Finish message which is more logical.

2.       From the table that I included:  Does the use of the CertificateURL message cause a problem which has not been looked at.  Since this may not include any client specific data (the client certificate is not sent), we are not back into a situation where the client identity and identity key are not included as part of the computation for the master secret.   I can’t find it on a fast scan, but I believe that you have stated that hashing the client identity into the handshake messages is of importance.  This would appear to argue for hashing the CertificateVerify handshake message since it would be a unique value for the client and associated with the client certificate in this case.  (Another way would be to hash in the result of getting the certificate from the URL but that is probably not desirable.)

3.       I don’t believe that there are any implications that come from the use of the Supplemental Data and New Session Ticket handshake messages, however it would be good to state that this is the case.  I would note that in the case of the New Session Ticket messages, the one sent from the server to the client can occur only after the client finish message has been received so it cannot be part of the context used to build the master secret.

Jim

From: Alfredo Pironti [mailto:[email-masked]] 
Sent: Wednesday, September 03, 2014 1:45 AM
To: Jim Schaad
Cc: [email-masked]
Subject: Re: [TLS] Master Secret Computation

The hash used for signature and the one used for the PRF can indeed be different.
The reason why we left CertificateVerify out from the session_hash is that the master_secret computation depends on session_hash. In turn, in SSL 3.0, the computation of CertificateVerify depends on the master_secret.
This could be relaxed for later TLS versions, where the master_secret is not used in the computation of the CertificateVerify message. However, since CertificateVerify does not alter the state of the session, we left it out for all TLS versions, to ease implementation of the extension.
This choice is documented in the implementation note of section 3 of the current session-hash draft. But if the text doesn't read clear enough, we can try to improve it.

As discussed in the session-hash call for adoption thread [1], the session-hash extension is mainly intended as a fix for TLS <= 1.2; whereas the fix should be an integral part of TLS 1.3 (and how this is precisely achieved is still under design).

Best,
Alfredo

Jim

---

From: Alfredo Pironti <[email-masked]>
Date: Thu, 18 Sep 2014 11:35:09 +0200

On Wed, Sep 10, 2014 at 4:18 AM, Jim Schaad <[email-masked]> wrote:

> As I said in my message, I believe that these issues apply both the TLS
> 1.3 document and to the session hash document.  The questions that I would
> have for the session hash document are:
>
>
>
> 1.        Why is there not a justification of stopping the hash before
> the CertVerify handshake message rather than before the Finish message
> which is more logical.
>
I believe the justification is given at [1] "Implementation note":
paragraph.

[1] http://tools.ietf.org/html/draft-ietf-tls-session-hash-01#section-3

> 2.       From the table that I included:  Does the use of the
> CertificateURL message cause a problem which has not been looked at.  Since
> this may not include any client specific data (the client certificate is
> not sent), we are not back into a situation where the client identity and
> identity key are not included as part of the computation for the master
> secret.   I can’t find it on a fast scan, but I believe that you have
> stated that hashing the client identity into the handshake messages is of
> importance.  This would appear to argue for hashing the CertificateVerify
> handshake message since it would be a unique value for the client and
> associated with the client certificate in this case.  (Another way would be
> to hash in the result of getting the certificate from the URL but that is
> probably not desirable.)
>
The table is not TLS <= 1.2. In general, the session hash captures the
information that contributes to the session; TLS 1.3 has a different
handshake flow, and I expect an updated definition of the session hash.
Regarding URLs instead of certificates, this is an orthogonal problem: TLS
provides handshake integrity, the integrity of the certificate retrieval
seems out of scope (although security relevant).

> 3.       I don’t believe that there are any implications that come from
> the use of the Supplemental Data and New Session Ticket handshake messages,
> however it would be good to state that this is the case.  I would note that
> in the case of the New Session Ticket messages, the one sent from the
> server to the client can occur only after the client finish message has
> been received so it cannot be part of the context used to build the master
> secret.
>

This is true for any data sent after the session hash is computed: they
must not alter the state of the session.

Alfredo

>
>
> Jim
>
>
>
>
>
> *From:* Alfredo Pironti [mailto:[email-masked]]
> *Sent:* Wednesday, September 03, 2014 1:45 AM
> *To:* Jim Schaad
> *Cc:* [email-masked]
> *Subject:* Re: [TLS] Master Secret Computation
>
>
>
>
>
>
>