Subject: [TLS] Explicit use of client and server random values

From: John Foley <[email-masked]>
Date: Wed, 16 Dec 2015 11:12:42 -0500

I apologize if this topic was previously discussed, I've only recently 
joined the TLS mailer list.  While reviewing the TLS 1.3 draft (revision 
10), section 7 begins with the following wording:

    In order to begin connection protection, the TLS Record Protocol
    requires specification of a suite of algorithms, a master secret, and
    the client and server random values.

However, when reading through all of section 7, there appears to be no 
explicit use for the client and server random values.  While these 
values would be used implicitly when the handshake messages are hashed, 
and thus have bearing on the key schedule calculation, there appears to 
be no explicit use of the client and server random values similar to 
section 6.3 in the TLS 1.2 spec.

Am I interpreting this properly?  If the client and server random values 
are no longer explicitly used in any key derivation logic, maybe this 
should be noted in section 6.3.1, as implementors will no longer need to 
parse these values when processing incoming messages.  Additionally, the 
intro to section 7 is misleading to implementors, as it implies the 
client and server random values are needed to derive the key schedule.

The following issue and PR appear to be related to my question:

https://github.com/tlswg/tls13-spec/issues/185
https://github.com/tlswg/tls13-spec/pull/189

---

From: Dave Garrett <[email-masked]>
Date: Wed, 16 Dec 2015 15:30:05 -0500

On Wednesday, December 16, 2015 11:12:42 am John Foley wrote:
> Am I interpreting this properly?

Yes, with the exception of the new downgrade protection mechanism that rides in the server random (in draft11 WIP), randoms are used implicitly via the handshake hash.

> If the client and server random values 

There's still a lot of stuff with "TODO" notes on it in there that needs revision with regard to this. In particular, SecurityParameters still contains the randoms as well as the old master secret. I agree that this needs explicit explanation.

> https://github.com/tlswg/tls13-spec/pull/189

Not really. The issue there was a suggestion to regen the randoms on retry request. Yes, it touches the randoms, but it's a tangential issue. In any case, the idea in question has been shelved.

Dave

PS
When referencing sections in the draft, please do so not just by number. Those can change as sections change. I suggest linking to one of the numbered drafts and citing its section, where possible. 6.3.1 is already different between draft10 and the current draft11 WIP.

---

From: John Foley <[email-masked]>
Date: Wed, 16 Dec 2015 16:15:00 -0500

On 12/16/2015 03:30 PM, Dave Garrett wrote:
> .
Thanks for answering my questions.  Have you considered adding KAT 
values for the key derivation steps?  This would be helpful to 
implementors.  RFC5869 already has KAT values for HKDF-Extract and 
HKDF-Expand.  But the TLS 1.3 spec has added HKDF-Expland-Label. 
Additionally, It would be useful to show intermediate KAT values for 
xSS, xES, mSS, and mES.

---

From: Dave Garrett <[email-masked]>
Date: Wed, 16 Dec 2015 16:28:02 -0500

> Additionally, It would be useful to show intermediate KAT values for 

I suggest filing an issue or submitting a PR with a starting point set of changes and discussing it with ekr.

Dave

---

From: John Foley <[email-masked]>
Date: Thu, 17 Dec 2015 10:13:49 -0500

> I suggest filing an issue or submitting a PR with a starting point set of changes and discussing it with ekr.

I've submitted https://github.com/tlswg/tls13-spec/issues/378.  If you 
give me a few days, I'll update this issue with KAT values per revision 
10.  Since it sounds like there are changes forthcoming in this section 
of the draft, I'll hold off on the PR until later. Hopefully someone 
else will volunteer to verify my KAT values.

---

From: Hugo Krawczyk <[email-masked]>
Date: Thu, 17 Dec 2015 15:02:44 -0500

I have mentioned this in private conversations but let me say this here: I
would prefer that the nonces be explicitly concatenated to the handshake
hash.  That is,

handshake_hash = Hash(

                            client random            ||

                            server random            ||

                            Hash(handshake_messages) ||

Hash(configuration) || )

The reason is that nonces are essential for freshness and session
uniqueness and I want to see them explicitly included in the
signed/mac-ed/KDF-ed information. I can envision a future variant/mode of
the protocol where parties do not transmit nonces but have a synchronized
state that they advance separately and use as nonces (e.g., for key
refreshing) - in such case the nonces would not be included in the
handshake-hash computation.

