Re: New Version Notification for draft-thomson-http-encryption-00.txt

On 13/05/2015 1:28 a.m., Poul-Henning Kamp wrote:
> Willy Tarreau writes:
> 
>>> Leaving C-E entirely out of the picture will make no difference in
>>> any scenario I can come up with (Please enlighten me if such scenarios
>>> exist).
>>>
>>> I think it would make much more sense to concentrate all the relevant
>>> information in a single new header (Content-Encryption ?) which would
>>> make Vary "just work".
>>
>> Interesting. But it would make it harder for a recipient to identify
>> in what order to apply transformations then if both content-encoding
>> and content-encryption are set.
> 
> Encryption first.

No, they may be applied by different layers at different times. A dumb
legacy intermediary may arbitrarily gzip everything going through it.

I agree with Willy here for the reasons he stated and the below as well.


I checked over the Vary situation earlier and do not find a huge problem.

* The Diffi-Helmen / dh= keying (section 4.2 form) requires Vary:*
because the key material is out of band. But so would gzip encoding with
an out-of-band dictionary to seed it.

* The explicit key= material (section 4.1 form) response can use
Vary:Accept-Encoding. Since the IKM is part of the response variant
headers it does not matter which client you send the pair to - all
clients will be able to decode using that key or not be able to with any
key (IKM provided was the *senders* part).

As you can see it does work if you get the cases right. But needs to be
stated in the spec so we and others dont have to individually figure it
out - making various mistakes along the way.


> 
> If you allow a client to retrieve get both a encrypt(plaintext) and
> encrypt(gzip(plaintext)) at their choice, you have revealed information
> about the payload which should be secret.

I note that it was your proposal to add Content/Accept-Encryption
separately from *-Encoding which allows this flaw you are now pointing
out. The -00 draft lacks this flaw.

When the two are using Accept-Encoding the Vary header will only contain
Vary:Accept-Encoding. Which is agnostic to compression vs encryption and
does not permit the client to control the gzip+aesgcm-128 case. The
server gets to choose to emit only gzip(plaintext) vs
encrypted(plaintext) for any variant.

Vary:Accept-Encoding,Accept-Encryption is the format which allows client
the most control of selection between encrypt(gzip(plaintext)) vs
encrypt(plaintext) by requiring the server to deal with permutations of
the cases.
 * it is also more verbose in both number of variants in play for
caching, and in bandwidth bytes used by headers.


> 
> If you waste CPU cycles gzip'ing the ciphertext you only harm your
> CO2 footprint.

Having two headers implicitly encourages using both. Having one header
and having to deal with these problems encourages getting it right
without forcing a particular viewpoint on everyone.


> 
> If people want to save bandwidth with compression, they have to compress
> before the encryption, and include the bit which says "compressed" in
> the plaintext passed to the encryption algorithm.
> 

True. That is something that probably also should be mentioned. Its a
good incentive and reason for implementers to make the right choice.

Amos

Received on Tuesday, 12 May 2015 16:35:49 UTC