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

From: Eric Rescorla <[email-masked]>
Date: Fri, 3 Jan 2014 11:41:33 -0800

WG Members,

We have received a request from the authors of

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

For early code point assignment. While there have not been
a lot of comments this is a simple draft and and seems like
an important tool for dealing with noncompliant servers
which do not react well to specific-sized ClientHellos
and so far we have heard no objections to this document.

If there are any strong objections to this document or to
making this provisional code point assignment, please
raise them by Jan 10.

The chairs are also interested in if people feel this should
be a TLS WG item or an individual submission (or, if, as
above, they object to it.)

-Ekr
[For the chairs]

---

From: Russ Housley <[email-masked]>
Date: Fri, 3 Jan 2014 14:51:39 -0500

I think the document is fine, but I do not think that the TLS WG should ask for a early allocation unless the WG is going to proceed with the document.

Russ

On Jan 3, 2014, at 2:41 PM, Eric Rescorla wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Watson Ladd <[email-masked]>
Date: Fri, 3 Jan 2014 14:53:55 -0500

> above, they object to it.)

What does this mean from a practical perspective? From my limited
knowledge it only
changes the length of the IETF last call, and doesn't substantively
affect the process.
Also, the draft shouldn't be published on April 1st. No one will
believe this is a real extension
if we do so.

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 03 Jan 2014 17:44:07 -0500

> making this provisional code point assignment, please

I would be happy to see a provisional code point assignment on this TLS
extension.

> above, they object to it.)

It seems to me like it should be a WG item.  It doesn't seem
controversial at all, and it's clear that all TLS clients today have a
concrete use for it.

	--dkg

---

From: Andrei Popov <[email-masked]>
Date: Tue, 7 Jan 2014 19:13:40 +0000

A provisional code point assignment for this TLS extension would be great.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Daniel Kahn Gillmor
Sent: Friday, January 3, 2014 2:44 PM
To: Eric Rescorla; [email-masked]
Subject: Re: [TLS] Next steps for draft-agl-tls-padding

On 01/03/2014 02:41 PM, Eric Rescorla wrote:
> For early code point assignment. While there have not been a lot of 
> comments this is a simple draft and and seems like an important tool 
> for dealing with noncompliant servers which do not react well to 
> specific-sized ClientHellos and so far we have heard no objections to 
> this document.
> 
> If there are any strong objections to this document or to making this 
> provisional code point assignment, please raise them by Jan 10.

I would be happy to see a provisional code point assignment on this TLS extension.

> The chairs are also interested in if people feel this should be a TLS 
> WG item or an individual submission (or, if, as above, they object to 
> it.)

It seems to me like it should be a WG item.  It doesn't seem controversial at all, and it's clear that all TLS clients today have a concrete use for it.

	--dkg

---

From: [email-masked] (Martin Rex)
Date: Tue, 7 Jan 2014 21:17:22 +0100 (CET)

> 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

---

From: Adam Langley <[email-masked]>
Date: Wed, 8 Jan 2014 14:29:23 -0500

> what draft-agl-tls-padding-02 really means implementation-wise.

Thanks for the comments. I think you make a good point and I've
updated the draft
(https://tools.ietf.org/html/draft-agl-tls-padding-03) to include your
suggestions. (It'll need to be updated with the precise extension
type, if assigned.)

Cheers

AGL

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 26 Jan 2014 15:37:48 -0800

WG Members,

Based on this discussion the chairs believe we have sufficient support to
ask for an early code point assignment. This message serves as a request
to the chair to do so.

Additionally, unless someone objects we intend to adopt it as a WG draft.
If there are any objections, please post them by Mon Feb 3.

-Ekr