On Tue, Dec 20, 2011 at 2:47 PM, Anne van Kesteren <ann...@opera.com> wrote: > On Tue, 20 Dec 2011 22:55:40 +0100, Eric Rescorla <e...@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. -Ekr