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

From: Noah Robbin <[email-masked]>
Date: Tue, 22 Aug 2017 17:50:49 +0000

Hello Todd!

I also did not see a reason why the random values had to be the same but the language does mandate it.  I see some of the TLS 1.3 clients using the same random and some are not.  There probably isn't anything that needs to be changed in the spec, but client implementers should be aware of the potential interoperability issue if the random is not maintained.

You make a good argument for not altering the padding on the second ClientHello.

-Noah

From: "Short, Todd" <[email-masked]>
Date: Tuesday, August 22, 2017 at 11:06 AM
To: Noah Robbin <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [EXT] Re: [TLS] What counts as the same ClientHello?

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:

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.

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.

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?

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.

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?

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<https://clicktime.symantec.com/a/1/Hc3vWWWdeHQWbzqwXFDoReORbWrEgS7Xj0-226UDvNw=?d=OIu0gj9PUnG5fI3n8fnkhJPbc19DwgMnL_YUuxaZyO3xNzKoVqoZQuDpD5ddEu4ud53efTYZcT8zPL2SsnvMSKvvZPO7oIzsMbsqjaOhUWx7tust2YI7I9PDIW087Ipk22jyZWE6NeD5QyWhGFa9PSIXVDdeNroJkNltupwF5dreaQDSHp-C0TIcEsEGSV4rRRjqZiTF5LbTmT3qtbE7dRXudBjGQodj0FpYp5VDf4Nw5ZquSotvxu91g-xhHu5pCAfacjPNpnRUOlHz7iNNFEAmm8TZV0rB6McVAEDYJYMU1I9pH2KtWdeoUuNIB1wA4VfpTArDB8PB9t4P6ebbukHqfwGkyN7iGdc4dJGrQDZDwKnEQ5G8cxW8-oASO9PiP6l4FSNt&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls>

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 22 Aug 2017 23:13:54 +0300

On Tue, Aug 22, 2017 at 05:50:49PM +0000, Noah Robbin wrote:
> Hello Todd!
> 
> I also did not see a reason why the random values had to be the same
> but the language does mandate it.  

I really do not think there is any technical or security reason why the
randoms have to be the same. After all, TLS 1.3 does not directly use
the randoms anywhere (they only affect things indirectly via hashes of
the handshake).

> You make a good argument for not altering the padding on the second

I read that argument as "TLS 1.3 implementations should not need
padding".

I took a look at struct ClientHello and the extensions list:

There are technical reasons for not altering (the client has no idea
what the heck server did with these):

- server_name
- max_fragment_length
- status_request
- signature_algorithms
- use_srtp
- heartbeat
- application_layer_protocol_negotiation
- signed_certificate_timestamp
- client_certificate_type
- server_certificate_type
- psk_key_exchange_modes (due to side-effects)
- certificate_authorities
- post_handshake_auth

The following are explicitly listed as to be altered/deleted:

- key_share 
- pre_shared_key
- early_data
- cookie

The following do not negotiate state:

- <random>
- padding

The following can't appear in ClientHello:

- oid_filters

The following client gains information about in HRR:

- <ciphersuites>
- supported_groups (partially if key_share was not present).
- supported_versions (the client knows what server selected).

However the last group seems to be kind of things that are rather
questionable to prune (might be okay, but those make me wary).

Also, I came accross one edge case: What if client discovers that all
tickets in pre_shared_key are incompatible? The definition does not
allow 0 tickets, so choices are:

1) Leave all the tickets (which is not going to work) in.
2) Leave one ticket (which is not going to work) in.
3) Strip the entiere extension.

-Ilari

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 29 Aug 2017 13:20:33 +0200

Hi Noah, Todd, Ilari,

the HRR is used for two purposes, namely
 * to report an error (with the key shares), and
 * for DoS protection.

In both cases it feels excessive to require that the two ClientHellos
are the same (with some minor exceptions). I see this as particularly
problematic for the use with DTLS since with connectionless transport
protocols the use of the HRR is obviously common and we are essentially
wasting bytes on the wire for no good reason(with every handshake).

For the return-routability check there will be a cookie in the HRR and
the RR check is useful primarily for connectionless transports.
Re-transmitting the same information twice in this case is of doubtful
value since (a) either the cookie contains the necessary info already or
(b) the second ClientHello carries the relevant information.

