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

On Tue, May 12, 2015 at 05:44:04PM +0000, Poul-Henning Kamp wrote:
> --------
> 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.

Well, thinking about it, C-E, C-T, range, etc are the body's meta-data
so they should be hidden from the clear-text headers and encrypted with
the body.

Regarding the fact that the transported contents must not be compressed,
I disagree here. If we encrypt, it's in order to protect the transported
data, regardless of that data. We will never decide what type of data a
server sends, and if you want to send a tar.gz or a PNG with different
compression levels, you must be allowed to do so. However I agree that
you don't want to reveal a single bit about what's inside.

So I tend to think now that moving all entity headers to the body (including
C-E) and using a separate header to indicate what's being compressed makes
sense.  You ask for a blob, you get a blob and until you decipher it, you
cannot tell how it was made nor what it contains.

At this point, reusing Content-Encoding to indicate the envelope's format
doesn't seem problematic at all to me since any previous occurrence of it
would have moved inside the body.

Regards,
Willy

Received on Tuesday, 12 May 2015 18:17:28 UTC