W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: [XHR] chunked requests

From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 20 Dec 2011 14:59:50 -0800
Message-ID: <CABcZeBM3EpzaMDcTZVjKBzhidWBh2Zaz-ksmruzvHfobJjn2mg@mail.gmail.com>
To: Anne van Kesteren <annevk@opera.com>
Cc: public-webapps@w3.org
On Tue, Dec 20, 2011 at 2:47 PM, Anne van Kesteren <annevk@opera.com> wrote:
> On Tue, 20 Dec 2011 22:55:40 +0100, Eric Rescorla <ekr@rtfm.com> wrote:
>> That isn't to say that the browser stacks aren't adding 1/n+1
>> splitting. NSS, for instance, has such a fix. However, I don't think
>> there's anything to do from a TLS standards perspective.
> What I would like is a standard that actually defines what of TLS user
> agents need to implement. Instead of every user agent having to figure that
> out for themselves. Those unknowns (TLS is not alone here) create a barrier
> to entry and make it harder to create user agents that interoperate with
> "legacy" content.

Again, the TLS spec does tell you what to do: it tells you to
implement TLS 1.1 and/or 1.2.

What you're asking for is for it *also* to tell you what to do in
cases where you choose
to use a downrev version of TLS. But unfortunately, that guidance is
necessarily application
specific. In particular, the use of 1/n+1 splitting is the result of
discovering that some
HTTP stacks don't properly handle empty TLS records and even then some
stacks choke
Moreover, many non-HTTPS stacks have no need to do any sort of countermeasure
because Rizzo-Duong-style attacks don't apply.

If/when IETF publishes a revision of TLS, I suspect we'll add a
description of 1/n+1 splitting
as a backward compatibility measure, but I don't really think it's the
role of standards
to document security hacks for downrev versions in perpetuity.

Received on Tuesday, 20 December 2011 23:01:00 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:37 UTC