Subject: [TLS] Verifying the second HelloRequest in TLS 1.3

From: Kazuho Oku <[email-masked]>
Date: Fri, 18 Nov 2016 18:19:30 +0900

Hi,

In section 4.1.2, the latest draft (18) states that a ClientHello sent in
response to a HelloRetryRequest must be identical to the first one except
for addition, modification, and removal of the designated extensions.

To be precise, the draft states:

   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.8) if one was
      present.  Early data is not permitted after HelloRetryRequest.

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

Does this mean that the ClientHello must be at the octet-level be
equivalent (with the exception for the positions at which the necessary
extensions are inserted)?

Or does this mean that a semantically equivalent ClientHello must be
accepted? If this is the case, it would mean that a client is allowed to
exchange the order of the extensions within ClientHello. There could be
other ways to construct an semantically identical ClientHello that looks
different at byte level.

I think the latest draft can be interpreted in either way (please correct
me if I am wrong), and would like to learn what the answer would be.

Thank you in advance.

-- 
Kazuho Oku