Clarify how to negotiate groups if you want to respect the client order. #1331
Conversation
draft-ietf-tls-rfc8446bis.md
Outdated
| though saving the round trip of HelloRetryRequest. Servers | ||
| that wish to respect the client's group preferences SHOULD first | ||
| select a group based "supported_groups" and then either complete the | ||
| handshake or send a HelloRetryRequest depending on the contents of |
There was a problem hiding this comment.
Is "complete the handshake" what we want here? I would say that both branches of the decision tree are completing the handshake, it's just that one is not doing so immediately.
There was a problem hiding this comment.
Sure. How about "send either a ServerHello or a HelloRetryRequest depending..."
There was a problem hiding this comment.
Chris has put in the suggestion; thanks (looks good to me)
Yes, we could if we were trying to avoid 2119 language, but it seems like a circumlocution |
| 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, |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
| Selecting a group based on KeyShareEntry may result in the use of | ||
| a less preferred group than the client and server mutually support, | ||
| though saving the round trip of HelloRetryRequest. Servers | ||
| that wish to respect the client's group preferences SHOULD first |
There was a problem hiding this comment.
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?
|
@kaduk Is this good-to-go from your perspective? |
Once Chris's suggestion is taken, it is okay from my perspective. |
…ntents of KeyshareClienthello." Co-authored-by: Christopher Wood <caw@heapingbits.net>
Suggestion committed |
This tries to make the situation clearer. It does add a normative SHOULD but I think it's obvious.