Re: Requiring TLS 1.3 as alternative to HTTP/2 section 9.2.2

Hi, Dave. This is just my opinion

HTTP, whether /1 or /2 is not unique. If anything, HTTP/1 is more
vulnerable to all sorts of attacks because of the COOKIE that is attached
to every request.

On Tue, Oct 28, 2014 at 3:42 AM, Dave Garrett <davemgarrett@gmail.com>
wrote:

> It looks like HTTP/2 section 9.2.2 is on the chopping block, with little
> push-back thus far, so I'm going to ask the obvious question: what's going
> to replace it?
>

IMO nothing.  TLS is deprecating RC4, standardizing encrypt-then-mac,
adding new AEAD ciphers, etc. These decisions make HTTP/2 more secure right
along with HTTP/1, SMTP, LDAP and all other protocols that use TLS. HTTP/2
is not a special case.

Attempting to enforce cipher requirements here is problematic, however
> removing these requirements will also add its own interoperability
> problems. If a server were to follow the spec without these requirements,
> then a browser that already implements them will reject the connection.
> Unless everyone is also going to pledge to remove already implemented
> security checks, this will be an issue. Without 9.2.2, even RC4 is valid
> for HTTP/2 traffic, which seems like something implementors would fight
> against introducing.
>

RC4 is no more dangerous to HTTP/2 than it is to HTTP/1.

There were a few people that suggested simply waiting for TLS 1.3 and
> requiring that instead of TLS 1.2 plus a series of hacks. Is it possible to
> fast-track TLS 1.3 from its current draft to standardization for HTTP/2,
> and move further TLS development to 1.4? This is the simplest solution and
> obsoletes almost all of section 9.2, not just 9.2.2.
>

TLS 1.3 is just getting started whereas HTTP/2 is almost done. I estimate
at least a year before TLS 1.3 is done, and I don't think HTTP/2 proponents
want to wait that long.


>
> I guess the real question is: can two working groups work together here?
>
> They can, but standardization takes time.

Yoav