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

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.

> Section 4.1 is missing statements to the effect that encoding with the
> key= parameter containing explicit keying material the message is
> cacheable subject to other cacheability criteria.
>  This implies the Vary:Accept-Encoding header is mandatory.
>  This also implies Security Considerations regarding proxy caches (or
> CDN) storing and sharing the message payload to multiple recipients.

Indeed, caching (and Vary) implications do need to be addressed.
Tracking: https://github.com/martinthomson/http-encryption/issues/1

I'm less concerned about the proxy cache story.  Though perhaps we
could acknowledge the fact that this shifts the access control basis
from the content to the key (which also gets to your later point about
key loss).

> Section 4.2 is missing statements to the effect that messages encoded
> with the dh= parameter are not cacheable.
>  This implies the "Vary: *" header and field-value are mandatory.
>  This also implies that for compatibility with legacy implementations
> the Cache-Control:no-store and/or Expires header should be recommended
> to enforce correct behaviour.
>  This method also requires a Security Considerations reinforcing
> understanding that if the out-of-band parts of the encryption are lost
> the data encoded is also lost. (common sense to us, but not to some
> others in my experience).

Tracked: https://github.com/martinthomson/http-encryption/issues/2

> Has any correlation check been done to see if there are any equivelent
> mechanisms within protocols using MIME or mime-like headers? This is a
> mechanism that could find a useful place in many of the other popular
> protocols beyond HTTP. The Encryption* headers also fit the criteria
> outlined in BCP 90 section 2.2.2 for Content-* prefixed MIME headers.

I've looked, but I know how poor I am at this searching business, so
will defer to others.  One thing that we decided was that decided to
generically design something for application to other protocols would
be a great way to kill it.

Obviously S/MIME (now CMS) is in this general space.  But the reasons
for not choosing that are articulated in the document.

Adding Content-* seemed like a waste.  We might just as well have
chosen to add 'Access-Control-Allow-*' to everything.

Received on Tuesday, 12 May 2015 00:07:59 UTC