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

From: Peter Bowen <[email-masked]>
Date: Sat, 5 Apr 2014 08:25:56 -0700

On Sun, Jan 26, 2014 at 3:37 PM, Eric Rescorla <[email-masked]> wrote:
> 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.

It looks like this was assigned value 21 last month.
(http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml)
 Other than updating the draft replace "TBD" with "21" are there other
open issues?

---

From: Andrey Jivsov <[email-masked]>
Date: Sun, 06 Apr 2014 17:21:56 -0700

>
> 1. Introduction
>
>
>    Successive TLS [RFC5246] versions have added support for more cipher
>    suites and, over time, more TLS extensions have been defined.  This
>    has caused the size of the TLS ClientHello to grow and the additional
>    size has caused some implementation bugs to come to light.  At least
>    one of these implementation bugs can be ameliorated by making the
>    ClientHello even larger.

( Sorry if it was already discussed )

I suggest to explain why the last sentience in the above paragraph holds 
true. The paragraph leads the reader to the idea that "larger 
ClientHello --> bugs", but then there is a shift that "even larger 
ClientHello --> fewer bugs".

The spec would benefit from a suggestion about what the recommended use 
of the padding extension is (i.e. to which size one should pad).

Thank you.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 7 Apr 2014 10:21:07 -0700

On 6 April 2014 17:21, Andrey Jivsov <[email-masked]> wrote:
> The spec would benefit from a suggestion about what the recommended use of
> the padding extension is (i.e. to which size one should pad).

This has been discussed extensively, here and elsewhere.  See for
instance, http://www.ietf.org/mail-archive/web/tls/current/msg10423.html
or https://www.imperialviolet.org/2013/10/07/f5update.html or
https://code.google.com/p/chromium/issues/detail?id=315828 .

I expect that the draft authors are being sensitive to the fact there
is no need to create a more public, permanent record of what is a
transient problem.

---

From: Watson Ladd <[email-masked]>
Date: Mon, 7 Apr 2014 10:40:10 -0700

> > The spec would benefit from a suggestion about what the recommended use
of
> is no need to create a more public, permanent record of what is a

I read the F5 explaination. It's worth keeping it around so in the future,
when tempted to upgrade a binary protocol we ask the guy proposing the
upgrade how to distinguish old and new.

In particular,  tossing it down the memory hole out of misguided
professional courtesy would probably mean making the same mistake in the
future.

In particular treating this extension's proper use as something to be
passed on by word of mouth hurts new implementors who don't know the magic
number. Embarrassment for F5 is nowhere near as serious.

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

---

From: Andrey Jivsov <[email-masked]>
Date: Mon, 07 Apr 2014 23:25:07 -0700

On 04/07/2014 10:40 AM, Watson Ladd wrote:
>
> On Apr 7, 2014 10:21 AM, "Martin Thomson" <[email-masked]
> <mailto:[email-masked]>> wrote:
>  >
>  > On 6 April 2014 17:21, Andrey Jivsov <[email-masked]
> <mailto:[email-masked]>> wrote:

I appreciate this concern, but I think that both goals can be achieved.

I was looking for a generic description of what problem the draft solves 
and how from the viewpoint of somebody who is unfamiliar with the problem.

Something along these lines:
> The extension can mitigate defects in TLS message identification by
> allowing the sender control the values of octets representing the
> size of the ClientHello packet. The extension can also be used as a
> testing tool for such issues.

>
> I read the F5 explaination. It's worth keeping it around so in the
> future, when tempted to upgrade a binary protocol we ask the guy
> proposing the upgrade how to distinguish old and new.

True. One should always think about what kind of a state machine will be 
needed to handle the old and new protocol messages.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 08 Apr 2014 11:48:33 -0400

> number. Embarrassment for F5 is nowhere near as serious.

I agree with Watson here.  Including some variant of Xiaoyong Wu's
explanation [0] in the padding draft would be useful for future
implementers.  The global network *does* still have SSLv2 endpoints on
it, and they connect to and listen on ports that SSLv3/TLSv1.{0,1,2}
peers also use.

I think Xiaoyong and F5 have done us all a favor by making this
situation clear.  This shouldn't be considered an embarrassment for them.

	--dkg

[0] https://www.ietf.org/mail-archive/web/tls/current/msg10423.html

---

From: Peter Bowen <[email-masked]>
Date: Sun, 13 Apr 2014 09:25:35 -0700

On Tue, Apr 8, 2014 at 8:48 AM, Daniel Kahn Gillmor
<[email-masked]> wrote:
> explanation in the padding draft would be useful for future

This sounds like ideal example appendix material.  It doesn't need to
explicitly call out certain products by name, rather it could suggest
that real world implementations have been observed...

Thanks,
Peter