Does this make sense?

Ciao
Hannes

On 08/22/2017 10:13 PM, Ilari Liusvaara wrote:
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "Short, Todd" <[email-masked]>
Date: Tue, 29 Aug 2017 13:39:51 +0000

Hannes:

The ID indicates that the two ClientHellos must be identical except for the fields explicitly listed. If you strongly disagree, then you should request a change to the ID. I understand your opinions on the matter; but as written, the ID requires those fields extensions to be the same. Here is the text in question, emphasis mine:

4.1.2<https://tools.ietf.org/html/draft-ietf-tls-tls13-21#section-4.1.2>.  Client Hello

   When a client first connects to a server, it is REQUIRED to send the
   ClientHello as its first message.  The client will also send a
   ClientHello when the server has responded to its ClientHello with a
   HelloRetryRequest.  In that case, the client MUST send the same
   ClientHello (without modification) except:

   -  If a "key_share" extension was supplied in the HelloRetryRequest,
      replacing the list of shares with a list containing a single
      KeyShareEntry from the indicated group.

   -  Removing the "early_data" extension (Section 4.2.9<https://tools.ietf.org/html/draft-ietf-tls-tls13-21#section-4.2.9>) if one was
      present.  Early data is not permitted after HelloRetryRequest.

   -  Including a "cookie" extension if one was provided in the
      HelloRetryRequest.

   -  Updating the "pre_shared_key" extension if present by recomputing
      the "obfuscated_ticket_age" and binder values and (optionally)
      removing any PSKs which are incompatible with the server's
      indicated cipher suite.

To avoid DOS and maintenance of state, the server should not maintain any of this information (except, perhaps indirectly via the cookie) if an HRR is returned. Thus the ClientHello is sent with all the information provided again. Yes, it’s a slight waste of bandwidth, but I’d rather use bandwidth that fleets away like time (use it or lose it), than memory in my device. This also permits multiple methods of implementation of the initial connection if all the information is provided again.

On Aug 29, 2017, at 7:20 AM, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:

Hi Noah, Todd, Ilari,

Does this make sense?

Ciao
Hannes

You make a good argument for not altering the padding on the second
ClientHello.

- server_name
- max_fragment_length
- status_request
- signature_algorithms
- use_srtp
- heartbeat

- key_share
- pre_shared_key
- early_data
- cookie

- <random>
- padding

- oid_filters

- <ciphersuites>

-Ilari

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 29 Aug 2017 13:29:55 -0500

Hi Ilari,

Thanks for the by-extension categorization/breakdown.

> the randoms anywhere (they only affect things indirectly via hashes of

IIRC there was at some point talk of reconstructing the original
ClientHello based on the second one, but I guess we explicitly decided
to not allow that with https://github.com/tlswg/tls13-spec/pull/678 . 
So, I guess I am just saying that I agree.

> I read that argument as "TLS 1.3 implementations should not need

IIRC at least some of the need for padding was due to middleboxes, and I
don't have data on to what extent existing middleboxes choke on TLS 1.3
traffic.  (I believe others do have such data, though.)

> 3) Strip the entiere extension.

My conceptual preference would be for (3), though I have a hard time
convincing myself that the current text actually permits doing so. 
Maybe it's simplest to just add a short not about removing the extension
if no compatible PSKs are known.

-Ben

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 29 Aug 2017 12:02:48 -0700

On Tue, Aug 29, 2017 at 11:29 AM, Benjamin Kaduk <[email-masked]> wrote:

> ClientHello based on the second one, but I guess we explicitly decided to
> not allow that with https://github.com/tlswg/tls13-spec/pull/678 .  So, I
> guess I am just saying that I agree.
>

The padding isn't for middleboxes, it's for terminating endpoints.
 in favor of removing these restrictions.

> convincing myself that the current text actually permits doing so.  Maybe
> it's simplest to just add a short not about removing the extension if no
> compatible PSKs are known.
>

I think the current text says #1, which, AFAIK, doesn't cause any interop
problems, so I think we should just leave it as-is.

-Ekr

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 29 Aug 2017 14:40:56 -0500

On 08/29/2017 02:02 PM, Eric Rescorla wrote:
>
> On Tue, Aug 29, 2017 at 11:29 AM, Benjamin Kaduk <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Ilari,
>
>     ClientHello based on the second one, but I guess we explicitly
>     decided to not allow that with
>     https://github.com/tlswg/tls13-spec/pull/678
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls13-2Dspec_pull_678&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=tEEAaQnSyf8luhNnt4mugdNFY_rMiHCHzWFF1jtMyD0&s=RdeqGj8DPVrm2Hm2Axp5dGMSG2O_KHNc18Y7EPqiaio&e=>
>     .  So, I guess I am just saying that I agree.
>
>     IIRC at least some of the need for padding was due to middleboxes,
>     and I don't have data on to what extent existing middleboxes choke
>     on TLS 1.3 traffic.  (I believe others do have such data, though.)
>
>

No objection to removing the restriction from me.

>     My conceptual preference would be for (3), though I have a hard
>     time convincing myself that the current text actually permits
>     doing so.  Maybe it's simplest to just add a short not about
>     removing the extension if no compatible PSKs are known.
>
>
> I think the current text says #1, which, AFAIK, doesn't cause any
> interop problems, so I think we should just leave it as-is.
>

The editor's copy says the client can update the "pre_shared_key"
extension by removing any PSKs that are incompatible with the server's
indicated cipher suite, which is not exactly #1.

-Ben

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 29 Aug 2017 13:49:58 -0600

On Tue, Aug 29, 2017 at 1:40 PM, Benjamin Kaduk <[email-masked]> wrote:

>> not allow that with https://github.com/tlswg/tls13-spec/pull/678

That'll teach me not to go look at the spec before I talk. Sounds like we
should perhaps just remove that text and do #1, but I could also live with
#3.

-Ekr

---

From: Noah Robbin <[email-masked]>
Date: Tue, 29 Aug 2017 20:23:36 +0000

I want to bring up my original question on CH random values again.  The draft requires the two CH random values to be the same without a real reason for doing so.  Should we relax this requirement?

-Noah

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 29 Aug 2017 23:38:28 +0300

> No objection to removing the restriction from me.

Looking back at the list I posted, there are pretty few extensions that
are safe to alter or delete:

- key_share
- pre_shared_key
- early_data
- cookie
- <random> (not actually an extension)
- padding

The remaining extensions are either very much unsafe to alter due to
unknown commitments, or look potentially dangerous to security to alter
(with known commitments).
 
Hmm... Could pre_shared_key also belong to "potentially dangerous to
security to alter"? It is part of cipher negotiation after all, and
there is no bounding set, unlike with key_share.

The ClientHellos are tied together by handshake hash, which makes
attacks quite a lot more difficult, especially given that weak hashes
are unsafe for other reasons. Unfortunately, properly analyzing this is
way beyond my pay grade.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 29 Aug 2017 15:11:11 -0600

No, I don't think so. I don't see that it makes anyone's life significantly
easier too relax.

-Ekr

On Tue, Aug 29, 2017 at 2:23 PM, Noah Robbin <[email-masked]>
wrote:

> I want to bring up my original question on CH random values again.  The
> draft requires the two CH random values to be the same without a real
> reason for doing so.  Should we relax this requirement?
>
>
>
> -Noah
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 30 Aug 2017 15:57:34 +0300

> Thanks for the by-extension categorization/breakdown.

Sigh, I missed cached_info, because that does not appear in TLS 1.3
extension lists. It falls into "unsafe to alter because unknown
commitments" category.

However, I identified a new category of extensions that I didn't notice
before: Dependent on altered extensions. There are no such standardized
extensions, but there is at least one proposal (in WG draft stage).

The latter kind of extensions is incompatible with MUST be the same
except <list of extensions> requirement.

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Thu, 31 Aug 2017 09:50:07 +1000

> extensions, but there is at least one proposal (in WG draft stage).

Is it possible that you could help us by sharing which one?

I would however suggest that this sort of dependency is already
possible.  We have a few places in our code that checks certain
conditions after extension processing because of dependencies between
extensions.  In particular, the pre_shared_key and early_data
extensions trigger a lot of cross checking because they change the
protocol in fairly fundamental ways.