On Wed, Nov 23, 2016 at 12:19 AM, Olivier Levillain < olivier.levill...@ssi.gouv.fr> wrote:
> 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". > This is is unsafe, because the HRR is unauthenticated. We could update it after the handshake completes, but I think this is obvious enough that it doesn't need to be stated. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
