- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Tue, 12 May 2015 17:44:04 +0000
- To: Amos Jeffries <squid3@treenet.co.nz>
- cc: Willy Tarreau <w@1wt.eu>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, Mark Nottingham <mnot@mnot.net>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
-------- In message <55522BBF.9060404@treenet.co.nz>, Amos Jeffries writes: >On 13/05/2015 1:28 a.m., Poul-Henning Kamp wrote: >> Encryption first. > >No, they may be applied by different layers at different times. A dumb >legacy intermediary may arbitrarily gzip everything going through it. So this is one of the reasons I think overloading C-E is a bad idea. It adds a cryptographic weakness if C-E: aesbla, gzip and C-E: gzip, aesbla mean different things. In the transmitted headers, an attacker is welcome to be able to tell the difference between aesbla(plaintext) and gzip(aesbla(plaintext)) since that doesn't reveal anything about the plaintext. (Never mind that this is waste of CPU cycles, same thing goes for JPEG). But the attacker should not be able to tell the difference between: aesbla(plaintext) and aesbla(gzip(plaintext)) since that would leak information, and she should *absolutely not* be able to force this distinction herself by sending an Accept-Encoding header. Therefore I think we should leave the Content-Encoding header alone and add a new Content-Encryption header, so that the order is not defined in what you find in the headers, but by what headers you find. Notice that Range is not in C-E for the very same reason: By pulling it out of C-E its exact placement in the pipeline gets nailed down. -- 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 17:44:30 UTC