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

On 12/05/2015 7:30 p.m., 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.
> 
> 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?

In the ways I outlined in my earlier mail. Stating clearly which
encrypted messages are safe to cache (or not) and what response headers
should be added to make it easier for compliant caches to do the right
thing will make implementers reading the spec aware that they are
relevant actors.

Perhapse explicitly calling out the types of third-party, including
proxy caches, which are expected to be handling these messages in the
Intro or some early section. Though I leave that to the editors.

Given that the purpose of this is to enable safe storage / caching of
objects by untrusted third parties. At least raising the topic of
middlewares is important.


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

Yes, its still usable and relevant. But its currently not spelled out
how. Which will lead to mistaken interpretations and interoperability
failure IMO if left as per -00.

> 
> 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, well. I disagree (slightly) on that - in the general case. The spec
does state that encryption may be layered with multiple keying. I see it
reasonable then that a proxy could add/remove one or more of those
encryption layers as the message transits in or out of sites security zones.

Amos

Received on Tuesday, 12 May 2015 08:12:22 UTC