It makes sense to me. It's OK if TLS 1.3 only supports (EC)DHE cipher suites. If it is extended to support other cipher suites, for example PSK or KRB5 cipher suites (which do not require named groups), the HelloRetryRequest.selected_group may be redundant if this extra RTT is required. As the ServerKeyExchange/ClientKeyExchange will be replaced with key_share extension, I'm still not sure of the impact on those cipher suites, including PSK and KRB5, that replies on ServerKeyExchange/ClientKeyExchange messages. Hopefully, no other cipher suites needs an extra RTT similar to HelloRetryRequest.
Thanks & Regards, Xuelei On Sat, Nov 28, 2015 at 10:25 AM, Martin Thomson <martin.thom...@gmail.com> wrote: > On 26 November 2015 at 18:38, Xuelei Fan <xuelei....@vimino.com> wrote: > > What's the consideration to place selected_group out of the extensions > filed > > in HelloRetryRequest? > > An extension would work, except that I believe that extensions in > HelloRetryRequest are going to carry somewhat different semantics to > those in other Hello messages. > > If we go to dynamically generated groups, then we can easily define a > new FFDHE code point to signal the use of a dynamic group. Though I > think that I'd be sad about having to always spend an extra round trip > if it came to that. > > Also, it's not much, but the explicit field keeps the message (a tiny > bit) smaller and easier to process. >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
