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

[Andrey Jivsov <[e-mail]>]

On 04/07/2014 10:40 AM, Watson Ladd wrote:
>
> On Apr 7, 2014 10:21 AM, "Martin Thomson" <[e-mail]
> <mailto:[e-mail]>> wrote:
>  >
>  > On 6 April 2014 17:21, Andrey Jivsov <[e-mail]
> <mailto:[e-mail]>> 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.

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.