Re: #445: Transfer-Codings

This requirement to not merge does appear to be in tension with Martin's
point on the "Frame Length Restrictions" thread, that a padding
intermediary is able to re-frame to 16K - 9 bytes to achieve an arbitrary
padding distribution.

Conceptually, the "don't merge" and "don't compress" requirements impose
new implicit end-to-end boundaries in the data stream (for each compression
context). Perhaps it would be preferable to use the existing segment
mechanism instead? Eg, compression is per-frame, but intermediaries may
re-frame and re-compress within a segment iff the origin also compressed
that segment.

There was some concern on the the other thread about the delineation of
secret vs attacker-controlled segments being difficult for clients/servers,
but I'm unclear how coupling compression boundaries to frames helps this.
If an implementation doesn't have enough information to segment, surely it
also doesn't have enough to identify frame boundaries appropriately?

thanks,
-johnny


On Thu, Apr 24, 2014 at 10:57 AM, Martin Thomson
<martin.thomson@gmail.com>wrote:

> On 24 April 2014 02:26,  <K.Morgan@iaea.org> wrote:
> > however the uncompressed data from separate frames MUST NOT be merged.
> > Merging uncompressed data from separate frames creates a shared
> compression
> > context that could allow an attacker to recover secret data if merging
> > combines confidential and attacker-controlled data.
>
> My first impression was that you have too much text there, but this
> point is valuable.  I had to ship -12, but I'll add this to the
> editor's copy in preparation for -13.
>
> Note that this is only an issue if the merged data is subsequently
> compressed.
>
> I think that the text could more succinctly say:
>
> [...] frames that are separately compressed cannot be merged into a
> single compressed frame.  Either could result in the compression of
> secret and attacker-controlled data within the same compression
> context.  Compressed frames MAY be decompressed, in whole or part.
>
> I'm less certain about making the downstream intermediary point so
> explicit.   There's a balance to be struck.  There are plenty of other
> places where our prohibitions are less-well explained than this
> already is.  This is a fractal landscape, and we try to avoid
> exhaustively exploring all the minute details in the interests of
> readability and accessibility.
>
>