Draft: draft-ietf-tls-tls13

Commentary: For issue . This relaxes the requirement to check for and error on lack of inclusion in both extensions and focuses the explicit error requirement on the case of multiple keys for the same group . 
 Clients MUST NOT offer multiple KeyShareEntry values for the same parameters . Clients and servers MUST NOT offer any KeyShareEntry values for groups not listed in the client 's " supportedgroups " extension . Servers MUST NOT offer a KeyShareEntry value for a group not offered by the client in its corresponding KeyShare . Implementations receiving any KeyShare containing any of these prohibited values MUST abort the connection with a fatal " illegalparameter " alert . It 's a pain in the ass to check for KeyShareEntry values that are not in the NamedGroups and NSS does n't presently do it . I think the requirement should be relaxed to just be that you do n't select one of them . 
 I think you wrote this text . Objections ? 
 Relaxing this a bit should be fine . Letting redundant keys slide sounds a bit risky for interop , though . PR with new text submitted . 
 The " MUST " for what error to throw could be reduced to a " SHOULD " , if you 'd like to make this even less strict . Not likely to come up that often , though , and I do n't see it being more than an interop & waste issue ( at least at the moment ) . 
 I think that MUST NOT send and MAY generate a fatal error is the right balance here . As an implementation , it 's annoying to do this sort of validation because you have to cross validate two extensions , and most of the code for extensions is in the extension handler . Note that even the check for duplicate groups is not something that NSS does . ( Did you want to close this now ? )
Paragraph (version A):
Clients offer an arbitrary number of KeyShareEntry values, each
representing a single set of key exchange parameters.  For instance,
a client might offer shares for several elliptic curves or multiple
integer DH groups.  The key_exchange values for each KeyShareEntry
MUST by generated independently.  Clients MUST NOT offer multiple
KeyShareEntry values for the same parameters.  Clients and servers
MUST NOT offer any KeyShareEntry values for groups not listed in the
client's "supported_groups" extension.  Servers MUST NOT offer a
KeyShareEntry value for a group not offered by the client in its
corresponding KeyShare.  Implementations receiving any KeyShare
containing any of these prohibited values MUST abort the connection
with a fatal "illegal_parameter" alert.
Paragraph (version B):
Clients offer an arbitrary number of KeyShareEntry values, each
representing a single set of key exchange parameters.  For instance,
a client might offer shares for several elliptic curves or multiple
integer DH groups.  The key_exchange values for each KeyShareEntry
MUST by generated independently.  Clients MUST NOT offer multiple
KeyShareEntry values for the same group and servers recieving
multiple KeyShareEntry values for the same group MUST abort the
connection with a fatal "illegal_parameter" alert.  Clients and
servers MUST NOT offer or accept any KeyShareEntry values for groups
not listed in the client's "supported_groups" extension.  Servers
MUST NOT offer a KeyShareEntry value for a group not offered by the
client in its corresponding KeyShare.