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

Hi Poul-Henning,

On Tue, May 12, 2015 at 12:56:16PM +0000, Poul-Henning Kamp wrote:
> --------
> In message <5551F31A.2000404@cs.tcd.ie>, Stephen Farrell writes:
> 
> >In other contexts, we've seen that people talk about use-cases
> >for signing and even deploy signing, but verification can lag
> >significantly behind, which can make the whole effort somewhat
> >pointless.
> 
> Agree, there are plenty of wrecks in the road-side, but the other
> side of that problem is that people end up rolling their own because
> there is no standard.
> 
> I personally think this is the privacy area we should have focused
> on, rather than the blunt weapon of "SSL-everywhere", because
> this does not conflict with laws and disable caching to the same
> degree.
> 
> However, it is not obvious to me that it is a good idea to involve
> the Content-Encoding at all, whereas I see several downsides.
> 
> For instance we cannot Vary: on just the aesgcm-128 part of the C-E
> header, and since the Encryption: header is just noise without the
> qualifying C-E element, varying on just Encryption: is not a good
> idea.
> 
> Leaving C-E entirely out of the picture will make no difference in
> any scenario I can come up with (Please enlighten me if such scenarios
> exist).
> 
> I think it would make much more sense to concentrate all the relevant
> information in a single new header (Content-Encryption ?) which would
> make Vary "just work".

Interesting. But it would make it harder for a recipient to identify
in what order to apply transformations then if both content-encoding
and content-encryption are set. Imagine two servers communicating
together over encrypting gateways, which would apply their own algo
to be safe on their local networks, and the gateways would apply a
stronger one on to of this over the WAN, after base64-ing the contents.

I know this is totally made up and highly stupid, but it's just to give
an idea. If the protocol is successful, and we encourage to work well
with intermediaries, then we could expect to see adoption at several
levels in some institutions where encryption keys are assigned to
different internal business units, leading to encapsulation. In this
case I think that content-encoding alone would remove any confusion.

Not that I'm encouraging to do dirty practices, but rather that we
manage to make the thing robust against such practices.

> This would also make the obvious "Accept-Encryption" negotiation
> header possible.

That could be a good point.

Regards,
Willy

Received on Tuesday, 12 May 2015 13:14:50 UTC