Re: #445: Transfer-Codings

Sounds reasonable to me. Would that imply that all frames within a segment must be compressed or not compressed? i.e. would it be an error to have the compress flag vary from frame to frame within a segment? (That would imply a receiver has to keep state per segment to remember the flag.)

-Keith


On Apr 24, 2014, at 20:56, "jgraettinger@chromium.org<mailto:jgraettinger@chromium.org>" <jgraettinger@chromium.org<mailto:jgraettinger@chromium.org>> wrote:

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<mailto:martin.thomson@gmail.com>> wrote:
On 24 April 2014 02:26,  <K.Morgan@iaea.org<mailto: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.



This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

Received on Thursday, 24 April 2014 20:00:12 UTC