Re: HTTP/2 extensibility <draft-ietf-httpbis-http2-17>

[Ben Niven-Jenkins <[e-mail]>]

Hi Bob,

> On 5 Mar 2015, at 12:55, Bob Briscoe <[e-mail]> wrote:
> For instance, a number of potential issues around DoS are left open.

Can you expand a bit more on what these DoS vectors might be or is it more of a general concern?

> If the protocol has to be hardened against new attacks, I believe the recommended extensibility path is to design and implement a completely new protocol release, then upgraded endpoints negotiate it during the initial handshake. The timescale for such a process is measured in years, during which the vulnerability has to be lived with. Surely we need more granular extensibility; to introduce new frame types and structures, and/or to deprecate outdated/vulnerable ones.

As Martin points out, I don't see how deployment of a new extension/frame type/etc is likely to be any faster than a new protocol release.

Anyway, if necessary there is nothing to stop a future RFC modifying the base behaviour without a new protocol release (along with all the complexities of backwards compatibility that go along with that) if that is what the WG decides to do at the time a vulnerability is discovered IMO.

Also as Martin points out dealing with the flexibility allowed by HTTP/1.1 is a royal PITA and leads to lots of extra rarely executed code paths to deal with the numerous corner cases.

> HTTP is important to us all. It has now become the only way to extend transport capabilities. The last thing we should do is build over the only pathway we have left with an evolutionary cul-de-sac.

I don't think HTTP/2.0 is perfect but for the use cases it addresses it is an improvement over HTTP/1.1. It'll be a long time (if ever) IMO before HTTP/2.0 completely supplants HTTP/1.1. In that time there is plenty of scope to evolve along a different path if that is what is required, so I don't see it as a cul-de-sac but merely one possible evolutionary path. Time will tell whether HTTP/2.0 becomes the dominant species or another evolution branches from HTTP/1.1 or HTTP/2.0 itself evolves.

Ben