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

Clarify how to negotiate groups if you want to respect the client order. #1331

Merged
merged 4 commits into from
Nov 29, 2023
Merged

Clarify how to negotiate groups if you want to respect the client order. #1331

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
e956efe
Clarify how to negotiate groups to address the issue raised by
ekr Nov 11, 2023
919066c
Fix capitalization
ekr Nov 11, 2023
8aed03e
More clarity
ekr Nov 11, 2023
5f9a44a
"either send a ServerHello or a HelloRetryRequest depending on the co…
dconnolly Nov 29, 2023
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
10 changes: 10 additions & 0 deletions draft-ietf-tls-rfc8446bis.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2304,6 +2304,16 @@ MAY omit the most preferred groups. Such a situation could arise if the most
preferred groups are new and unlikely to be supported in enough places to
make pregenerating key shares for them efficient.

For this reason, the omission of a share for group A and inclusion of
one for group B does not mean that the client prefers B to A.
Selecting a group based on KeyShareEntry may result in the use of
a less preferred group than the client and server mutually support,
Copy link
Contributor

Choose a reason for hiding this comment

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

Optional: Is it worth calling out explicitly out the security issue explicitly?

Perhaps something like:

For this reason, the omission of a share for group A and inclusion of one for group B does not mean that the client prefers B to A. Selecting a group based on "key_share" alone may result a less preferred group than the client and server mutually support. Although this saves the round trip of HelloRetryRequest, the selected group may be less secure than another common option. Servers MAY preferentially select a group based on "key_share" to reduce round trips, but MUST consider all options in "supported_groups" when making this decision.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think the explanatory text is good, but the MUST in the last sentence is too strong. Like, suppose my policy is: I am happy with groups A, B, or C, though I prefer A. In that case, I don't need to look at supported_groups, I just need to pick the one I like best out of KeyShare if present, right?

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah fair. Yeah if you know that you only have one equipreference group then it doesn't matter. Maybe a SHOULD? Or we could just drop the sentence. Not attached to it.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think we do want a MUST-level requirement on the server, but for something like "MUST account for the possibility that supported_groups contains a more-preferred group than is present in key_share". Knowing that you only have a single equipreference grouping accounts for that possibility by rendering it impossible.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't see how "MUST account for" is operationalizable.

As @davidben says, we've never made any requirements at all about how the server negotiates, so I don't think doing so now unconditionally is really appropriate.

though saving the round trip of HelloRetryRequest. Servers
that wish to respect the client's group preferences SHOULD first
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: This may not just be client prefs, but also server prefs. I think really this is about the server not believing in equipreference groups, either by way of the client's prefs (since the client can't express them) or its own.

But talking about equipreference groups in a spec that intentionally doesn't talk about selection criteria is kinda weird. Not sure what to do here. Maybe we don't need that example if we've spelled it out in the preceding text clearly enough?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's my hope.

select a group based "supported_groups" and then either send a
ServerHello or a HelloRetryRequest depending on the contents of
KeyshareClienthello.

Clients can offer as many KeyShareEntry values as the number of supported
groups it is offering, each
representing a single set of key exchange parameters. For instance, a
Expand Down
Loading