Re: Concluding discussion on #612 (9.2.2)

[Martin Thomson <[e-mail]>]

I was talking to someone about new research into attacks on RC4, and was
asked if HTTP/2 was potentially interesting. In particular, they were
looking for interesting information in the first 256 bytes of a session,
where the biases are most easily exploited. I noted that it might be
interesting - header compression results in less boilerplate - if it
weren't for the fact we had prohibited use of RC4.
On Oct 7, 2014 6:06 PM, "Brian Smith" <[e-mail]> wrote:

> On Tue, Oct 7, 2014 at 1:13 PM, Rob Trace <[e-mail]> wrote:
> > Our feedback on the proposals listed below is that we cannot live with
> 9.2.2 being in the HTTP/2 spec and favor Greg's proposal of "move 9.2.2
> requirements to a document that applies to h1 and h2."
>
> AFAICT, that is not even an option at this stage, without risking
> significant delay and/or making the protocol less secure.
>
> It seems that some people think that 9.2.2 is in the specification due
> to some kind of unnecessary advocacy effort for better cryptography.
> While I think it is good if it has that effect, 9.2.2 is really in the
> the specification because it addresses real security and performance
> concerns.
>
> Many months ago, I was asked, as I'm sure others were, to provide
> feedback about the interaction of TLS and HTTP/2. In particular, is
> HTTP/2 as safe to use as HTTP/1.1 with RC4? Is HTTP/2 as safe to use
> as HTTP/1.1 with TLS 1.0 CBC-mode cipher suites? My feedback, and I
> believe the others' feedback, was that it was a waste of time to try
> to prove that HTTP/2 is as safe to use as HTTP/1.1 in these
> dysfunctional configurations of TLS. That is why I supported making
> RC4, SSL 3.0, and TLS 1.0 MUST NOTs.
>
> Those restrictions were added to an HTTP/2 draft a long time ago (a
> year ago?), and they've remained in the draft (actually, the draft has
> gotten more strict) for a very long time. Consequently, nobody even
> bothered to do a security analysis of HTTP/2 using these dysfunctional
> configurations of TLS, on the assumption that these restrictions would
> remain in place. As it currently stands, it doesn't make sense, given
> what we know about these security footguns, to allow them with HTTP/2,
> because we don't have a clear idea if they are safe to use in
> conjunction with HTTP/2.
>
> While RC4, SSL 3.0, and TLS 1.0 have obvious known problems, it seems
> to me that the restrictions beyond prohibiting those three things are
> more about prevention of as-yet-unknown problems. I think that that
> preventative effort will pay off down the road, probably sooner than
> later. Plus, if we'd have the no-RC4, no-SSL 3.0, and no-TLS 1.0
> restrictions anyway to address practical known concerns, I don't see
> how the additional TLS 1.2, AEAD, and ephemeral key exchange
> requirements are a significant additional burden.
>
> The biggest benefit of HTTP/2 is better performance & efficiency. The
> use of ephemeral key exchange, the symmetric cipher used, and probably
> eventually the version negotiated, are factors used by many clients
> will choose to do False Start or not. The False Start optimization is
> one of the most important optimizations for HTTP. Having the HTTP/2
> specification require a TLS configuration that is roughly the
> intersection of what enables False Start for all major browsers is
> itself enough of a reason to leave things 9.2.2 in the spec.
> Otherwise, implementations will have to indefinitely continue to make
> significant and otherwise-unnecessary, security-for-performance
> trade-offs.
>
> So, again, 9.2.2 serves a real purpose in the spec independently from
> any "better/ideal crypto" advocacy effort. At this point, after 9.2.2
> has been in the drafts for so long, and because people have relied on
> that to avoid the cost of doing additional (wasteful, IMO) security
> analysis, the burden of responsibility for doing any additional
> security analysis for HTTP/2 with currently-prohibited configurations
> of TLS falls on the people that want to remove 9.2.2, before the
> working group should even consider doing so.
>
> Cheers,
> Brian
>