Re: Call for Adoption: Encrypted Content Encoding

> On 1 Dec 2015, at 09:50, Eliot Lear <lear@cisco.com> wrote:
> 
> I realize there's a lot of back and forth on this, and so just to restate my own position so that it doesn't get lost in the bustle.
> 
> The approach standardizes behavior that would ease transmission of malware to end users without the ability of the server to scan content by providing a  protocol element automated systems could use that does not already exist today.
> 
> While somewhat analogous to an encrypted zip file, we don't specify behavior in that case, and unknown zip files themselves are well known to to pose risks such that automated processing is generally discouraged.  Certainly

Sorry, I’m still perplexed by this. If a server is worried about allowing unvalidated binary data through, that server should send 415 Unsupported Media Type in response to any request with Content-Encoding: aesgcm128. There is no requirement to accept a content-encoding a server does not like.

However, for servers that are unconcerned about the risk of malware distribution (e.g. secret storage/distribution tools like Barbican), this RFC represents a net win, because it specifies a *general* solution to the problem of distributing arbitrary secret data end-to-end.

Let me point out one additional thing: for each intermediary/server that wants to remove malware from a transmitted entity, there’s at least one that would happily *add* it. Replacing an entity with a malware-ridden one is not all that difficult when the body is unencrypted, but it is substantially harder when the body is encrypted, because the encryption specified here is relatively resistant to tampering and modification. Even wholesale replacement of the body only works if the key is compromised. It is possible to argue that this is safer from a malware perspective, because now the only risk of malware is from entities possessing the key.

(Strictly this isn’t true, it’s from entities possessing *any* key your user agent will transparently accept. This is mentioned in Section 6.2, though I’d like it if we could avoid washing our hands of responsibility for this concern and could address it more strongly. For example, should we require that user-agents not transparently decrypt data until they’ve had the user authorise the key being used for this specific data? The risk here is, should this Content-Encoding become popular, user-agents (and even more so servers) may store a great many keys indeed, greatly raising their threat surface to this attack.)

Cory