Hi, >> Being able to send supported_groups does allow a server to choose to make >> a tradeoff between an extra round trip on the current connection and its >> own group preferences. One example where a server might want to do this is >> where it believes that X25519 is likely a more future-proof group and would >> prefer that, but still believes the client's choice of P256 is suitable for >> this connection. Always requiring an extra round trip might end up being >> expensive depending on the situation so some servers might prefer to avoid >> sending an HRR for a slightly more preferred group. >> >> I think that requiring the client to maintain state from the >> supported_groups puts undue requirements on the client, since not all >> clients keep state between connections, and those that do usually only keep >> session state for resumption. >> > This matches my view as well. > > I agree that the client should not be require to keep state. I do not > believe that the draft requires this, but if someone thinks otherwise, > please send a PR to fix. >
There were actually two points in my message: - I was not convinced by this way of signalling a preference without enforcing it, but I understand that, if we keep supported_groups, it does not cost much and the client can safely ignore the server sent extension; - however, I found strange that the specification stated that the client could update its view when seeing this extension, but that it was not stated in the case of an HRR where updating its views of the servers' preference would clearly be useful for the future. I only proposed to add the same text "The client MAY update its view of the server's preference when receiving an HRR, to avoid the extra round trip in future encounters". olivier _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
