Re: [TLS] Draft 18 review : Hello Retry Request and supported groups cache

[Olivier Levillain <[e-mail]>]

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