Subject: HTTP/2 States and Frame Types <draft-ietf-httpbis-http2-17>

From: Bob Briscoe <[email-masked]>
Date: Fri, 6 Mar 2015 19:05:18 +0000

Co-authors & editors,

This is the last of my review postings.

We're working on a generic framing protocol within the TCP Data. The 
main reason I was reading HTTP/2 was to understand it as a set of 
requirements for what we're doing. I don't expect many (any?) of the 
comments below to change the protocol spec, but if someone could 
spare the time to answer my questions, it will help us understand 
what you were trying to do with HTTP/2, so we can better meet its 
needs in future.

I found it very hard to understand the HTTP/2 spec, because it was 
largely a stream of assertions, with hardly any rationale. I read a 
book on SPDY to try to understand some of the rationale, but I got a 
similar barrage of assertions.

All that said, you might want to try to improve the spec with some of 
these answers, because poor comprehensibility leads to bugs, 
particularly bearing in mind non-English implementers need to 
understand the spec too.

Apologies if these questions have been raised before. I tried to 
check with a quick search of the archives and I read the IESG 
reviews, but I may have missed stuff.

<https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-2.1>2.1. 
Document Organization
"...this specification does not define a completely generic framing layer..."

Given the prevalence of HTTP, was the design of HTTP/2 framing 
designed for hardware (or software) offload (i.e. required to be 
possible to implement separately from the contents of the frames)? 
Was this a requirement? It's not mentioned. I'm sure it will be done 
now that HTTP/2 is specified.

A great shame it won't be generic, but that's water under the bridge now.

<https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-5.1.2>5.1.2. 
Stream Concurrency
"   Streams in either of the "reserved" states do not count toward the
    stream limit."
Why? Once reserved, they require stream state.
In fact, it would be useful to enumerate the amount of state needed 
for each stream.

<https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-6>6. 
Frame Definitions
Why the particular set of frame types, and not more or less?

This raises the question of why the frame types have all been defined 
as completely independent. A multi-part frame structure could have 
been used that constrains the order of frames to that required (I've 
done a back of envelope design for this). Without structural ordering 
constraints, it will be necessary to define a very large number of 
ordering errors (many more than the draft currently states).

<https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-6.1>6.1. DATA
Why does padding have to be filled with zeros? There are good 
cryptographic reasons for not requiring this. And random padding 
could help ensure that retransmissions are significantly different 
from the original transmission.

Why is the pad length and padding field included in flow control? An 
http receiver (client or intermediate) can discard padding without 
consuming buffer memory, and an intermediate node can then 
reconstruct (a potentially different amount of) padding.

<https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-6.2>6.2. 
HEADERS
Why is the END_HEADERS flag needed? Given HEADERS frames MUST be 
contiguous, why can't the Length field of the HEADERS frame specify 
the length of one frame for all http headers, without all the 
complexity of CONTINUATION frames and an END_HEADERS flag?

<https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-5.3.5>5.3.5. 
Default Priorities
Why is the default stream weight 16?

<https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-6.3>6.3. 
PRIORITY
"The PRIORITY frame can be sent on a stream in any state, though it
    cannot be sent between consecutive frames that comprise a single
    header block"
Why?

<https://tools.ietf.org/html/draft-ietf-httpbis-http2-16#section-6.5>6.5. 
SETTINGS
"     ACK (0x1):  [...] When this
       bit is set, the payload of the SETTINGS frame MUST be empty.
       Receipt of a SETTINGS frame with the ACK flag set and a length
       field value other than 0 MUST be treated as a connection error
"
Why? It would be more efficient, and surely cause no harm, to ack on 
the same frame as sending a setting in the other direction.

<https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-6.6>6.6. 
PUSH_PROMISE
Why is the whole PUSH_PROMISES approach needed? Given a request 
doesn't have to use the same stream ID as a response.

<https://tools.ietf.org/html/draft-ietf-httpbis-http2-17#section-6.7>6.7. PING

I don't see the point of the two apparently arbitrary restrictions below.

"  PING frames are not associated with any individual stream.
"
Why prevent an implementer from monitoring the round trip of a specific stream?

"  PING responses SHOULD be given higher priority than any
    other frame.
"
This prevents an implementation from using PING to measure the buffer 
that all other frames have to endure.

Bob

________________________________________________________________
Bob Briscoe,                                                  BT

---

From: Martin Thomson <[email-masked]>
Date: Fri, 6 Mar 2015 11:23:16 -0800

On 6 March 2015 at 11:05, Bob Briscoe <[email-masked]> wrote:
> Why does padding have to be filled with zeros? There are good cryptographic
> reasons for not requiring this.

Remember POODLE, I think that the opposite is true.  Also c.f. IND-CCA
(and IND-CCA2).

---

From: Bob Briscoe <[email-masked]>
Date: Sat, 7 Mar 2015 15:15:33 +0000

Martin,

Don't listen to me on cryptography, I don't 
follow it. I'm probably out of date.

Nonetheless, I just skimmed the POODLE paper 
[Möller14]. From my reading, POODLE surely only 
applies to padding that is beyond the coverage of 
the MAC (i.e. which necessarily has to have been 
added while encrypting). I don't think these 
chosen ciphertext attacks (CCAs) apply to HTTP/2 
padding, because the HTTP/2 padding is in the 
layer below the encryption process, so it will 
surely always be covered by the MAC.

If, as in HTTP/2, the length of the padding field 
is given in the protocol header (which is then 
encrypted), I believe the padding can be 
arbitrary, and I assume it's best for the padding 
not to be structured (predictable).

But please don't take my word for it - crypto is not my field.

[Möller14] Möller, Bodo; Duong, Thai; Kotowicz, 
Krzysztof, "This POODLE Bites: Exploiting The SSL 
3.0 Fallback" (September 2014). <https://www.openssl.org/~bodo/ssl-poodle.pdf>

Bob

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 7 Mar 2015 17:45:40 +0200

On Sat, Mar 07, 2015 at 03:15:33PM +0000, Bob Briscoe wrote:
> 
> If, as in HTTP/2, the length of the padding field is given in the protocol
> header (which is then encrypted), I believe the padding can be arbitrary,
> and I assume it's best for the padding not to be structured (predictable).

Any encryption algorithm that is anywhere even near secure can easily
deal with predictable padding (any that have problem with it should be
phased out immediately). Protocols are usually full of known plaintext
anyway.

And random padding actually causes problems (possibility of data
leakage).

-Ilari