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

[Bob Briscoe <[e-mail]>]

HTTP/2 folks,

I've reviewed the whole draft. I know the draft has just successfully 
passed IESG review, but I hope this posting is still useful.

My credentials for this: first role in the IETF in 1995 was to ensure 
HTTP/1.1 generalised from Web pages to objects, but for the last 15 
years my focus has shifted down the layers into transport.
Non-credentials: I've been paying insufficient attention to HTTP/2 
until now, but I have tried to research back over the ML for the 
rationale behind design decisions.

So consider this as a late review from a clueful but fresh pair of eyes.

My main concerns are
* extensibility
* flow control
* numerous open issues left dangling
I'll cover extensibility here, and my other concerns (as well as 
nits) in subsequent posting.


Achieving this milestone on time has been impressive. I understand 
the reasons for having to get something standardised. However, I see 
potential problems. And that would be fine, but only if there were a 
more granular mechanism to extend the protocol to fix it in future.

For instance, a number of potential issues around DoS are left open. 
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.

Rather than a blanket statement saying that an endpoint discards and 
ignores a frame type that it does not recognise, we should include a 
field in the generic frame header to specify this behaviour. In this 
way, the currently defined extensibility behaviour could be required 
or relaxed depending on what the future brings - instead of having to 
decide the extensibility model now.

This would be safe, because the worst an attacker can do is inject a 
new unrecognised header and get it forwarded, but not acted on. 
Unless it is a type known to at least one implementation, it will 
never be acted on.

The same point applies to extending known frame types. There is no 
point having a length field on frames if any length other than that 
specified produces a FRAME_SIZE_ERROR. For extensibility, a frame 
with an unexpected length should at least be ignored, rather than 
leading to a stream error. Ideally, similar to above, there should be 
a field that specifies what action to take (forward or not) if the 
structure of the frame type is unrecognised.

One of the greatest strengths of HTTP/1.x was the general rule about 
unrecognised headers, which enabled 'a thousand flowers to bloom'. 
The few most beautiful ones survived. If evolution can only proceed 
in giant steps, the natural selection process will be glacially slow.

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.



Bob


________________________________________________________________
Bob Briscoe,                                                  BT