Re: chunk-extensions

I've considered using them for a few things over the years. However, two things always stopped me; they aren't accommodated by Apis, and they aren't guaranteed to transit a hop. 

For the breach attacks, I don't think deprecating them harms things, since you can still sen them; in these mitigations, the payload / semantics don't matter, as long as something is there. 

Personally, I'm ok either way; the important thing is to document their behavior / limitations. Deprecation I one way to do that, but we could do it in prose too. 

From a chair perspective - we need to wrap this up. If we can get clean consensus to change quickly, great. Otherwise, lets leave it be. 

Sent from my iPhone

On 14/09/2013, at 8:01 AM, "Roy T. Fielding" <fielding@gbiv.com> wrote:

> On Oct 21, 2010, at 7:29 PM, Mark Nottingham wrote:
> 
>> What do people think about deprecating the use of chunk-extensions -- i.e., requiring that they be consumed, but not produced?
>> 
>>    chunk          = chunk-size *WSP [ chunk-ext ] CRLF
>>                     chunk-data CRLF
>>    chunk-size     = 1*HEXDIG
>>    last-chunk     = 1*("0") *WSP [ chunk-ext ] CRLF
>> 
>>    chunk-ext      = *( ";" *WSP chunk-ext-name
>>                        [ "=" chunk-ext-val ] *WSP )
>>    chunk-ext-name = token
>>    chunk-ext-val  = token / quoted-str-nf
>> 
>> I haven't seen any practical uses for them, and haven't seen any implementations that do anything with them other than throw them away.
> 
> http://trac.tools.ietf.org/wg/httpbis/trac/ticket/343
> 
> I know this was closed a long time ago, but I have never been
> comfortable with the idea of deprecating chunk-ext.  They were
> originally intended to allow per-chunk signatures or hashes,
> similar to those used in the Wave protocol.  More recently, they
> have been considered as a potential solution to BREACH-style
> attacks, specifically when a compression transfer encoding is
> used within a TLS-secured connection. [There are other solutions,
> of course, like changing the compression algorithms or changing
> TLS, but chunk-ext is easier to deploy on a per-hop basis.] 
> 
> I am concerned that we might be deprecating something that will
> be needed if we get widespread deployment of transfer-encoding
> compression (instead of content-encoding compression).  Moreover,
> recipients don't actually gain anything from this deprecation,
> since they have to continue parsing for chunk-ext to remain
> compatible.
> 
> Does anyone else share that concern?  It would be different if
> we knew of systems that actually break on receipt of chunk-ext,
> but I am not aware of any.
> 
> 
> Cheers,
> 
> Roy T. Fielding                     <http://roy.gbiv.com/>
> Senior Principal Scientist, Adobe   <https://www.adobe.com/>
>

Received on Friday, 13 September 2013 23:54:55 UTC