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

--------
In message <20150512184635.GL6738@1wt.eu>, Willy Tarreau writes:

>> 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.

They are not.

>Except that "gzip, aesbla" cannot happen since whatever appears before
>"aesbla" would have been moved into the encrypted body.

s/would/SHOULD/

There's no guarantee against people doing stupid things.

>> 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.

I think it would bring clarity.

-- 
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 18:50:36 UTC