Re: fixing TLS vulnerabilities with h2 was: ezflate: proposal to reinstitute deflate header compression

Hi Greg-

Thanks for the feedback. Changing the subject though to more adequately reflect what you discussed, which IMO is an important point, namely:

Is it the responsibility of h2 to fix security vulnerabilities in TLS?

You make a good argument that the answer is no. The very purpose of protocol layering is separation of concerns. In other words, the security protocol, in this case TLS, should be secure (or patched if it isn't) - the underlying protocol shouldn't have to worry about it.

Nobody should ever be concerned about whether their bank is using the "right" h2 implementation - eg one that uses constant time string comparison functions.

-Keith


On Jun 4, 2014, at 4:52, "gregw@intalio.com<mailto:gregw@intalio.com>" <gregw@intalio.com<mailto:gregw@intalio.com>> wrote:

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<mailto: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<mailto:w@1wt.eu>]
> > Sent: mardi 3 juin 2014 10:18
> > To: K.Morgan@iaea.org<mailto:K.Morgan@iaea.org>
> > Cc: ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>; C.Brunhuber@iaea.org<mailto: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<mailto: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.

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

Received on Thursday, 5 June 2014 03:38:14 UTC