Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Issue644 remove hrr reconstruction #678

Merged
merged 3 commits into from
Oct 16, 2016
Merged

Issue644 remove hrr reconstruction #678

Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
d010e87
Don't append the new KeyShareEntry to ClientHello.key_shares. Fixes #…
ekr Oct 11, 2016
70b3f7b
Editorial
ekr Oct 11, 2016
49e6e44
Change alert, due to Martin Thomson
ekr Oct 16, 2016
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 11 additions & 13 deletions draft-ietf-tls-tls13.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -432,6 +432,7 @@ draft-17

- Add max_early_data_size field to TicketEarlyDataInfo (*)

- Replace Client.key_shares in response to HRR (*)

draft-16

Expand Down Expand Up @@ -1403,8 +1404,9 @@ 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:

- Including a new KeyShareEntry as the lowest priority share
(i.e., appended to the list of shares in the "key_share" extension).
- 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 ({{early-data-indication}}) if one was
present. Early data is not permitted after HelloRetryRequest.
Expand Down Expand Up @@ -1645,12 +1647,13 @@ HelloRetryRequest MUST NOT contain any extensions that were not first
offered by the client in its ClientHello, with the exception of optionally the
"cookie" (see {{cookie}}) extension.

Upon receipt of a HelloRetryRequest, the client MUST verify that the extensions
block is not empty and otherwise MUST abort the handshake with a
"decode_error" alert. Clients SHOULD also abort the handshake with an
"unexpected_message" alert in
response to any second HelloRetryRequest which was sent in the same connection
(i.e., where the ClientHello was itself in response to a HelloRetryRequest).
Upon receipt of a HelloRetryRequest, the client MUST verify that the
extensions block is not empty and otherwise MUST abort the handshake
with a "decode_error" alert. Clients SHOULD abort the handshake with
an "unexpected message" if the HelloRetryRequest would not result in
any change in the ClientHello or in response to any second
HelloRetryRequest which was sent in the same connection (i.e., where
the ClientHello was itself in response to a HelloRetryRequest).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So the thing to note here is that HRR can't include extensions that you don't agree should be there. So, if extensions are present, then they have to be ones that change the ClientHello (we shouldn't define any that don't). That means the only way for HRR to be wrong is:

  • no extensions (decode_error)
  • unknown extension (unsupported_extension)
  • extension doesn't cause a change, for instance key_share uses an unknown group, or one that already had a share

In the last case, I chose to make this an illegal_parameter alert.

And yes, if you receive a second HRR, then unexpected_message is correct (note that you missed the underscore there).

I chose to send illegal_parameter


Otherwise, the client MUST process all extensions in the HelloRetryRequest and
send a second updated ClientHello. The HelloRetryRequest extensions defined in
Expand All @@ -1660,11 +1663,6 @@ this specification are:

- key_share (see {{key-share}})

Note that HelloRetryRequest extensions are defined such that the original
ClientHello may be computed from the new one, given minimal state about which
HelloRetryRequest extensions were sent. For example, the key_share extension
causes the new KeyShareEntry to be appended to the client_shares field, rather
than replacing it.

## Hello Extensions

Expand Down