Re: ezflate: proposal to reinstitute deflate header compression

Keith,

what I like about this proposal is that it essentially makes being safe
from CRIME style attacks somebody else's problem.   Ie the transport
protocol should not need to tie itself in knots trying to make up for the
deficiencies of the secure channel of choice on the internet.

Currently I've seen at least 3 security inspired mechanism in h2 that I
don't think belong in the transport protocol.

   - Firstly there is data frame padding, complete with scary text about
   how you must use this feature if you wish to be secure - But don't even
   think of trying to use it unless you are a super security expert.

   - We then have hpack encoding strategies that must pick the right style
   of encoding depending on the security nature of the meta data.  Easy for
   cookies, but not much else.

   - While not in the spec, I have seen a hpack implementation that is
   using a constant time string equals function, so it does not leak timing
   information on inequality failure!

These are all at the discretion of the implementation and thus I do not
understand how they move security forward in any general way and users will
not know if they can trust https2 or not. Will it really only be safe to
use my online banking if I know both ends are using constant time equals
comparisons?   How will the users know that their bank server is generating
safe padding? Will the browser location bar contain a bunch of little icons
for constant time equals, safe padding generation etc.

I do understand that something has to be done to fix the deficiencies of
TLS.  I just don't see why that is the responsibility of the h2 protocol
and the detailed implementations to do so.     Not every (or any) h2
implementation is going to be able to warrant that it does not leak some
kind of information about it's security related content.  Avoiding
compressing cookies is OK, but I just don't know what to do with the other
mechanisms and nor will many many http2 implementers.

I can't really comment much more about this specific proposal, simply
because I'm not just not qualified and do not have the deep security
related knowledge to do so.   For exactly this reason, I think the
transport protocol is not the place to solve these types of problems - we
should use and depend on RFCs that have been developed by a WG of security
experts.

As for using ezflat in h2, should be fine.  Using gzip was a bit of a pain
in SPDY because of serialisation  for the shared state, but we have that
with hpack anyway.  At least it is fragmentable.

cheers






On 3 June 2014 17:21, Willy Tarreau <w@1wt.eu> wrote:

> On Tue, Jun 03, 2014 at 08:45:16AM +0000, RUELLAN Herve wrote:
> > > -----Original Message-----
> > > From: Willy Tarreau [mailto:w@1wt.eu]
> > > Sent: mardi 3 juin 2014 10:18
> > > To: K.Morgan@iaea.org
> > > Cc: ietf-http-wg@w3.org; C.Brunhuber@iaea.org
> > > Subject: Re: ezflate: proposal to reinstitute deflate header
> compression
> > >
> > > ...
> > >
> > > it yet so I would not pronounce myself on it), but at least it has the
> merit
> > > of having been designed for the exact purpose it will be used for. My
> only
> > > concern with it is how we could disable it when its gains are not
> considered
> > > worth its costs, or when an issue is faced later and we need to
> disable it.
> >
> > HPACK in itself can't be disabled, but you can always send headers as
> > literals and flagging them to forbid indexation further down the path.
> You
> > can do this for all headers, to go back to an encoding close to
> HTTP/1.x, or
> > only for some critical headers.
> > This feature was added recently, after a security analysis of HPACK.
>
> OK, thank you Hervé for this clarification.
>
> Regards,
> Willy
>
>
>


-- 
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.