Re: Stuck in a train -- reading HTTP/2 draft.

Cherry-picking topics to respond:

On 17 June 2014 09:28, Martin Thomson <martin.thomson@gmail.com> wrote:

>
> >> From: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
>
> >> Page 28ff: Padding
> >> ------------------
> >>
> >> If padding is intended for obscuration of traffic patterns, it should
> >> be available in all frames to avoid "housekeeping" frames from leaking
> >> information about the relationships of other frames.
> >>
> >> For this reason I would make padding part of the framing format,
> >> rather than the individual message types.
> >>
> >> I'm also sceptical of demanding that padding be zeros, historically
> >> that has been a popular recipe for staring through compressions and
> >> encryptions.  I would probably specify that it is up to the sender
> >> to decide what to pad with, with guidance to prefer PRN bits rather
> >> than predictable (ie: zeros) or meaningful data.
>
> The guidance I've gotten is split regarding this point.  A known (zero
> or otherwise) padding allows for a weak cipher to be broken more
> easily.  Random padding on the other hand leaves you further exposed
> to bad integrity checks.
>
>
I am not a security person, and this is purely spit-balling, but how about
a hybrid? First n bytes must be <sentinel value, maybe zeroes>, remainder
is random/ignored.​ That way you get to detect bad packing, but also
hopefully get to mess with known-plaintext stuff. However it's more words
and more code, and I have no idea if it's worth it.



>
> >> Page 30  HEADERS/SEGMENTS
> >> -------
> >>
> >> What does END_SEGMENT do on a HEADERS frame ?
> >>
> >> It looks like Copy&Paste error.
>
> https://github.com/http2/http2-spec/issues/397
>
>
I still don't know where these segments come from. If it's a reference to
something from 1.1, a pointer would be very helpful; otherwise some sort of
motivating text or an exemplar is sorely lacking.



> >> Page 34: SETTINGS
> >> ------------------------
> >>
> >> Are we absolutely certain that we will never need per-stream SETTINGS ?
> >>
> >> At least I would specify SETTINGS with non-zero stream to be ignored
> >> so that we can open that later.
>
> I think that the easiest way around this would be to define a new
> setting that allows for the use of SETTINGS on streams.  If your peer
> sets that (on stream 0, of course), then you can start sending
> SETTINGS on streams.  That is, if you ever discover a need.
>
>
+1. Write it up as an extension setting and we keep the door open while
avoiding any YAGNI issues.


​
> >> Page 36: SETTINGS synchronization
> >> ---------------------------------
> >>
> >> This is utterly bogus.
> >>
> >> There is no way a SETTINGS frame can overtake any other frame while
> >> in transit, and there is no way the receiver can refuse the SETTINGS.
> >>
> >> There is also none of the settings which require synchronization between
> >> the ends or which the sender cannot prepare for before sending the
> >> SETTINGS frame.
> >>
> >> Simply demand that SETTINGS be applied atomically when received, before
> >> processing any subsequent frames and we're done.
> >>
> >> If the sender *really* wants to know that the SETTINGS has been
> >> registered in the far end, it can send a PING after the SETTINGS
> >> and wait for the PING+ACK.
> >>
> >> As it is now, SETTINGS causes the loss of an RTT if implemented as
> >> specified.
>
> That's not true.  You send SETTINGS, you carry on.  You only lose RTTs
> if you want to apply tight limits and then open them again.
>
> As for the rest, yes, this isn't 100% necessary, but it does give an
> endpoint the ability to say at what point a setting should have been
> respected.  Thus, if I set SETTINGS_MAX_CONCURRENT_STREAMS to 0, then
> I know that I can kill the connection when a new stream arrives.
>
> And the explicit acknowledgement allows for different implementation
> strategies.  We've already seen that people are enqueuing packets well
> ahead of what the underlying transport permits.  (That might be
> suboptimal in some respects, but I'm sure that these people know what
> they are doing.)
>
>
I agree with Martin. If I use my earlier per-frame compression as an
example: say I send the equivalent of SETTINGS[TE:gzip]. Then I find my
resources being starved, maybe I'm being zip-bombed, so I send
SETTINGS[TE:gzip;q=0]. If I'm being polite, I continue to accept gzipped
messages until I get the ACK; however if it is actually a DoS attack, the
ACK may never come, so I start a timer and use SETTINGS_TIMEOUT to bail.
 The advantage here is that I can use the same timer if I reduce my
SETTINGS_MAX_CONCURRENT_STREAMS, or send any other setting where in-flight
messages could cause an error. Because there's one timer, the spec is
simpler, and probably the code is simpler.



>
> >> I would allocate frame Type values so that the top bit indicates
> >> "subject to flow-control" to simplify implementation.  Similarly
> >> expending a bit to mark hop-to-hop frames would make life easier
> >> for high performance implementations.
>
> SPDY effectively did that.  Given the status quo, I'm not sure that
> (!type) and (type&mask) are measurably different performance-wise.
>
>
Wouldn't play nicely with extension frames; you'd need more rules about how
to forward unrecognised end-to-end frame types (not currently possible),
how to detect/mitigate jerks working around flow control ... actually, I
thought extension frames were all flow controlled, but apparently not. We
rely on extension authors to be honest and accurate about what extension
frames are flow-controlled.



> >> I also think it is a mistake to exempt the 8 byte frame header from
> >> the FCW:  You can fill a lot of pipe with 1 byte DATA frames when
> >> the overhead isn't counted.
>
> This is another place where the flow control window isn't usable.  It
> doesn't bother me a great deal.  It seems like there are bigger holes
> in this fence.
>
>
Indeed: ping -f



> >> Page 50: Error messages
> >> -----------------------
> >>
> >> The RFC should propose text-messages for presentation purposes
>
> I'm sure that people would welcome a contribution in this regard.
>
>
The equivalent of reason phrases attached to status codes, or something
richer? If the former, we kind of already have those (FLOW_CONTROL_ERROR,
STREAM_CLOSED, COMPRESSION_ERROR, etc.) if the latter, who wants to deal
with L10n?



> >> Page 51: Trailing headers
> >> -------------------------
> >>
> >> Support for trailing headers should have a bit in SETTINGS.
>
> I guess that we could do it.
> https://github.com/http2/http2-spec/issues/530
>
> Not sure if it will fly, but we can see.
>
>
To be honest, I'm surprised it isn't already a SETTING, and that the
corresponding Trailer:foo header doesn't have some way of being
communicated outside of the headers. I guess I should spelunk the archives
and minutes to read up on the discussions that resulted in almost all
hop-by-hop headers being replaced with settings or dropped, but left the
chunking stuff.


-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/