- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Tue, 12 May 2015 13:28:04 +0000
- To: Willy Tarreau <w@1wt.eu>
- cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Mark Nottingham <mnot@mnot.net>, Martin Thomson <martin.thomson@gmail.com>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
-------- In message <20150512131405.GF6738@1wt.eu>, 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. 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. If you waste CPU cycles gzip'ing the ciphertext you only harm your CO2 footprint. 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. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Received on Tuesday, 12 May 2015 13:28:29 UTC