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

Hi Mark,

On Tue, May 12, 2015 at 05:30:05PM +1000, Mark Nottingham wrote:
> 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.

Yes, over-designing is the first step to massive failure.

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

>From my point of view, HTTP gateways must continue to work normally, and I'm
no seeing significant risks by encrypting a payload since gateways generally
do not even "see" this payload. Maybe we should be careful about those which
can compress contents however. First, compression should be discouraged in
such a case as it will be useless (or the encryption has a serious flaw),
and second it could hurt the recipient's ability to extract the data. Note
that if a client supporting an encrypted response payload sets gzip in
Accept-Encoding, it probably means it's willing to decompress *after*
decryption, so the content-encoding in the response will reflect the
series of transformations and a compressing intermediary will not be
tempted to compress again. Some might be tempted to recompress better and
might skip unknown tokens in content-encoding. It would be prudent to remind
the reader that an intermediary must not touch certain header fields (eg:
content-encoding again), and/or be precise in the way the recipient must
understand the fields if they come as a list because an intermediary has
appended another level of transformation. But that's normally covered by
the HTTP spec.

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

Yes very likely since this covers the intended use case. I think that
intermediaries located between two agents encrypting a payload over clear
text are generally well under control (eg: load balancers) and that the
purposes for which they would have to modify a content-encoding are
limited and configurable.

When it comes to caches, I don't know if anything must be done, it could
even be useful to cache such contents if multiple clients use the same
key. Maybe pass a vary: referencing the encryption key then, but I could
be wrong, I'd rather let the experts talk.

Cheers,
Willy

Received on Tuesday, 12 May 2015 08:25:56 UTC