W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: Striving for Compromise (Consensus?)

From: Johnny Graettinger <jgraettinger@chromium.org>
Date: Fri, 11 Jul 2014 15:06:31 -0400
Message-ID: <CAEn92ToUOsR6rtt691TecqgccjTFU6FJ2LZkTtzHVnkFmVSUTQ@mail.gmail.com>
To: Jason Greene <jason.greene@redhat.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, Greg Wilkins <gregw@intalio.com>, Jeff Pinner <jpinner@twitter.com>, HTTP Working Group <ietf-http-wg@w3.org>
> >> Ok in that case, Roberto’s analysis does not prove what you say it does.
> >
> > I'm pretty sure that it does.
> >
> > This point:
> >> The current design handles this fairly well, at most one set of headers
> can
> >> be incomplete at any point in time (sending a large number of incomplete
> >> headers and keeping most of them incomplete most of the time is an
> >> excellent attack vector, which the design currently precludes).
> This is the flaw:
> "1) Stalling a connection by never finishing the sending of a full set of
> headers.
> I don't find #1 interesting, since the attacker is mostly just attacking
> themselves"
> If you coalesce connections there are N users per connection. Thats a real
> problem you can’t just wave away.

Without interleaving, such a proxy coalescing un-trusted users must buffer
at most *one* set of incomplete request headers per-user before forwarding.
As you note, it can't forward fragments. This prevents an attacker from
impacting other coalesced clients.

But with interleaving, such a proxy must buffer M different sets of
incomplete request headers for each of N different users. Requiring that
:headers appear in the first frame increases the likelihood that the proxy
is able to incrementally forward, but it doesn't eliminate it (again,
consider a reverse proxy routing on a session cookie). The only bound on M
right now is the stream concurrency limit, which is large.
Received on Friday, 11 July 2014 19:06:59 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC