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

My .02 - 

I'm somewhat wary of putting the requirements of every possible use case on the shoulders of one mechanism, as I see that as a recipe for boiling the ocean and subsequent failure. Arguably, this is what's been happening in Web authentication for quite some time now.

On the other hand, it would be good if we make sure we don't needlessly block reuse. E.g., it would be good if this were aligned with something like <https://tools.ietf.org/html/draft-cavage-http-signatures> (although we should be wary of what a minefield header signing has proven to be elsewhere). It might make sense to consider taking them on together.

Willy, Amos - how do you think this spec *should* talk about intermediaries? As specified, the HTTP caching model is still usable, and of course proxies are still capable of working with them. What else do you see as missing?

I can see is that it might be prudent to add Cache-Control: no-transform to the message, but then again an intermediary that transforms bodies with C-E that it doesn't understand kind of deserves what it gets, IMO…

Cheers,


> On 12 May 2015, at 3:06 pm, Willy Tarreau <w@1wt.eu> wrote:
> 
> On Mon, May 11, 2015 at 05:07:31PM -0700, Martin Thomson wrote:
>> On 11 May 2015 at 16:18, Amos Jeffries <squid3@treenet.co.nz> 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 :-)
> 
> I hope to find some time to review your work, that sounds interesting and
> useful.
> 
> Thanks,
> Willy
> 
> 

--
Mark Nottingham   https://www.mnot.net/

Received on Tuesday, 12 May 2015 07:30:37 UTC