W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

Re: Encryption simplification

From: Willy Tarreau <w@1wt.eu>
Date: Mon, 31 Oct 2016 07:51:10 +0100
To: Martin Thomson <martin.thomson@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20161031065110.GA17020@1wt.eu>
Hi Martin,

On Sun, Oct 30, 2016 at 09:22:26PM +1100, Martin Thomson wrote:
> After discussion about content codings, I've made something of a
> drastic change to the encryption draft.  A preview is here:
>     http://httpwg.org/http-extensions/encryption-preview.html
> 
> The pull request is here:
>     https://github.com/httpwg/http-extensions/pull/252
> 
> This is a huge simplification in many ways, so I think that's a fair
> improvement.
> 
> The main assertion that this assumes is this: content codings should
> be self-descriptive.
> 
> Obviously, this isn't a strong assertion given that this content
> coding requires a key, and SDCH relies on having an external
> dictionary, but the point is that the contents of the message can be
> decoded without reading additional header fields.  This is consistent
> with the observation that James Manger made about the MICE content
> coding previously [1].
> 
> To that end, I've removed the Encryption header field and packed the
> critical data into the content itself.  This is more efficient and
> avoids strange cross-header-field correlation between Encryption and
> Content-Encoding.  It retains Crypto-Key and key identifiers, but
> that's necessary since they generally travel separately.

I like it. I think it is well designed and even suspect that if it
succeeds we'll see an update later to move some payload-specific
metadata which currently stand in headers into the encrypted block
(I don't have good examples right now but have faced this need in
the past -- we may for example think about the content's title and
author or the location where a photo was taken). But for now I think
it efficiently covers what it aims to.

Good job!
Willy
Received on Monday, 31 October 2016 06:51:40 UTC

This archive was generated by hypermail 2.3.1 : Monday, 31 October 2016 06:51:43 UTC