Draft: draft-ietf-tls-tls13

Commentary: The text already says that both supportedgroups and keyshares are in order of " client preference " . Supposing " client preference " is a well - defined notion , we are already requiring the order match . The SHOULD was also unclear on whether the list may be a general subsequence . Clarify that this is allowed . This may be useful if , say , we define some very large NamedGroup ( post - quantum ? ) in the future that is still preferable over the existing options . Clients would likely wish to NOT offer it initially because it would be a waste of bandwidth for the vast majority of servers which do n't support it . ( Not to mention intolerance problems . ) In that scenario , a client would likely not predict a keyshare by default and instead use some kind of server info cache ( either caching what the server chose or using the full server supportedgroups list ) . But that client would still wish to advertise the new group first . 
 This is what I get for uploading PR immediately before trying to enforce it instead of immediately afterwards ... :-) On the plus side , yay for tests ! The list in the extension is supposed to be " in descending order of client preference " . However , this is n't true for the second ClientHello because the new KeyShareEntry is always appended . It 's only a SHOULD - level requirement with reverted , but the spec text is still off , and it is a little bit odd for stateless HRR implementations . ( Though if the stateless implementation remembers in the cookie that it already committed to a group , it 's probably still fine ? ) 
 Just put an " except for the last , in the case where an additional is requested with a HelloRetryRequest " or something on the sentence . 
 Sounds reasonable . Another option is we say is n't ordered at all . I dunno , maybe you have to keep them sorted or something . There already is a ordering . We 're pretty ambiguous right now about whether is a secondary preference list or merely a prediction set . ( I think it 's best to make it a prediction set and avoid the complex semantics . ) 
 Although keeping them sorted would be a huge pain , even if it is easier to enforce . That 's probably not a good idea . 
 Well , if we wanted the  case to jive nicely with sorting , we could mandate reverse priority order ; the appended would be top priority . This would work nicely , but could be considered unnecessary if sorting is any burden . I do n't remember if this was specifically why I put a SHOULD here , but mandating an absolute requirement here could just be more trouble than it 's worth . The worry with not having any requirement is that a pair of bad implementations could use the keyshare priority instead of supportedgroups and mess things up , however I 'm not so sure it 's that big of a risk . I think a SHOULD with exception is fine . 
 proposal on - list to replace the key_share after an  , rather than append to it , would fix this rather easily . Much better than fiddling with the language or ordering .
Paragraph (version A):
A list of offered KeyShareEntry values in descending order of
client preference.  This vector MAY be empty if the client is
requesting a HelloRetryRequest.  The ordering of values here
SHOULD match that of the ordering of offered support in the
"supported_groups" extension.
Paragraph (version B):
A list of offered KeyShareEntry values in descending order of
client preference.  This vector MAY be empty if the client is
requesting a HelloRetryRequest.  Each KeyShareEntry value MUST
correspond to a group offered in the "supported_groups" extension
and MUST appear in the same order.  However, the values MAY be a
non-contiguous subset of the "supported_groups" extension and MAY
omit the most preferred groups.