Re: [TLS] Next steps for draft-agl-tls-padding

[[e-mail] (Martin Rex)]

Andrei Popov wrote:
>
> A provisional code point assignment for this TLS extension would be great.

A provisional code point would be nice, but I had to read the
description of the extension contents several times and cross-check
with other TLS extension documents to figure out (and assure myself)
what draft-agl-tls-padding-02 really means implementation-wise.

  http://tools.ietf.org/html/draft-agl-tls-padding-02#section-3

   3.  Padding Extension

   A new extension type (""padding(TBD)"") is defined and MAY be
   included by the client in its ClientHello message.
   enum {
           padding(TBD), (65535)
   } ExtensionType

   The client MUST fill the padding extension completely with zero
   bytes, although the padding extension may be empty.

   The server MUST NOT echo the extension.


Based on the general definition of TLS extensions:

   http://tools.ietf.org/html/rfc3546#section-2.3
   http://tools.ietf.org/html/rfc4366#section-2.3
   http://tools.ietf.org/html/rfc5246#section-7.4.1.4

   2.3.  Hello Extensions

   The extension format for extended client hellos and extended server
   hellos is:

      struct {
          ExtensionType extension_type;
          opaque extension_data<0..2^16-1>;
      } Extension;

   Here:

   - "extension_type" identifies the particular extension type.

   - "extension_data" contains information specific to the particular
     extension type.


I assume that what draft-agl-tls-padding-02 intends to say is that

  "extension_data" for the Padding TLS extension has no internal structure
  (and therefore no additional extension-internal length field).

Anyhow, extension_data is supposed to have variable length,
and constain only zero bytes when present.

compare to Renegotiation Info TLS extension:
   http://tools.ietf.org/html/rfc5746#section-3.2

It might help to describe the resulting on-the-wire encoding of two samples:

the padding ExtensionType will be a 16-bit integer that can be represented
as 0xhhll  (where hh stands for the most significant octet and ll stands
for the least significant octet).

The shortest padding "Extension" struct with padding length 0 will encode to

   hh ll 00 00

With a padding of 5 octets, the padding "Extension" struct will encode to

   hh ll 00 05 00 00 00 00 00

   \   / \   / \            /
    \ /   \ /   \          /
     |     |     ----------
     |     |         |
     |     |         +----  Extension.extension_data contents 
     |     |
     |     +--------------  <0..2^16-1> 16-bit length of
     |                      Extension.extension_data variable length vector
     |
     +--------------------  IANA-assigned Extension.extension_type
                            for padding extension


The Renegotiation Info extension will also be "empty" on initial handshakes
on a connection, but its extension_data has internal structure

      struct {
          opaque renegotiated_connection<0..255>;
      } RenegotiationInfo;

and the variable length internal structure adds an additional length field
(a one-octet length field for vector size <0..255>), even when
renegotiated_connection itself is "empty", resulting in the
on-the-wire representation  ff 01 00 01 00 .


-Martin