On Tue, Nov 22, 2016 at 11:09 AM, Steven Valdez <sval...@chromium.org> wrote:
> 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. -Ekr > > 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 > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
