On Thu, Jan 04, 2024 at 04:33:30PM +0100, Hannes Tschofenig wrote: > Hi Ilari, > > When exchanging key shares, the use of supported_groups is mandatory (at > least that's what I remember).
Only for client, it is not mandatory for server. RFC 8446 only says that servers "are permitted to send" supported_groups and SHOULD send it if doing HRR because of missing group. > > > > - The endpoint sending EKU with update_requested is the initiator for > > groups that have asymmetric roles, right? > > The client sends an EKU to the server in an attempt to update the > traffic key for traffic sent from itself to the server. If it also > wants to trigger the server to update the traffic keys in the reverse > direction, namely from the server to the client, it needs to set the > update_requested flag. Then, the server will have to trigger a > separate exchange. There are groups where it is not possible for client to tell crossed EKU request from EKU reply from the key share itself, and things go south if it processes crossed EKU requesst as EKU reply. Milder version of that is groups that have incompatble client and server key shares, but those can be identified from length. I don't think having just update_requested/update_not_requested flag is sufficient. Non-crossed bidirectional update needs three-way (with two or four key shares), and the crossed case needs to be handled (with four key shares). -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
