Subject: [TLS] What counts as the same ClientHello?

From: Noah Robbin <[email-masked]>
Date: Tue, 22 Aug 2017 14:16:16 +0000

Section 4.1.2 of the TLS 1.3 draft RFC specifies that the ClientHello sent in response to a HelloRetryRequest “MUST be the same (without modification) except” for a list of specific exceptions.  I have found one server that verifies that the random in the first ClientHello is the same as the random in the second ClientHello.  I have also found servers that accept the second ClientHello with a different random.  Many clients are sending a different random in the second ClientHello.
My reading of the specification is that the random must be the same, but if there are clients and servers taking different postures on this we will run into interop issues.
I also have two additional questions.
1 - The changes to key_share, early_data, and pre_shared_key extensions, and the addition of the cookie extension may change the overall length of the ClientHello such that it is now in the 256-511 range that some implementations have issues with.  Is it permissible to alter the padding extension?
2 -  The MUST language means that the order of the extensions must remain the same.  How strictly should a server enforce this and does this create a requirement for where the cookie extension should be inserted into the list?

Thank you,
Noah Robbin

---

From: "Short, Todd" <[email-masked]>
Date: Tue, 22 Aug 2017 15:06:28 +0000

Hi Noah!

See below…

--
-Todd Short
// [email-masked]<mailto:[email-masked]>
// "One if by land, two if by sea, three if by the Internet."

On Aug 22, 2017, at 10:16 AM, Noah Robbin <[email-masked]<mailto:[email-masked]>> wrote:

Based on the reading, the ClientRandom must be identical in both ClientHellos, although I do not see a reason that they need to be the same. It is likely that the server does not keep the original ClientHello around for comparison. More than likely the server generates a hash of the ClientHello and stuffs it into the cookie extension.

IMHO, this should not matter with TLSv1.3. Those older, broken, implementations would not support TLSv1.3, and subsequently will not send back a HelloRetryRequest. I would hope that those older, broken implementations would be updated to fix their issue with ClientHello length when they upgrade to TLSv1.3.

The logical choice would be to append it to the end, so as to not change the order of the other extensions. But the pre-shared key must be last. So, never mind.

OpenSSL inserts the cookie after the key share, but before certificate authorities, basically the same place as the early data extension (which has to be removed), which would also be a logical choice.

Again, I don’t think that a server would keep an older ClientHello around, and would instead store the state in the Cookie extension (see section 4.2.2, second reason).

Thank you,
Noah Robbin

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 22 Aug 2017 20:10:26 +0300

On Tue, Aug 22, 2017 at 02:16:16PM +0000, Noah Robbin wrote:
> Section 4.1.2 of the TLS 1.3 draft RFC specifies that the ClientHello
> sent in response to a HelloRetryRequest “MUST be the same (without
> modification) except” for a list of specific exceptions.  I have
> found one server that verifies that the random in the first
> ClientHello is the same as the random in the second ClientHello.  I
> have also found servers that accept the second ClientHello with a
> different random.  Many clients are sending a different random in the
> second ClientHello.

The actual reason for this requirement appears to be that the server
might have committed several decisions that it can't back off of (e.g.,
ALPN), and which are not apparent in HelloRetryRequest.

The implementation I have written indeed does this sort of commitment
with every parameter that is actually used (but not ClientRandom,
because it isn't actually used in TLS 1.3). In fact, it does not even
check if the decisions are consistent with the new Client Hello (only
that the needed key share is present).

-Ilari