On Wed, Sep 3, 2014 at 5:30 PM, Greg Wilkins <gregw@intalio.com> wrote:
>
> On 4 September 2014 08:30, Roberto Peon <grmocg@gmail.com> wrote:
>
>> 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.
>>
>
> I completely agree that applications often don't think about this sort of
> thing. As an infrastructure provider I like nothing more than providing a
> service my users didn't even know that they needed.
>
> But in this case the draft does not say that automatic padding is a bit
> better than nothing. In fact it says that padding without knowledge of the
> data may be *counterproductive* and *easily defeated.*
>
I also said something about rules/configuration... :)
-=R
>
> So without guidance of how to generate padding in productive way, my
> implementation will simply never generate padding and will discard any
> padding received (because there are no channels available to pass it to
> layers above). Hhmmm I think Brian said this better:
>
>
> On 4 September 2014 08:31, Brian Smith <brian@briansmith.org> wrote:
>
>> In general, it is unreasonable to expect implementations to correctly
>> implement this security feature when the way to correctly implement it
>> is unspecified. The correct processing of padding, in particular, is
>> extremely non-obvious.
>
>
> +1
>
> If there is a recommended way to improve security by generating padding,
> then I will happily implement it. But if there is not a recommended
> general approach to padding then we are not going to magically create
> secure automatic padding simply by saying that implementations may pad for
> security.
>
> cheers
>
>
> --
> 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.
>