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

On 12/05/2015 8:32 a.m., Martin Thomson wrote:
> 
> Name:           draft-thomson-http-encryption
> Revision:       00
> Title:          Encrypted Content-Encoding for HTTP
> Document date:  2015-05-11
> Group:          Individual Submission
> Pages:          17
> URL:
> https://www.ietf.org/internet-drafts/draft-thomson-http-encryption-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-thomson-http-encryption/
> Htmlized:       https://tools.ietf.org/html/draft-thomson-http-encryption-00
> 
> 
> Abstract:
>    This memo introduces a content-coding for HTTP that allows message
>    payloads to be encrypted.
> 

Thank you. This is indeed a document covering an area of some interest
to several members of the Squid community including myself.


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.


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.


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).


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.

Amos

Received on Monday, 11 May 2015 23:19:26 UTC