So while the redundancy of having them twice in the handshake_hash
calculation may be annoying, this adds robustness to the security (and
analysis) of the protocol.

Another reason for including them (in particular as the leading values) in
the computation of handshake_hash is to have them always located at the
same position in the hashed stream. It is needed to make sure that these
streams are unique per session (in theory, and maybe in practice, an
attacker may play games changing the boundary of nonces by changing
surrounding bytes in the stream).

If this augmenting of handshake_hash is not adopted then there should be a
note cautioning against excluding the nonces from the transmitted messages.
If possible, it would be good to move them to a fixed position (from the
start of the input to the handshake_hash).

Hugo

On Thu, Dec 17, 2015 at 10:13 AM, John Foley <[email-masked]> wrote:

> 10.  Since it sounds like there are changes forthcoming in this section of
> the draft, I'll hold off on the PR until later. Hopefully someone else will
> volunteer to verify my KAT values.
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 17 Dec 2015 15:11:15 -0500

> analysis) of the protocol.

This change doesn't make implementation or specification significantly more
difficult.
Does anyone  else object or feel it makes analysis harder? :)

-Ekr

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 17 Dec 2015 20:13:44 +0000

> Does anyone  else object or feel it makes analysis harder? :)

Oh yeah, like anyone's gonna disagree with Hugo that this makes the analysis harder :)

Paging Watson ... :)

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Thu, 17 Dec 2015 20:44:49 +0000

> On Thu, Dec 17, 2015 at 3:02 PM, Hugo Krawczyk <[email-masked]> wrote:
>> hash….

Let’s do it.

> Does anyone  else object or feel it makes analysis harder? :)

:-)

---

From: Mike Hamburg <[email-masked]>
Date: Thu, 17 Dec 2015 14:33:11 -0800

> On Dec 17, 2015, at 12:11 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Thu, Dec 17, 2015 at 3:02 PM, Hugo Krawczyk <[email-masked] <mailto:[email-masked]>> wrote:
> I have mentioned this in private conversations but let me say this here: I would prefer that the nonces be explicitly concatenated to the handshake hash.  That is, 
> 
> handshake_hash = Hash(
>                             client random            ||
>                             server random            ||
>                             Hash(configuration)      ||
>                            )
> The reason is that nonces are essential for freshness and session uniqueness and I want to see them explicitly included in the signed/mac-ed/KDF-ed information. I can envision a future variant/mode of the protocol where parties do not transmit nonces but have a synchronized state that they advance separately and use as nonces (e.g., for key refreshing) - in such case the nonces would not be included in the handshake-hash computation.
> 
> So while the redundancy of having them twice in the handshake_hash calculation may be annoying, this adds robustness to the security (and analysis) of the protocol.
>  
> This change doesn't make implementation or specification significantly more difficult.

While I haven’t been following TLS 1.3 development all that closely, I will question this request.

TLS is annoying to implement and analyze in part because it hashes more-or-less arbitrary parts of the handshake messages together, in arbitrary order, at arbitrary times.  Removal of all the explicit hashing of client/server random in TLS 1.3 makes it clearer what’s going on, and makes implementations simpler.  Some of the crypto operations still feel pretty arbitrary (particularly Finished), but things seem to be improving overall.  In this context, it feels like adding client random and server random back to the hash is a regression.

From an analysis point of view, the client and server random are parseable from Hash(handshake messages) because they are concatenated with framing information.  But here, they are concatenated without framing information.  So I don’t understand Hugo’s contention that the old scheme leads to trouble if the nonce changes sizes in a later version, and that the new scheme does not.  It seems to me that the reverse is more likely to be true.

Cheers,
— Mike

---

From: Hugo Krawczyk <[email-masked]>
Date: Fri, 18 Dec 2015 00:39:54 -0500

On Thu, Dec 17, 2015 at 5:33 PM, Mike Hamburg <[email-masked]> wrote:

