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

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 <foleyj@cisco.com> wrote:

> On 12/16/2015 04:28 PM, Dave Garrett wrote:
>
>> On Wednesday, December 16, 2015 04:15:00 pm John Foley 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.
>>>
>> 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.
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>