Truthfully, many folks who write applications will not think about this kind of thing, and providing something which does handle this for them automatically is likely quite a bit better than nothing. Sometimes (reverse) proxies are called into the picture to help out with some of these issues. In such cases, having a mechanism that allows a proxy to manipulate the data on the wire (likely with simple settings/rules for that application/product/endpoint) with a guarantee that it is not affecting an accidental semantic change is useful. -=R On Wed, Sep 3, 2014 at 3:22 PM, Greg Wilkins <gregw@intalio.com> wrote: > > On 4 September 2014 05:33, Brian Smith <brian@briansmith.org> wrote: > >> That isn't the issue. The issue is with an implementation, such as a >> proxy, that does something like "split the padding into its own frame >> and put the data in another frame," and/or putting those split frames >> in separate TLS records and/or TCP packets, which is currently allowed >> (AFAICT) in draft 14. >> > > Which is precisely why telling the framing layer about security padding is > a self defeating exercise. TCP packet boundaries are just one potential > artefact that an observer can use to guess payload sizes, handling time is > another and I'm sure somebody could even observe CPU and/or power drain if > they really wanted to get spooky about it. > > If we want security padding to be truly indistinguishable from real > payload, then don't tell the framing layer that it is padding. > > Better to have no security than false security. > > -- > Greg Wilkins <gregw@intalio.com> > http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that > scales > http://www.webtide.com advice and support for jetty and cometd. >
Received on Wednesday, 3 September 2014 22:31:23 UTC