1
$\begingroup$

In the TLS 1.2 protocol, the client may send extensions. My question is: what is the format of this field? is it a list?

In TLS 1.2 client hello, the standard says:

extensions Clients MAY request extended functionality from servers by sending data in the extensions field. The actual "Extension" format is defined in Section 7.4.1.4.

At the server hello, the standard explicitly says it is a list. But I am not sure if this implies that the client also sends the extensions as a list:

extensions A list of extensions. Note that only extensions offered by the client can appear in the server's list.

I assume the same format is used in tLS 1.3 as well.

$\endgroup$
  • $\begingroup$ This doesn't really have anything to do with cryptography and probably belongs next door on security.SX. $\endgroup$ – dave_thompson_085 Aug 7 '17 at 6:30
  • 1
    $\begingroup$ It is actually called a variable length vector and the syntax is described in section 4.3. The maximum number of octets has implications to the runtime format, because it demands a length tag of uint16 (2 octets) before the actual concatenation of encoded extensions (and each encoded extension gives its own length representation). $\endgroup$ – eckes Aug 12 '17 at 17:21
1
$\begingroup$

Section 7.4.1.2 of RFC 5246 defines the following ClientHello:

  struct {
      ProtocolVersion client_version;
      Random random;
      SessionID session_id;
      CipherSuite cipher_suites<2..2^16-2>;
      CompressionMethod compression_methods<1..2^8-1>;
      select (extensions_present) {
          case false:
              struct {};
          case true:
              Extension extensions<0..2^16-1>;
      };
  } ClientHello;

As you can see, you can add up to $2^{16}=65536$ bytes of extensions to your client hello in a list format as per section 4.3.

| improve this answer | |
$\endgroup$
  • $\begingroup$ That's 65536 -1 bytes of extensions. Each extension must be at least 4 bytes, and most actually-used extensions are more, so the number of extensions can't be more than a few thousand, and in practice is never more than a dozen or two. $\endgroup$ – dave_thompson_085 Aug 7 '17 at 6:28
  • $\begingroup$ @SEJPM Thanks a lot for your helpful answers. Two more question about this please. Correct me if I'm wrong. 1) The following notation in the standard <...> always means a list format?? 2) That means the extensions field is a list of lists. Reference to the Extension struct in link, I get that the Hellos extension field is a list of lists (each extension is represented by a list). $\endgroup$ – user6875880 Aug 12 '17 at 11:48
  • $\begingroup$ @user6875880 yes, <...> always denotes a variable-length list format in RFC 5246. And yes the Extension struct is a header (the ExtensionType) with up to $2^16$ bytes worth of data. And yes these extensions are organized as a list themselves. $\endgroup$ – SEJPM Aug 12 '17 at 11:52
  • $\begingroup$ @SEJPM Sorry but just recognised that, struct is not a list. It is a datatype in itself, isn't it? I'm confused in a message sequence diagram, say a client hello with multiple extensions including key_share extension as in TLS 1.3. Should it by like: client_hello(.., [..,[k_1,k_2],..], ..) or just: client_hello(.., [k_1,k_2], ..) ?? do you see the difference? either the list of key shares inside the client_hello directly, or inside a list (the Extension parameter). I'm confused. $\endgroup$ – user6875880 Aug 12 '17 at 12:11
  • $\begingroup$ @user6875880 If the key_shares is an extension that defines its own list-format (or re-uses the TLS one), the extension would be an entry in the outer list (marking the following bytes / entries as key_share entries) and then there would be an inner list of key_shares, so in total something like client_hello(...,[...,{key_shares,[k_1,k_2]},...],...) $\endgroup$ – SEJPM Aug 12 '17 at 13:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.