RE: #445: Transfer-codings

See responses in-line below...



On 04 April 2014 23:20, msweet@apple.com wrote:
> The origin server sets Content-Encoding and is able to make an informed
> decision about what content is compressed.  Intermediates are not supposed
> to change that.  But they *can* change Transfer-Encoding while still not
> knowing whether the content should be compressed.
>
On 04 April 2014 22:41, Martin Thomson Wrote:
> On 4 April 2014 13:36,  <K.Morgan@iaea.org> wrote:
>> If there are specific security issues related to gzip then they apply
>> equally to C-E gzip (which is implicitly required for clients to support
>> already). As we mentioned below, one of the benefits of using
>> TE/Transfer-Encoding over a framing layer transfer coding mechanism is
>> that the decision to TE compress can be made at the same level as deciding
>> to CE compress.
>
> This is not correct.  An origin server applies Content-Encoding.
> Transfer-Encoding is hop-by-hop.  As I pointed out previously, the
> entities applying T-E are likely to lack the contextual information
> required to make the right decisions regarding safe use of
> compression.

In response to both of you, I am either totally missing something or these security concerns related to an intermediary adding compression without contextual information are dubious.

The security concerns all relate to compression within a TLS/SSL tunnel, but:
 1) In a secure tunnel, the origin server is the only one that can apply a transfer encoding.  Intermediaries only see encrypted content and *can't change the transfer coding*.
 2) In the case of plain-text communication it doesn't matter if the intermediary adds or removes a transfer encoding.

The framing layer proposal, however, suffers from this security problem, even at the origin server, because the framing layer is likely unaware of the necessary contextual information.

On 04 April 2014 22:23, Martin Thomson wrote:
> On 4 April 2014 11:41,  <K.Morgan@iaea.org> wrote:
>> The proposals by Matthew and Mark get the job done, but they strike us as
>> more complex than TE/Transfer-Encoding...
>
> I don't agree.  Both are considerably simpler.

I disagree with your disagreement :)

Implementation requirements of TE/Transfer-Coding...
Servers: None if they don't want to support TE. To support TE: logic in parallel with the existing C-E logic to decide which type to use (i.e. whether to send the C-E or TE header) - use the same compression code as for C-E
Clients: if (is_content_encoding_gzip || is_transfer_encoding_gzip) decompress();

Implementation requirements of framing layer transfer codings:
Servers: At a minimum support a new setting. To fully support transfer coding: support new setting (including settings table for acceptable encodings); add logic at the framing layer to decide if content should be compressed; add flag and encoding bytes for each data frame
Clients: support a new setting; add parsing logic for flag/encoding; add logic at the framing layer to decompress content if necessary;
BTW, as the framing layer proposal now stands, the transfer coding compression can go in either direction so both sides would require the extra logic above for servers/clients.

On 04 April 2014 22:23, Martin Thomson wrote:
> ...we've removed hop-by-hop headers from HTTP/2.  I don't think
> that re-introducing them would be a good idea.

Why not? (Please be more specific.) I get why the other Connection hop-by-hop headers don't make sense, but why are transfer-encoding headers such a bad idea? We gave a list of 5+ benefits of using TE/Transfer-Encoding.


> On Apr 4, 2014, at 2:41 PM, K.Morgan@iaea.org<mailto:K.Morgan@iaea.org> wrote:
>
>
> The proposals by Matthew and Mark get the job done, but they strike us as more complex than TE/Transfer-Encoding...
>
>
>
> A (partial) list of benefits of TE/Transfer-Encoding (over framing layer transfer coding):
>
>     1.  TE/Transfer-Encoding doesn't require any changes at the HTTP/2 framing layer!!!
>
>     2.  Since TE and Transfer-Encoding are headers, the decision to compress can be made closer to the application layer.
>
>          a. i.e. this makes it easier to decide when to compress.
>
>          b. It also makes it less likely that double compression will occur.
>
>          c. This also covers Martin’s concern that “an entity performing compression has knowledge of what is being compressed and is therefore able to more accurately determine whether compression is safe to use.”
>
>     3. Retains the extensibility to support new compression algorithms (with all the same benefits Matthew mentioned in [1]).
>
>     4. With TE/Transfer-Encoding, only clients have a new requirement. Servers that don’t want to support Transfer-Encoding don’t have to do anything except ignore TE headers.
>
>     5. Since TE/Transfer-Encoding is already part of the HTTP/1.1 spec, 1.1 clients could benefit from this compression when talking to a 1.1<->2 intermediary by implementing TE/Transfer-Encoding; relieving intermediaries of the burden to decompress; and save bandwidth.
>
>
>
> We submit the following alternative proposal for consideration:
>
>
>
> 9.4 Transfer-Encoding
>
>
>
> HTTP/2 retains the semantics of HTTP/1.1 regarding transfer codings (see [HTTP-p1]<http://http2.github.io/http2-spec/#HTTP-p1>, Section 4<https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/26/p1-messaging.html#transfer.codings>), with the following additional requirements. Servers MUST NOT use chunked transfer coding. Clients MUST support “gzip” transfer coding. If the "TE" request header field-value is empty or if no TE field is present, the only acceptable transfer coding is "gzip".
>
>
>
>
> In earlier threads, Roy Fielding gave his support for compression transfer codings, including implicitly requiring clients to understand (decompress) gzip transfer encoding (our apologies to Roy for quoting him so often):
>
>
>
> “I would not require [gzip transfer coding] to be used -- just make it possible to be used and required to understand (decompress by recipient).  This is what you already do with HTTP/2…” [2]
>
>
>
> “… it isn't virtually impossible to introduce standard transfer codings.  It just requires effort by browsers to support one. It also isn't necessary to restrict HTTP/2 features to what a current browser supports.” [2]
>
>
>
> “Transfer compression has limited deployment but actually does work when it is deployed by consenting adults.  You can change that deployment in HTTP/2. It is well within scope.” [3]
>
>
>
>
> (We redact our earlier proposal [4] which had several flaws.)
>
>
>
> [1] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0067.html
>
> [2] http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/1203.html
>
> [3] http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/1189.html
>
> [4] http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/1205.html

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 Friday, 4 April 2014 22:21:46 UTC