Re: [TLS] Master Secret Computation

[Alfredo Pironti <[e-mail]>]

On Wed, Sep 10, 2014 at 4:18 AM, Jim Schaad <[e-mail]> 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:[e-mail]]
> *Sent:* Wednesday, September 03, 2014 1:45 AM
> *To:* Jim Schaad
> *Cc:* [e-mail]
> *Subject:* Re: [TLS] Master Secret Computation
>
>
>
>
>
>
>
> On Tue, Sep 2, 2014 at 1:18 AM, Jim Schaad <[e-mail]> wrote:
>
> 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.
>
>
>
> 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.
>
>
>
>
> 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.
>
>
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>
>