Re: New Version Notification for draft-kerwin-http2-encoded-data-01.txt

Actually, it is an issue, so long as there is no ordering requirement on
extension frames (as we'd have had with END_SEGMENT).

We've not imposed (actually removed) such restrictions on proxies, and so
we may find that there is no way to do it in the future. That would be a
sad day.
-=R


On Tue, Jul 22, 2014 at 9:51 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:

> On 23/07/2014 12:26 p.m., Matthew Kerwin wrote:
> > On 23 July 2014 09:14, Greg Wilkins <gregw@intalio.com> wrote:
> >
> >>
> >> Matthew,
> >>
> >> why are the compression contexts frame only?    Doesn't that make this
> >> extension very vulnerable to fragmentation, specially if we drop
> >> END_SEGMENT as we have done.
> >> ​
> >> ​
> >>
> >> ​
> >> ​
> >> Surely there is no harm in having a compression context that is per
> stream?
> >>
> >>
> > The two main reasons were CRIME/BREACH attacks, and to limit the state
> > commitment, particularly when transport-level compression was part of the
> > main spec. I'm trying to dig up a reference to the conversation that lead
> > to it; here's one cherry I've picked from the archives, which might be a
> > starting point back from which to work:
> > http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0297.html
> Three
> > months is such a long time ago, on the internet. :\
> >
> > Incidentally, END_SEGMENT had potential to enforce useful fragmentation
> --
> > i.e. avoiding a CRIME/BREACH attack by separating secret and
> > attacker-controlled data with an end-to-end barrier -- if the END_SEGMENT
> > mechanism was exposed to the origin application.
>
> Fragmentation is not a problem. There are two obvious options from using
> a new extension frame type; either 1) define the frame as
> non-fragmentable, or 2) containing an END_SEGMENT flag.
>
> Amos
>
>