Re: Striving for Compromise (Consensus?)

>
> >> 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.