>> I have mentioned this in private conversations but let me say this here:
>> I would prefer that the nonces be explicitly concatenated to the handshake
>> hash.  That is,
>>
>> handshake_hash = Hash(
>>
>>                             client random            ||
>>
>>                             server random            ||
>>
> TLS is annoying to implement and analyze in part because it hashes
> more-or-less arbitrary parts of the handshake messages together, in
> arbitrary order, at arbitrary times.  Removal of all the explicit hashing
> of client/server random in TLS 1.3 makes it clearer what’s going on, and
> makes implementations simpler.
>

​How does removal of explicit hashing of the nonces make things clearer?
What are the things that are made clearer?

​

>  Some of the crypto operations still feel pretty arbitrary (particularly
> Finished), but things seem to be improving overall.  In this context, it
> feels like
> ​​
> adding client random and server random back to the hash is a regression.
>

​What do you mean by ​

​"
​
 adding client random and server random back to the hash is a regression
​"?
Why "back"? Were they removed? What's the regression?
You are probably not suggesting to omit them, right? Are you worried about
the redundancy of being hashed twice? Is it a security issue or an
implementation issue?
​
.​

>
> From an analysis point of view, the client and server random are parseable
> from Hash(handshake messages) because they are concatenated with framing
> information.
>

​They are parseable, but I am not sure they are *uniquely* parseable - a
fixed location in the stream does make them uniquely parseable.

​

>  But here, they are concatenated without framing information.
>

​The nonces are the main framing information - they are the (honest
parties') unique identifier of the handshake.

​

> So I don’t understand Hugo’s contention that the old scheme leads to
> trouble if the nonce changes sizes in a later version, and that the new
> scheme does not.  It seems to me that the reverse is more likely to be true.
>

​I'm clearly not following your argument.

​Hugo
​

---

From: Mike Hamburg <[email-masked]>
Date: Fri, 18 Dec 2015 12:55:45 -0800

Whoops, big-R to reply all...

> On Dec 17, 2015, at 9:39 PM, Hugo Krawczyk <[email-masked]> wrote:
> 
> 
> On Thu, Dec 17, 2015 at 5:33 PM, Mike Hamburg <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On Dec 17, 2015, at 12:11 PM, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> 
> TLS is annoying to implement and analyze in part because it hashes more-or-less arbitrary parts of the handshake messages together, in arbitrary order, at arbitrary times.  Removal of all the explicit hashing of client/server random in TLS 1.3 makes it clearer what’s going on, and makes implementations simpler. 
> 
> ​How does removal of explicit hashing of the nonces make things clearer? What are the things that are made clearer?
> 
> ​ 
>  Some of the crypto operations still feel pretty arbitrary (particularly Finished), but things seem to be improving overall.  In this context, it feels like​​ adding client random and server random back to the hash is a regression.
> 
> ​What do you mean by ​ ​"​ adding client random and server random back to the hash is a regression​"?
> You are probably not suggesting to omit them, right? Are you worried about the redundancy of being hashed twice? Is it a security issue or an implementation issue?
> ​.​
> 
> From an analysis point of view, the client and server random are parseable from Hash(handshake messages) because they are concatenated with framing information.
> 
> ​They are parseable, but I am not sure they are *uniquely* parseable - a fixed location in the stream does make them uniquely parseable.
> 
> ​ 
> ​The nonces are the main framing information - they are the (honest parties') unique identifier of the handshake.
> 
> ​ 
> So I don’t understand Hugo’s contention that the old scheme leads to trouble if the nonce changes sizes in a later version, and that the new scheme does not.  It seems to me that the reverse is more likely to be true.
> 

Sorry Hugo, I misread the proposal as using the nonces and handshake hash when signing, but not elsewhere.  On rereading, it is still entirely consistent, and isn’t being added “back” anywhere, except perhaps to some memory structure in the handshake code.  It also definitely isn’t a security problem, and it isn’t as annoying for implementations as I had figured (but it does require extra memory, which I had hoped to see removed).

However, I’m somewhat confused about your statement that the framing information is the honest parties’ unique identifier of the handshake.  I had thought that TLS 1.3 was going to a model where the handshake trace (and configuration, for 0-RTT) was the real session identifier, and the nonces were there exclusively to make that trace unique.  This is a huge improvement from TLS 1.2, where the session identifier is sometimes the nonces and sometimes the trace and sometimes something in between (Server Certificate Verify eg).  It further means that future versions could drop the nonces entirely if they require one-use ephemeral key exchange.  It seems that you’re suggesting that the session identifier is the tuple (nonces, trace, configuration), which seems redundant to me.  Perhaps it is required by the security model (eCK?) to have a stable session identifier?

I’m concerned about parseability in two ways.  One, if the nonces ever change size in future versions, or are omitted due to required one-use ephemeral key exchange, then we will have to change how handshake_hash is calculated, and we will have to make sure that it cannot cause problems due to collisions with the current handshake_hash calculation.

Two, if the handshake messages fed into the hash function are not uniquely parseable, that’s going to be a serious problem for analyzing TLS 1.3, and should be a top priority to fix.

Cheers,
— Mike

---

From: Hugo Krawczyk <[email-masked]>
Date: Fri, 18 Dec 2015 19:02:29 -0500

On Fri, Dec 18, 2015 at 3:55 PM, Mike Hamburg <[email-masked]> wrote:

>> From an analysis point of view, the client and server random are
>> parseable from Hash(handshake messages) because they are concatenated with
>> framing information.
>>
>
> Sorry Hugo, I misread the proposal as using the nonces and handshake hash
> when signing, but not elsewhere.  On rereading, it is still entirely
> consistent, and isn’t being added “back” anywhere, except perhaps to some
> memory structure in the handshake code.  It also definitely isn’t a
> security problem, and it isn’t as annoying for implementations as I had
> figured (but it does require extra memory, which I had hoped to see
> removed).
>
> However, I’m somewhat confused about your statement that the framing
> information is the honest parties’ unique identifier of the handshake.  I
> had thought that TLS 1.3 was going to a model where the handshake trace
> (and configuration, for 0-RTT) was the real session identifier, and the
> nonces were there exclusively to make that trace unique.
>

In analysis we build on unique session identifiers which can be defined in
different ways but need always be part of the authenticated information
(sometimes, authentication can be implicit, i.e. non-explicit, by making
this information part of the input to the KDF).
When parties share state, state information may be used as part of the
unique session identifier. If this part is not transmitted and you only
authenticate information that went over the wire you may be missing
important inputs to authentication/KDF.
​I cannot predict all ways people can eventually construct logical session
identifiers but I can hope that these will always include session-specific
nonces, hence I want to make sure that they get included in the
authentication inputs (which in TLS 1.3 is governed by the handshake_hash).​
Of course, nonces by themselves are often not sufficient as session
identifiers but they are an essential piece [0].

 ​

>  This is a huge improvement from TLS 1.2, where the session identifier is
> sometimes the nonces and sometimes the trace and sometimes something in
> between (Server Certificate Verify eg).  It further means that future
> versions could drop the nonces entirely if they require one-use ephemeral
> key exchange.
>

​See [0]
​

>  It seems that you’re suggesting that the session identifier is the tuple
> (nonces, trace, configuration), which seems redundant to me.  Perhaps it is
> required by the security model (eCK?) to have a stable session identifier?
>

​I believe that any security model will need a unique way to refer to a
session and bind information to it.
​

>
> I’m concerned about parseability in two ways.  One, if the nonces ever
> change size in future versions, or are omitted due to required one-use
> ephemeral key exchange, then we will have to change how handshake_hash is
> calculated, and we will have to make sure that it cannot cause problems due
> to collisions with the current handshake_hash calculation.
>
> Two, if the handshake messages fed into the hash function are not uniquely
> parseable, that’s going to be a serious problem for analyzing TLS 1.3, and
> should be a top priority to fix.
>

​I, too, assume that non-unique parseability can create all kind of
problems. But I can also see parseability rules changing in protocol
variants/derivatives. The "insurance"​

​ in the form of prepended nonces does not seem to be too much of a burden.
But as I said in my initial posting, if this is considered a burden from
implementation point of view (or for any other reason) then it is not a
tragedy to keep it as currently defined but a note on the necessity of
transmitting nonces, as well as their unique parsing, should be included.

Hugo

[0] You mention the possibility of nonces being redundant in some cases,
e.g. when you send fresh DH values in each session for forward secrecy and
use these values in lieu of nonces (or as part of the naming of your
session). To me this is a good example of things people should NOT be
doing. For example, even if you specify that DH values MUST not be used
twice, there is no way to enforce that and someone (or a new
protocol/application) can decide that re-using a DH value for one minute
gives good enough forward secrecy. In many cases I would agree with that.
But then, if you also built on the DH values as nonces, then that decision
just broke your security.
Conclusion: Always use dedicated nonces for ensuring uniquenes of session
identifiers and session binding for authentication.
​