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. On Tue, Nov 22, 2016 at 2:01 PM Olivier Levillain < olivier.levill...@ssi.gouv.fr> wrote: > Hi list, > > I am sorry for the very late answer concerning draft 18, but we > (ANSSI) have several remarks after proof-reading the current > specification. > > We are sorry for the multiple long messages. > > If the WG is interested by some of our concerns/proposals, we would be > glad to propose some PRs. > > > = HRR and supported groups cache = > > In 4.2.4 (P.41), a server can send a supported_groups extension to > "update the client's view of its preference" in its ServerHello. > Since this behaviour is completely left to the client's discretion, it > does not seem a very relevant policy from the server: either the > server accepts one of the proposed groups, or it sends an HRR. We do > not think the middle ground (OK for this group, but I would prefer > this other one) is relevant, so the sentence should be removed. > > Moreover, as far as I could understand, there is no indication in the > specification that a client should remember the preference of the > server in case it receives a HRR, which there would definitely make > sense. Such text could go in 4.1.4. > > I can propose a PR for this point. > > > Olivier Levillain > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
