Subject: [TLS] "selected_group" field in HelloRetryRequest in TLS 1.3

From: Xuelei Fan <[email-masked]>
Date: Fri, 27 Nov 2015 10:38:45 +0800

Hi,

What's the consideration to place selected_group out of the extensions
filed in HelloRetryRequest?

      struct {
          ProtocolVersion server_version;
          CipherSuite cipher_suite;
          NamedGroup selected_group;
          Extension extensions<0..2^16-1>;
      } HelloRetryRequest;

vs

      struct {
          ProtocolVersion server_version;
          CipherSuite cipher_suite;
          Extension extensions<0..2^16-1>;   // use key_share (empty share)
or
                                                              //
supported_group for named groups
      } HelloRetryRequest;

The latter may be more friendly for future extensibility, and easier to
implement.  For example, FFDHE may be easy to expose to pre-computation
issues in the future, and dynamic safe prime groups may be expected at that
time.  Having the selected_group as an extension might be more flexible  to
define new replacement.

Thanks,
Xuelei

---

From: Martin Thomson <[email-masked]>
Date: Fri, 27 Nov 2015 18:25:00 -0800

On 26 November 2015 at 18:38, Xuelei Fan <[email-masked]> 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.

---

From: Xuelei Fan <[email-masked]>
Date: Sat, 28 Nov 2015 12:42:48 +0800

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