Re: Privacy difficulties in Blind Caching and OOB encoding

On 05/08/17 05:15, Jeffrey Yasskin wrote:
> Thanks, it's good to know I didn't miss anything.
> 
> I'm thinking about this in order to re-use as much of your work as
> possible in the eventual web packaging proposal. My guess for that is
> that simply omitting encryption support will make it more obvious to
> folks that there are lots of limitations on what secrets we can keep
> from the intermediates. Does that sound plausible?
> 

While those drafts particular approaches were problematic the encryption 
of message payloads proceeded well and became RFC 8188.

Whatever you do for the signature requirement can leverage that part to 
at last gain some protections which are expected to be interoperable 
over HTTP(S).

> Integrity support via SRI, MICE, or a signature is still very
> important, of course.
> 
> We do lose support for the case where it's fine for the intermediate
> to correlate users but not ok to expose the actual bytes. Since we
> keep being surprised by how much information metadata gives away, my
> instinct is that this isn't a big enough space to be worth the risk;
> but I'm curious if you have use cases where it is important and it's
> clear that users will understand what they're exposing?
> 

Have you looked at RFC 2660? while the document is woefully out of date 
in terms of crypto and quite broken in a number of other ways the idea 
of moving the identifiable non-transport headers (and maybe any 
non-standard ones from the message generator) into the encrypted portion 
can go a long way towards both security and privacy protection before it 
starts breaking HTTP.

Amos

Received on Saturday, 5 August 2017 03:57:31 UTC