Re: Alissa Cooper's Yes on draft-ietf-httpbis-http2-16: (with COMMENT)

Thanks Alissa, I have a few updates here:

I haven't done anything about a couple of your trickier comments.  If
you think that the explanations I've given suggests a need for text,
I'll see if I can work something out.

On 20 January 2015 at 13:54, Alissa Cooper <> wrote:

> = Section 3.1 =
> It might be worth keeping this sentence from the text that is marked for
> deletion:
> "Examples and text throughout the rest of this document use "h2" as a
>    matter of editorial convenience only."

Will do.

> = Section 3.2 =
> "A server that supports HTTP/2 can accept the upgrade with a 101
>    (Switching Protocols) response."
> Is there a reason why this behavior is not normatively described? Is
> there some other response that clients should expect that has the same
> semantic?

Mainly because trying to be normative here risks conflicting with
RFC7230, which we rely on for the real normative statements.  This is
really just a statement of fact at this point.

> = Section 5.1 =
> "WINDOW_UPDATE or RST_STREAM frames can be received in this state
>       for a short period after a DATA or HEADERS frame containing an
>       END_STREAM flag is sent. ...
>       endpoints MAY choose to treat frames that arrive a significant
>       time after sending END_STREAM as a connection error
>       (Section 5.4.1) of type PROTOCOL_ERROR."
> Can some ballpark guidance be given about how long "a short period" and
> "a significant time" are expected to be? Or how an implementation might
> calibrate these values?

This is tricky; a good implementation will maintain shallow send
buffers and so be able to respond to changes in state fairly quickly.
In that case, one RTT is enough.  However, keeping a buffer protects
against local hiccups and as soon as you buffer anything, you are
potentially subject to long stalls if packet loss or other problems

Maybe "significant" is 1RTT plus a complete CWND worth of received
data.  Even then I think that some implementations could buffer more
than that to allow them to encipher larger blocks.

> s/Frame of unknown types/Frames of unknown types/

I think you might be the 4th person to notice that gaffe.  That's how we roll :)

> = Section 5.2.2 =
> "Deployments that do not require this capability can advertise a flow
>    control window of the maximum size, incrementing the available space
>    when new data is received."
> I found this a little vague. Does this mean deployments can advertise a
> flow control window of size 2^31-1 and then locally increment available
> memory as new data is received? Would be good to state here both what the
> maximum size is and what is meant by "available space."

Would "advertise a flow control window of the maximum size (2^31-1),
and by maintaining this by sending a WINDOW_UPDATE frame when any data
is received."

> = Section 6.8 =
> s/the remote can know/the remote peer can know/

First!  Thanks.

> = Section 8.2 =
> s/that is not cacheable, unsafe or that/that is not cacheable, safe or
> that/

Second.  Julian noted the same flaw.  We currently have:

+ that is not cacheable, is not known to be safe or that indicates the
+ presence of a request body


> = Section 10.7 =
> "Intermediaries SHOULD retain padding for DATA frames, but MAY drop
>    padding for HEADERS and PUSH_PROMISE frames.  A valid reason for an
>    intermediary to change the amount of padding of frames is to improve
>    the protections that padding provides."
> The different recommendations for different frame types here are a bit
> puzzling. Why are intermediaries expected to be able to improve
> padding-based protection for HEADERS and PUSH_PROMISE frames more so than
> for DATA frames?

Noting that both are merely soft requirements; the available
protections are different.  The expectation is that header fields are
protected differently: HPACK defines a never-indexed encoding for
headers that is intended to be used outside of this.  An intermediary
is also highly likely to alter header fields and therefore needs to be
more intimately aware of the security consequences of altering length.

Do you think that a short note would help?

> = Section 10.8 =
> Is there anything more you could say about possible mitigations for the
> fingerprinting issue? Or there might not be, absent some coordination
> between endpoints, which would likewise be useful to note.

Without completely eliminating product differentiation at this
protocol layer, I think we're basically hosed.  Though the number of
new bits this exposes is probably relatively low.   I was reluctant to
put that in an RFC though.

I expect it to be possible to cut the exposure fairly easily for
instances of the same implementation (i.e., the Tor bundle) by
ensuring consistent behaviour and by adding a little noise to the
various signals (bucketing send times might help, for instance).
That's more of a research subject though.

Received on Wednesday, 21 January 2015 00:37:12 UTC