- From: Eliot Lear <lear@cisco.com>
- Date: Tue, 1 Dec 2015 14:01:27 +0100
- To: Cory Benfield <cory@lukasa.co.uk>
- Cc: Julian Reschke <julian.reschke@gmx.de>, "Walter H." <Walter.H@mathemainzel.info>, Roland Zink <roland@zinks.de>, Jim Manico <jim@manicode.com>, ietf-http-wg@w3.org
- Message-ID: <565D9A27.4010206@cisco.com>
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
Received on Tuesday, 1 December 2015 13:01:59 UTC