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

On Tue, Nov 22, 2016 at 11:09 AM, Steven Valdez <svaldez@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.levillain@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
>
>