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
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
