Re: Concluding discussion on #612 (9.2.2)

On Tue, Oct 7, 2014 at 1:13 PM, Rob Trace <Rob.Trace@microsoft.com> 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

Received on Wednesday, 8 October 2014 01:06:45 UTC