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

On Tue, May 12, 2015 at 07:34:18PM +1200, Amos Jeffries wrote:
> On 12/05/2015 5:06 p.m., Willy Tarreau wrote:
> > On Mon, May 11, 2015 at 05:07:31PM -0700, Martin Thomson wrote:
> >> On 11 May 2015 at 16:18, Amos Jeffries wrote:
> >>> I am more than a little surprised to find not one single mention of
> >>> proxy or cache middleware types or interoperability with them anywhere
> >>> within this document. Despite clear implications that it is intended for
> >>> use to secure data within CDN and other plain-text HTTP environments.
> >>
> >> Cleartext HTTP use cases are actually not intended for this, though
> >> I'm not opposed to adding any that make sense.
> > 
> > Well, you see, I've met people who designed and deployed their in-house
> > payload encryption mechanism in a banking environment where using plain
> > text for headers is mandatory to provide request routing capabilities
> > without giving the ability to decrypt data between the two extremities.
> > In fact many people use HTTP as a service-aware transport protocol on
> > top of TCP.
> > 
> > I can predict that you'll get requests for encrypting or at least signing
> > *some* header fields because these people had to do that when facing the
> > same use cases :-)
> 
> My take on that is that they should be able to use MIME syntax (or
> equivalent) within the encrypted payload to transmit additional object
> related headers.
> 
> The very act of encrypting any headers explicitly puts them out of scope
> of the transfer protocol (HTTP). So we dont need to care and should
> leave it undefined in this spec.

For encrypting, I agree, and I don't remember the exact use case (cookies
I believe though I'm not 100% certain). However signing headers will
certainly be used, but it doesn't require any specification if the
mechanism is agreed between two parties.

Willy

Received on Tuesday, 12 May 2015 08:06:57 UTC