Re: Call for Adoption: Encrypted Content Encoding

Hi Cory,

On 12/1/15 12:05 PM, Cory Benfield wrote:
> 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.

I seem to be making my point poorly.  I suspect we agree more than we
disagree.  Another coffee and another attempt ;-)

You're rebutting a rather blunt straw man argument that is not my
position. There are probably a great many alternatives to issuing a
blanket 415 Unsupported Media Type.  We needn't get into an exact
solution now, nor perhaps not even in the working group.  But stating a
risk as well as mitigations is a normal practice in a specification and
it should be followed here as well.  That is all I am suggesting.

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

I'm sympathetic to the draft being adopted, but your argument above is a
little off.  Today the Internet is full of intermediaries that do not
add malware, and would not happily add malware.  You yourself are using
just such an intermediary for your own email.  Even if we assume that
you meant to say that there is a threat that intermediaries can
introduce malware, my concern is more that a server will end up serving
up malware without any knowledge of doing so.  This is a separate threat
to those who retrieve information.  And you seem to agree because you
write...

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

And I'm suggesting further changes to Section 6 along the above lines,
and maybe some future work elsewhere, perhaps relating to
draft-thomson-http-content-signature.  Exactly what we can leave until
later.  My point is that with this functionality it doesn't take a
criminal mastermind to come up with some pretty scary scenarios
involving an 0wn3d publisher or 3 or 300 or 300,000.

Eliot