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

On Tue, May 12, 2015 at 06:35:06PM +0000, Poul-Henning Kamp wrote:
> --------
> In message <20150512181651.GH6738@1wt.eu>, Willy Tarreau writes:
> 
> >> 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.
> 
> >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.
> 
> Exactly.  This is why I say that encryption goes first: The moment
> you perform the encryption, all metadata except for the encryption
> parameters disappear, and you get an entirely new message.

OK it was a matter of wording/understanding then, let's say
interoperability between the sender and the receiver :-)

> We have to decide precisly how far that goes however, does an plaintext
> 403 response arrive as an encrypted 200 response which only reveal its
> true colors on decryption ?

I'd rather not start to play with status nor hop-by-hop headers. But on
the other hand, if some headers have to be encrypted even when there's no
contents, you don't want to return a 204/304 implying that content-length
can be ignored and return data after it :-/

And a 304 in response to a HEAD request must not reveal the plaintext
headers that would have been encrypted in response to the equivalent
GET request if it is assumed that these ones can reveal sensitive info.

I'm sorry I haven't read the proposal yet so maybe I'm talking about things
that are already covered, thus I'll rather stop speculating.

> It follows from this that if you receive a message with both
> (Content-)Encryption and Range it means:
> 
> 	Range(encryption(plaintext))
> 
> and if you get Encryption, Range and C-E: gzip it means
> 
> 	Range(gzip(encryption(plaintext))
> 
> so as to not reveal anything about the plaintext.

Good point.

> >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.
> 
> It is problematic if "gzip, aesbla" and "aesbla, gzip" means different
> things.

Except that "gzip, aesbla" cannot happen since whatever appears before
"aesbla" would have been moved into the encrypted body. Thus "aesbla, gzip"
means that gzip has been applied after aesbla. Whether or not the client
can decode it before decrypting is another story, of course.

> C-E is defined today as giving them different meanings, so either
> we have to add veribiage which mandates that "aesbla" always must
> be first in the C-E,

It will if the previous C-E moves to the body during the encryption
process.

> or (better) avoid the issue by not involving C-E.

Since it's clearly a change in the representation I still do find this
field appropriate for this use-case. There's no difference between
"aesbla" and "gzip" in terms of operations except that one uses some
extra parameters.

> The fact that encryption needs to care about metadata means that it
> is not really a "Content-Encoding" but rather a "Message-Encoding".

That's a possibility as well, though I'm not convinced that it brings
anything beyond C-E above.

Willy

Received on Tuesday, 12 May 2015 18:47:13 UTC