Subject: Re: Call for Adoption: Encrypted Content Encoding

From: "Walter H." <[email-masked]>
Date: Tue, 01 Dec 2015 09:22:01 +0100

On 01.12.2015 01:19, Roland Zink wrote:
> Am 01.12.2015 um 00:32 schrieb Jim Manico:
>> > TLS is also end-to-end
>>
>> No way is that true. TLS per the standard can be MITM'ed by proxies 
>> in ways that subvert both certificate pinning and HSTS in ways that 
>> do NOT inform the user in any browser today. I'm happy to provide 
>> references to this if you like.
>>
> The browser will build a end to end TLS tunnel through known proxies. 
> Intercepting proxies may do MITM and
and exact these intercepting proxies can't validate this content, if it 
contains malware or not;
as I said, THIS DRAFT IS NONSENS;

> RFC7469 says it is allowed for clients to turn off pin validation 
> based on some policy and still be compliant. Is this what you want to 
> reference?
>
> However it is also compliant to not do this and do pin validation.
>
what does this help preventing clients receiving malware, that will be 
raised through this draft?

---

From: Julian Reschke <[email-masked]>
Date: Tue, 1 Dec 2015 09:33:47 +0100

> as I said, THIS DRAFT IS NONSENS;

Are you promoting the concept of intercepting proxies that break up HTTPS?

> raised through this draft?

Privacy and the ability for third-parties to inspect the contents 
obviously are conflicting goals. Nothing new here.

One reason for the use of encrypted content in a "blind cache" is to 
allow caching of HTTPS content without having to mount a MITM attack. 
And I believe that's a very good reason.

Best regards, Julian

---

From: Cory Benfield <[email-masked]>
Date: Tue, 1 Dec 2015 08:33:59 +0000

> On 1 Dec 2015, at 08:22, Walter H. <[email-masked]> wrote:
> 
>>> No way is that true. TLS per the standard can be MITM'ed by proxies in ways that subvert both certificate pinning and HSTS in ways that do NOT inform the user in any browser today. I'm happy to provide references to this if you like.
>>> 
>> The browser will build a end to end TLS tunnel through known proxies. Intercepting proxies may do MITM and
> and exact these intercepting proxies can't validate this content, if it contains malware or not;

It’s not at all clear to me how this objection applies. The purpose of encrypting the content is to prevent it being read by intermediaries. That’s literally what encryption is for.

If an intermediary is worried that a client may be downloading malware in an encrypted body, it can simply chose to refuse to forward the response, and instead send some 4XX/5XX code. This is actually *easier* with this draft than it was before because the intermediary can reliably identify encrypted payloads and choose to block them, without needing to introspect the payload very closely.

---

From: "Walter H." <[email-masked]>
Date: Tue, 01 Dec 2015 10:05:02 +0100

> Are you promoting the concept of intercepting proxies that break up 
not really, this concept will come more and more as a weapon againt 
paranoia that
everything "must" be HTTPS
> obviously are conflicting goals. Nothing new here.
and why DOES someone really want to promote something (THIS) to a 
standard, which
raises these problems?
> allow caching of HTTPS content without having to mount a MITM attack. 
this draft is in connection with HTTP not HTTPS
> And I believe that's a very good reason.
not  really,
dynamic content is not cacheable and static content - at these times 
rearely to find - needn't be HTTPS ...

---

From: "Walter H." <[email-masked]>
Date: Tue, 01 Dec 2015 10:30:52 +0100

On 01.12.2015 09:33, Cory Benfield wrote:
>> On 1 Dec 2015, at 08:22, Walter H.<[email-masked]>  wrote:
>>
> It’s not at all clear to me how this objection applies.
encrypted content, that is spreaded to the wide this way without the 
real knowlegde where it really does come ...
>   The purpose of encrypting the content is to prevent it being read by intermediaries. That’s literally what encryption is for.
only if it is not done this way, because with this draft, no server at 
all can decrypt this content, and the primary source isn't known, too;
> If an intermediary is worried that a client may be downloading malware in an encrypted body, it can simply chose to refuse to forward the response, and instead send some 4XX/5XX code.
without this draft this situation would not exist ...
> This is actually *easier* with this draft than it was before because the intermediary can reliably identify encrypted payloads and choose to block them, without needing to introspect the payload very closely.
no, this draft raises other security problems;

---

From: Eliot Lear <[email-masked]>
Date: Tue, 1 Dec 2015 10:50:58 +0100

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

That to me is *not* a show stopper so long as we acknowledge it in the
Security Considerations and discuss mitigations as we do with other new
vectors.  Although I gave as an example a single means to demonstrate
that it is possible to mitigate risks from such a vector, unless there
is a clear approach that requires very little work, I'm not suggesting
that the mitigation or any other be fully specified in this document.

By the way: draft-thomson-http-signature lays a good foundation for any
attestation approach.

Eliot

---

From: Cory Benfield <[email-masked]>
Date: Tue, 1 Dec 2015 11:05:41 +0000

> On 1 Dec 2015, at 09:50, Eliot Lear <[email-masked]> 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

---

From: Eliot Lear <[email-masked]>
Date: Tue, 1 Dec 2015 14:01:27 +0100

Hi Cory,

> 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 *gener…

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 wit…

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 hand…

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

---

From: Julian Reschke <[email-masked]>
Date: Tue, 1 Dec 2015 14:14:16 +0100

On 2015-12-01 14:01, Eliot Lear wrote:
> ...
> ...

One could argue that that server is only serving some opaque blob, and 
only by combining it with additional information for decryption (not 
available from that server), the malware comes into existence.

Best regards, Julian

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 2 Dec 2015 02:30:46 +1300

> everything "must" be HTTPS

Intercepting proxies are not the only parties "breaking up" HTTPS.

TLS offloading is such routine practice that it has that defined term
"TLS offload" to name it by. This was going on at the CDN proxies end
long before MITM proxies were forced upon ISP by this "TLS everywhere"
craziness.

HTTPS relies on TLS. TLS is a point-to-point protocol, just like TCP.
Also just like TCP it can (and does) have multiple hops between user and
origin server.

> this draft is in connection with HTTP not HTTPS

IMO there is no particular reason for that. When fetching these objects
from a blind cloud provider it makes no difference whether that service
is HTTP or HTTPS. The ultra paranoid would probably also prefer to fetch
these objects over HTTPS / TLS for the added header protection it
affords while going over the network.

Which I hope clarifies the distinction:

* HTTPS is about protecting against untrusted network.

* This draft is about protecting against untrusted origin server, or
unauthorized third-party download.

Three very different attack vectors.

As has already been mentioned in this thread encrypted .rar/.zip or
other formats are possible (and already actively used) for exactly this
style of server-based attack mitigation. This draft is just formalizing
an existing practice in a format more suitable for HTTP agents use.

> dynamic content is not cacheable

Not true. Some Squid installations have reported caching rates up to 80%
on ISP even though the current web traffic consists of more than 50%
dynamic content.

The biggest problem these days is recent browser releases sending
Cache-Control:max-age=0 unconditionally. Which adds latency for
revalidation even perfectly usable objects are already available.

> and static content - at these times

Amos

---

From: Cory Benfield <[email-masked]>
Date: Tue, 1 Dec 2015 13:33:15 +0000

> On 1 Dec 2015, at 13:01, Eliot Lear <[email-masked]> wrote:
> 
> Hi Cory,
> 

On that we definitely agree. =)

> write…

Well, let’s stop for a minute. Your concern is that servers will end up serving malware with no knowledge of doing so: fine. I quite deliberately am minimising this concern because I don’t personally believe it’s that likely, but I grant you that it’s *more likely* than it was prior to this draft. I don’t think it’s *much* more likely, probably fractional percentages, but definitely more likely.

However, you follow-on to write:

> My point is that with this functionality it doesn't take a

And this is valid: it doesn’t take a criminal mastermind. However, that misses the wood for the trees, which is that you can do *exactly that*, today. It’s not harder than it would be with this draft in place: if anything, it may be easier.

Remember, a server can serve whatever the hell it chooses. Do some servers screen their resources for malware? Presumably, I’m sure. But I bet far more don’t. If the server allows user A to upload arbitrary thing X, and serves it to user B, then we should assume that it is vulnerable to distributing malware. Given that there is no 100%-perfect malware detection system, we should therefore assume that *any* system that behaves in this way is potentially at risk. Encrypting those payloads makes it easier to trick a server that actively scans for malware, sure, but the difference is that it potentially eliminates (or restricts) the ability to mount a parallel attack, which is to intercept the thing X at any point in its multiple transmission hops and replace it with malware-ridden thing Y. With this RFC, the only entities capable of attacking me are those that have access to my keys, which (I hope) is going to be fewer than the number of entities that could attack an unencrypted payload in flight or at rest.

The real root of our disagreement, I think, is whether we trust the intermediaries more than the communicating peers (where intermediaries are any machine/network that touched the document, and the communicating peers are those that possess the encryption keys). I do not believe that trusting those intermediaries, either to protect me from malware or to not actively insert malware into my data stream, is a thing I should do on the modern web. For that reason, I don’t really care that a server can’t scan documents for malware before serving them to me, because if that’s my only defence against malware then I’m screwed anyway: it’s only a matter of time before I hit a hostile server or network that deliberately serves malware.

Having malware scans increases defence in depth, sure, but I don’t believe it’s a panacea, and I don’t believe that the need to sacrifice it is a slam-dunk reason to avoid promoting this draft.

Generally speaking, all we can do is remove attack surface for malicious or naive actors to attack users. HTTPS does this by making it harder for intermediaries to attack users. This draft would also make it harder for servers, or HTTPS-terminating network hops, to attack users. In my mind, that’s a net win: with this in place, I only need to defend against actors that have the key I’m using.

Now, Eliot, to be entirely fair to you, your request (to mention this problem in Section 6) is totally reasonable, and I’m in favour of it. I’d also like us to investigate further whether draft-thompson-http-content-signature or something equivalent can be folded into this proposal to help reduce the risk of the attack that I’m concerned about, which you have helpfully suggested. However, Walter has suggested that “THIS DRAFT IS NONSENS” because of this trade-off, and I wanted to make a clear and coherent case of why I believe that is untrue. I remain +1 on the intent of this draft, though I believe we need to flesh out Section 6 substantially.

Cory

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 2 Dec 2015 03:02:16 +1300

On 1/12/2015 12:15 p.m., Roland Zink wrote:
> Am 30.11.2015 um 21:10 schrieb Walter H.:
>> On 30.11.2015 13:22, Amos Jeffries wrote:
>>> The point of this draft is the same. When anything is encrypted with
>>> intentio that the recipient acts on the decrypted content in ways
>>> other than saving it to a file - the sender emits the appropriate C-E
>>> header that says its crypted (and how). Such that the recipient can
>>> decrypt if/when it has the ability. 
>> in comparison to encrypted end-to-end encrypted E-mails, there is the
>> same problem; this draft is the same bad idea than the
>> publishing the public keys to the wide ...
>>
> 
> TLS is also end-to-end
> 

That is a false statement.

TLS is point-to-point. There is no requirement in TLS that point-B on
the conection be the origin server.

Very often in CDN network HTTPS it is actually not the origin server but
a TLS offloader / load balancer at least one hops in front of a whole
LAN or farm of origins.

One CDN I recently helped diagnose traffic bugs within had 8 distinct
connection hops from the frontend HTTPS terminating device to the origin
server. Over three separate TLS connections and a VPN  (non-TLS)
connection across two continents.

>> I don't say that the malware detection on client side is not as good
>> as that on any server side; I'd say,
>> that the chance to detect malware is better when it is not only at one
>> pont: the client;
>>
>> just think of the following case:
>>
>> someone has implemented this draft; that everybody downloading the so
>> uploaded data trusts the server owner ...
>> and it absolutely nonsense that the webadmin itself can't clearly open
>> the file natively on the server, because its encrypted ...
>>
>> data exchange is good, but this way its more than stupid;
>>
>> there doesn't exist any really USEFUL use case ...
>>
>>
> I don't understand the problem. The message is send from server A
> through server B to recipient C. B can't read the message. As long as C
> can determine the message is from A (and not B) this is the same as with
> TLS, isn't it?
> 
> That said it might wishable for TLS end users to contract a third party
> to check the messages before opening itself the messages.
> 

One use-case:

  Global service provider Not So Awkward offers cloud storage services
at a cheap price that nobody else can beat. Estonian Central Bank has
grown so large that it needs an external backup. It has the obvious
legal restrictions that prevent storing banking records unencrypted on
any third-party service. As well as the added problem that NSA cloud
services are not able to provide clear information or guarantees about
the specific location or safety of their storage servers.

 Since it is paying for the storage service EC Bank would like that
service to be useable as a full working alternative should its internal
systems suffer an outage. This means that clients be able to download
and use the objects stored by the NSA cloud directly from a banking web
portal (stored on another smaller but more trusted third-party) without
additional archival software being needed.

 The EC Bank decides to use C-E:aes to encode their backup content in
its native format with cryptographic keys that only the bank itself and
the individual clients are able to access on a per-object basis. But no
other party, including the backup cloud provider can access.

HTH
Amos

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 2 Dec 2015 03:30:18 +1300

On 1/12/2015 8:51 p.m., Walter H. wrote:
> On 01.12.2015 00:15, Roland Zink wrote:
>>
>> TLS is also end-to-end
> when you think of one end encrypting and one end decrypting that yes;
> but there is nowhere said, that one end is any server sending the data
> and the
> other end is the client receiving the data ...
>>
>> through server B to recipient C. B can't read the message. As long as
>> C can determine the message is from A (and not B) this is the same as
>> with TLS, isn't it?
> and exact this is the problem; C can't determine from where the message
> comes ...
> or do you really think there exist such stupid webadmins that publish
> encrypted data, which they can't decrypt for themselves?
> 

Yes such admin exist. And no they are not stupid. See the use-case I
presented a short while ago to your other email as one example of such
admin.

It is also not uncommon to have admin on our proxy help mailing lists
post attachments with packet captures and such details. Some of which
contain encrypted traffic. Neither the admin posting the message nor
myself nor any other reader of the list necessarily has the keys to
decrypt it, but the reason its posted is to replicate accurately some
problem with the proxy handling certain byte sequences that come up.

For example off-by-1 error parsing the T-E:chunked framing of the
wrapper message that crypted object was sent in. When the error only
occurs rarely and randomly on certain objects.

Amos

---

From: Roland Zink <[email-masked]>
Date: Tue, 1 Dec 2015 15:56:35 +0100

> connection across two continents.
It is possible to see it this way. However the TLS endpoint pretends to 
be the origin server and proofs this with a certificate. Not sure if the 
things behind it should be name origin server.

Regards,
Roland

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 2 Dec 2015 04:14:01 +1300

On 1/12/2015 8:53 a.m., Walter H. wrote:
> On 30.11.2015 13:33, Amos Jeffries wrote:
>>
>> Also how is this different from malware infected machines uploading
>> encrypted payloads today?
> in case this malware is encrypted in an archive container, there is no
> problem, because
> no key, no harm;

In the case that the server has a key to send in Encryption-Key it is
perfectly capable of decrypting the object itself and AV scanning it.

In the case that the server does not have a key, then the messages it
outputs do not have a key either. Ergo as you said "no key, no harm;".

So, no difference at all you mean.

Also noteworthy is that potentially an AV scanner along the way does
have the key and can scan the content. Even when the server does not.
This also goes for both todays existing situation and the draft method.

> 
> in case this malware is not encrypted in an archive container like .zip
> or .rar,
> the server has the change to clean it ...
> 

The case where the upload is not encrypted is irrelevant to my question.
I asked about how this draft was worse than the _current existing_ case
where uploaded content is encrypted using a container format other than
what is described in this draft.

>> IMHO those opaque encrypted .rar/.zip files are a more fertile and
>> safe-from-inspection vector for malware to be using than this proposal
>> where the raw Content-Type etc are exposed for vetting.

> this is a wrong view to the fact, that .rar/.zip can be inspected as
> long they are not encrypted;

The attack vector is that they *are* encrypted. Telling me its a "wrong
view" does not counter the fact that there is active working malware
code out there doing it yesterday.

The question was how is encrypting using file-based methods safer than
encryption with this draft method. My conclusion: it is not.

> just the same as raw content;
> if they are encrypted they won't be any dangerous, because no key, means
> no access;
> but for this proposal, the server has no change doing anything against,
> and at client side,
> the malware may get start automatically, because of raw Content-Type ...
> 

There is the attack vector that needs addressing. BUT exactly that, it
needs addressing; not throw-the-whole-draft-away nor throw-privacy-away.

The first step in mitigation is that the crypto needs to be stripped
away for the auto-execute to actually work. Which as Cory mentioned
already requires the victim to have a key. See above for the two key
cases from server perspective.

To be honest the malware I'm aware of was encrypted .chm and .exe (not
.rar/.zip - thats just the types mentioned as examples earlier). So yes,
the file-based encrypted content can still auto-execute based on
Content-Type if the attacker is smart. Or they just use a wrapper
payload that both decrypts and translates into a weaponized form (ie
decrypt+extract archive). Auto-execute is the easy part for the attacker.

Amos

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 2 Dec 2015 04:21:34 +1300

> things behind it should be name origin server.

A TLS interception proxy / MITM pretends the same and also proofs using
a certificate the client trusts (through a different CA). So by your
interpretation it should be "the origin"?

Amos

---

From: Roland Zink <[email-masked]>
Date: Tue, 1 Dec 2015 16:50:27 +0100

> interpretation it should be "the origin"?
This is of cause even worse, but from the clients perspective the MITM 
is the "origin" although the MITM is lying.

---

From: Kyle Rose <[email-masked]>
Date: Tue, 1 Dec 2015 11:33:58 -0500

> the conection be the origin server.

Perhaps the confusion lies in the fact that end-to-end vs.
point-to-point, taken literally, depends on how you're defining your
endpoints? TLS is end-to-end if you consider the endpoints of the TCP
connection to be the two ends. But I'd argue that this interpretation
renders the two concepts meaningless. E2E vs. P2P in a security
context imply things other than what the phrases literally mean.

One of the distinguishing characteristics of end-to-end encryption in
my experience is that the payload/data stream can be time-shifted
without affecting the ability for authorized users to decrypt the
data: TLS, with forward secrecy, clearly does not have this
characteristic. Another characteristic is that the payload is
encrypted and decrypted offline, i.e., without any online handshake
between the sender and the recipient: again, TLS is explicitly
designed in a way that this is not possible. End-to-end also implies
the ability for (though not the necessity of) many recipients, rather
than one-to-one communication: TLS also fails this test.

Frankly, in myriad discussions over many years with lots of different
people, this is the first time I've encountered confusion about the
two concepts. It's almost hard to believe we're arguing about this.

Kyle

---

From: Roland Zink <[email-masked]>
Date: Tue, 1 Dec 2015 17:51:03 +0100

> two concepts. It's almost hard to believe we're arguing about this.
One reason is a mistyping. Actually it should be HTTPS instead of TLS. 
HTTPS can establish an end-to-end TLS connection through proxies using 
CONNECT requests over several TCP connections. In your definition this 
doesn't make a difference I guess.

---

From: Kyle Rose <[email-masked]>
Date: Tue, 1 Dec 2015 12:01:15 -0500

> One reason is a mistyping. Actually it should be HTTPS instead of TLS. HTTPS
> can establish an end-to-end TLS connection through proxies using CONNECT
> requests over several TCP connections. In your definition this doesn't make
> a difference I guess.

No, that seems to be a legitimate use of "end-to-end", which IMO just
adds further credence to the viewpoint that the two terms are actually
orthogonal to topology. Regardless of the other connotations it might
evoke, "end-to-end security" is probably best defined as "only the
sender and authorized users of the data have access to the cleartext",
whereas "point-to-point security" allows for such access to
intermediate nodes.

Kyle

---

From: Kyle Rose <[email-masked]>
Date: Tue, 1 Dec 2015 13:25:41 -0500

Now that I'm not running off to lunch, I can finish my thought.

Clearly, there are delivery scenarios in which the characteristics I
outlined in my OP (time-shifting, offline, multiple recipients,
confidentiality from untrusted intermediate nodes) are requirements,
so it's going to happen anyway. This proposal is useful because it's
better for the implementation meeting those requirements to be a
standard.

Kyle

---

From: "Walter H." <[email-masked]>
Date: Tue, 01 Dec 2015 21:12:09 +0100

> encryption with this draft method. My conclusion: it is not.
file-based methods won't get decrypted automatically without any 
mechanism on client side;
this draft method does.

I didn't find any example of how the HTTP request looks like, only the 
Responses as in chapter 5

so there are two possibilities

the client has implement this draft and stores the decrypted content, 
and if it is "useful" runs it ..., the worst case
or the client doesn't know this draft and also doesn't know what to do 
with the extra fields in the HTTP response ...

at todays view it would be good not to update the client ...

> needs addressing; not throw-the-whole-draft-away nor throw-privacy-away.
before giving potential attackers another possibility how they can 
attack more efficient,
it is better to throw away this draft, and think of, what went wrong ...
> cases from server perspective.
are you sure that there is no mechanism, to download the content and get 
it decrypted native?
just think of the HTTP header that is needed to get the content ...
>
> To be honest the malware I'm aware of was encrypted .chm and .exe
and what were these encryption formats?
I mean I can pack any file into an archive format and encrypt this ...

---

From: Cory Benfield <[email-masked]>
Date: Wed, 2 Dec 2015 10:16:20 +0000

> On 1 Dec 2015, at 20:12, Walter H. <[email-masked]> wrote:
> 
> file-based methods won't get decrypted automatically without any mechanism on client side;
> this draft method does.

You’re right: without this draft the file-based methods won’t get decrypted, no. It’s worse: they get *executed*.

Decryption itself should not be a malware distribution vector. The only way it could be is if the decryption code itself is vulnerable to a code injection attack of some form (e.g. buffer overflow). That’s certainly *possible*, but it’s not standard practice.

However, user-agents automatically process plenty of file formats already. Chrome opens PDFs in an internal renderer: PDFs are a potential malware distribution vector. Internet Explorer can be configured to helpfully open whatever program is associated with a file format without user input. Safari will automatically decompress a ZIP file that it’s served. Frankly, if your concern is malware distribution then I highly recommend you ask browser authors to stop automatically executing content they download. (Good luck with that.)

If user-agents did not execute, but did transparently decrypt, all content, there would be no problem. The problem is trusting the decrypted content, and that risk already exists for the non-decrypted content you receive today. Plus, when I download a zip file from GitHub today, there’s no guaranteeing that a MITM box didn’t replace that zip file with one containing a malware-based payload. This new draft does provide me with that guarantee: only GitHub and I can tamper with that file.

Once again, I cannot stress this enough: this draft does not add any new malware distribution vector. It makes certain malware distribution vectors harder to use, and it makes certain malware detection methods potentially less effective. However, it also grants the possibility of data distribution with tightly controlled access, which is not possible on the web today.

Cory

---

From: John Mattsson <[email-masked]>
Date: Wed, 2 Dec 2015 10:55:19 +0000

On 02/12/15 11:16, "Cory Benfield" <[email-masked]> wrote:

>Once again, I cannot stress this enough: this draft does not add any new
>malware distribution vector. It makes certain malware distribution
>vectors harder to use, and it makes certain malware detection methods
>potentially less effective. However, it also grants the possibility of
>data distribution with tightly controlled access, which is not possible
>on the web today.

+1 (Good summary)

---

From: "Walter H." <[email-masked]>
Date: Wed, 02 Dec 2015 12:32:36 +0100

On 02.12.2015 11:16, Cory Benfield wrote:
>> On 1 Dec 2015, at 20:12, Walter H.<[email-masked]>  wrote:
>>
you are talking about content, this draft has no influence, because it 
is not encrypted;

lets talk about the following case:

someone places somewhere an IMG-HTML-Tag

and would you really tell me, that in case this IMG-HTML-Tag points to 
such an encrypted file, this
will never be shown/executed/what ever?

as I said, in case the UA has no knowledge about this draft, nothing 
happens;
but with knowledge of this draft, you can't tell me that the encrypted 
content won't be shown;

to bring you notice the difference:

without this draft: someone has to explicitly a .js, .vbs, ... in the 
HTML-Tag or the server MUST send the
MIME type for the content in case it is .jpeg or other not harmful;
and this can be filtered easily;

with this draft there doesn't not exist any way of filtering it; because 
the URL looks as it should, but the content is something different;

in case you use a proxy, then with this draft, the proxy can't filter 
anything; without, it can;

> However, user-agents automatically process plenty of file formats already.
yes but without this draft they can't do anything in case the content is 
encrypted ...
with this draft, the HTTP request tells the server to hand out all 
neccessary and the malware is on your client ...

did you understand?

>   Chrome opens PDFs in an internal renderer: PDFs are a potential malware distribution vector.
only when opened with adobe; not every piece of software does the same 
stupid things ...

>   Internet Explorer can be configured to helpfully open whatever program is associated with a file format without user input.
IE is only on windows; and with Win10 Edge is MS's answer of Google's 
Chrome

>   Safari will automatically decompress a ZIP file that it’s served.
yes but then this draft makes it; we didn't talk about unencrypted 
content ...

> If user-agents did not execute, but did transparently decrypt, all content, there would be no problem. The problem is trusting the decrypted content, and that risk already exists for the non-decrypted content you receive today.
you are right: "If user-agents ...", then this draft raises the risks, 
because not only decrypted content is a problem, also encrypted content ...
>   Plus, when I download a zip file from GitHub today, there’s no guaranteeing that a MITM box didn’t replace that zip file with one containing a malware-based payload. This new draft does provide me with that guarantee: only GitHub and I can tamper with that file.
nobody did say this;
>
> Once again, I cannot stress this enough: this draft does not add any new malware distribution vector.
think of the example above and your stressing is against walls of water ...

>   It makes certain malware distribution vectors harder to use, and it makes certain malware detection methods potentially less effective.
this is nonsense ... see above ...

---

From: "Walter H." <[email-masked]>
Date: Wed, 02 Dec 2015 12:39:53 +0100

On 02.12.2015 11:55, John Mattsson wrote:
> On 02/12/15 11:16, "Cory Benfield"<[email-masked]>  wrote:
>
>
-1 (...which tells to throw it away, because the first 2 sentences of 
the summary disagree)

---

From: "Walter H." <[email-masked]>
Date: Wed, 02 Dec 2015 12:48:22 +0100

On 01.12.2015 12:05, 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.

refusing Content-Encoding: aesgcm128 for invalid or bad data, e.g. 
malware means also refusing Content-Encoding: aesgcm128 for valid or 
good data ...

any Webadmin should think of the fact, that he/she can be made 
responsible for spreading malware ...

  which sense does this draft then have?

---

From: Cory Benfield <[email-masked]>
Date: Wed, 2 Dec 2015 12:23:42 +0000

> On 2 Dec 2015, at 11:32, Walter H. <[email-masked]> wrote:
> 
> you are talking about content, this draft has no influence, because it is not encrypted;
> 
> and would you really tell me, that in case this IMG-HTML-Tag points to such an encrypted file, this

No, of course not. In fact, I said the exact opposite: it will definitely get ‘executed’ (I’m using ‘execute’ here very broadly, but it saves us having to fight too much about what the correct word is for each type).

> as I said, in case the UA has no knowledge about this draft, nothing happens;
> but with knowledge of this draft, you can't tell me that the encrypted content won't be shown;

Yes, but that’s no different to right now. If I put a HTML <img> tag in my web page right now, *all* user agents will ‘execute’ that image file. But this isn’t new to encryption: the only new thing is that your proxy can’t decide my user-agent shouldn’t execute something.

> without this draft: someone has to explicitly a .js, .vbs, ... in the HTML-Tag or the server MUST send the
> with this draft there doesn't not exist any way of filtering it; because the URL looks as it should, but the content is something different;
> 
> in case you use a proxy, then with this draft, the proxy can't filter anything; without, it can;

Yes, that’s correct. But as I’ve said before, that’s not a reason to destroy this draft. It’s a note worth putting in Section 6 of this draft, sure, but it’s not at all unreasonable to want to guarantee the integrity and privacy of a transmission. After all, while your proxy may only filter things for my “safety”, someone else's proxy may replace the legitimate content I wanted with other, potentially malicious, content. One person’s legitimate use case is another person’s active attack vector.

> yes but without this draft they can't do anything in case the content is encrypted ...
> with this draft, the HTTP request tells the server to hand out all neccessary and the malware is on your client ...
> 
> did you understand?

You said, this, which I understand, but then you said this:

> only when opened with adobe; not every piece of software does the same stupid things …
> 
> 
> IE is only on windows; and with Win10 Edge is MS's answer of Google's Chrome
> 
> yes but then this draft makes it; we didn't talk about unencrypted content …

Reconciling these two things is tricky. Your concern is that the client will automatically execute the encrypted content, but then you rubbished my concerns about this being an attack vector. My point is that the risk is not in decrypting content, it’s in running that content. Does this draft raise the risk that my user-agent will automatically execute malware? Sure. But I view that as a problem that user-agents should address when implementing this draft. Not a reason to remove the draft altogether.

Cory

---

From: "Walter H." <[email-masked]>
Date: Wed, 02 Dec 2015 13:56:59 +0100

On 02.12.2015 13:23, Cory Benfield wrote:
> No, of course not.
that is wrong; it will, no chance to stop it before ...
>   In fact, I said the exact opposite: it will definitely get ‘executed’
and will raise the attack vector, which you lie about ...
> Yes, but that’s no different to right now. If I put a HTML<img>  tag in my web page right now, *all* user agents will ‘execute’ that image file.
that is wrong, not every user agents accesses the server direct; all 
user agents using proxies or similar might not get the chance to 
'execute' that image file - with this draft they do;
and so you are really telling me this draft doesn't increase the attack 
vector?
>   But this isn’t new to encryption: the only new thing is that your proxy can’t decide my user-agent shouldn’t execute something.
>
> Yes, that’s correct. But as I’ve said before, that’s not a reason to destroy this draft.
then tell me why?

as long as this draft only helps increasing the attack vector it must be 
destroyed and thought of better ways ...

---

From: Cory Benfield <[email-masked]>
Date: Wed, 2 Dec 2015 13:30:19 +0000

> On 2 Dec 2015, at 12:56, Walter H. <[email-masked]> wrote:
> 
> and will raise the attack vector, which you lie about …

I’m sorry, here is a simple miscommunication. When I said “No, of course not”, I was answering your question. Your question was: “Would I tell you that an encrypted image will never get shown?” My response was “I am not saying that.” More specifically: of *course* that image will get shown, that’s the point. We’re agreeing here.

Please don’t call me a liar. There’s no reason for this discussion to get personal.

> that is wrong, not every user agents accesses the server direct; all user agents using proxies or similar might not get the chance to 'execute' that image file - with this draft they do;
> and so you are really telling me this draft doesn't increase the attack vector?

No, I’m not telling you that. In fact, as I said multiple times in this discussion (in [0], and [1], which is literally the email you’re replying to), I said that it absolutely *does* increase the attack vector *for this particular attack*.

(Allow me to quote myself from [1]: “Does this draft raise the risk that my user-agent will automatically execute malware? Sure.”)

What I also said is that it reduces or removes certain other attack surfaces. These two things can be simultaneously true (and in fact, I am arguing that they are).

I’m sorry that I’ve been insufficiently clear on this point.

> as long as this draft only helps increasing the attack vector it must be destroyed and thought of better ways …

The reason we shouldn’t destroy this draft is because this draft doesn’t “only helps increasing the attack vector”. It increases one particular attack vector, closes off others, and also introduces the valuable ability to more-easily secure a communication from all intermediary parties. This ability is important and useful, and making it available is important. I believe that the risk you highlight exists, and should be acknowledged in Section 6 of the draft.

However, I think that the draft should progress with that note in place, because I do not believe that you could introduce this kind of secure communication without increasing the risk of malware injection. It is my opinion that what we gain from this draft is more than what we lose.

Cory

[0]: https://lists.w3.org/Archives/Public/ietf-http-wg/2015OctDec/0287.html
[1]: https://lists.w3.org/Archives/Public/ietf-http-wg/2015OctDec/0305.html

---

From: "Walter H." <[email-masked]>
Date: Wed, 02 Dec 2015 15:43:04 +0100

> (Allow me to quote myself from [1]: “Does this draft raise the risk that my user-agent will automatically execute malware? Sure.”)
this alone would be reason enough to destroy the draft;
> What I also said is that it reduces or removes certain other attack surfaces.
please be concret here, I don't see any reduction or removing of certain 
other attack surfaces;

> The reason we shouldn’t destroy this draft is because this draft 
> doesn’t “only helps increasing the attack vector”.
let it me say in other words; I don't see any feature which is new and 
we hadn't already before ...

so I don't see a USEFUL use case of this draft;

---

From: Roland Zink <[email-masked]>
Date: Wed, 2 Dec 2015 15:59:47 +0100

Am 02.12.2015 um 12:32 schrieb Walter H.:
>> You’re right: without this draft the file-based methods won’t get 
>> decrypted, no. It’s worse: they get *executed*.
Today everybody can place an IMG tag (or iframe tag) pointing to 3rd 
party content. Who cares if malware is delivered this way if setting the 
reference gives some money. If you are instead able to push your content 
encrypted to some CDN servers around the world then you have confidence 
it will not be modified uncontrolled.

> with this draft there doesn't not exist any way of filtering it; 
> because the URL looks as it should, but the content is something 
> different;
>
The usage of TLS disables the filtering in a proxy unless the proxy is 
breaking the TLS security.

>> Decryption itself should not be a malware distribution vector. The 
>> only way it could be is if the decryption code itself is vulnerable 
>> to a code injection attack of some form (e.g. buffer overflow). 
>> That’s certainly *possible*, but it’s not standard practice.
>>
This is not true. Today it is no problem to deliver encrypted content 
and some JS to decrypt it. Even worse steganography may be used to hide 
the fact that encryption was used at all.

---

From: Cory Benfield <[email-masked]>
Date: Wed, 2 Dec 2015 15:04:48 +0000

> On 2 Dec 2015, at 14:43, Walter H. <[email-masked]> wrote:
> 

I disagree.

> please be concret here, I don't see any reduction or removing of certain other attack surfaces;

Sure. This drastically reduces the likelihood of intermediaries replacing a legitimate payload with a malware-ridden one, on both encrypted (HTTPS) and unencrypted (HTTP) communication channels. For example, it is harder to serve me with a malware-ridden PDF version of my bank statement instead of the one my bank wanted to serve me, because you would need a key I trust in order to do so. (With the enhancements I want to Section 6, you’d need a key that I trust *for this content*, an even higher bar.) This is a legitimate and possible attack that is not possible to mount against communications using this draft.

>> The reason we shouldn’t destroy this draft is because this draft doesn’t “only helps increasing the attack vector”.
> let it me say in other words; I don't see any feature which is new and we hadn't already before …

That cannot be accurate: you’ve just discussed some. Specifically, today I cannot serve you an encrypted image and have it render into your web page without hand-rolling this using Javascript. You cannot serve me a document and cause my browser to notify me that it’s the exact same document I placed on the server three weeks ago. Essentially, this moves a lot of capabilities into my user-agent that previously required custom software or additional steps.

Cory

---

From: "Walter H." <[email-masked]>
Date: Wed, 02 Dec 2015 16:34:21 +0100

On 02.12.2015 16:04, Cory Benfield wrote:
> Sure. This drastically reduces the likelihood of intermediaries replacing a legitimate payload with a malware-ridden one,
why should  this be true?
you've forgotten something essential: anything in this draft can also be 
faked by intermediaries ..., so where is the guarantee the PDF or 
whatever is the real one you expect?

this should be enough to see, that this is ONLY an increase of the 
attack vector, and nothing else;

your example with PDF and bank: when this occurs we have another 
problem, which can't be prevented by this draft nor by something else ...

we should be realistic: an increase of attack vector and no new features 
is no useful use case; it is reason enough to destroy this draft;
> That cannot be accurate: you’ve just discussed some.
from the view of malware ...; from the view of good-ware there is no new 
feature, which already exists as alternative before;
encrypted .rar/.zip archives as example;

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 3 Dec 2015 08:05:00 +1100

Walter (et al),

This discussion seems to be repeating the same arguments, without much progress. You don't see value in this draft, but many others have expressed support for it and its use cases.

Unless you have new information, I'd suggest we move on.

Cheers,

> On 3 Dec 2015, at 2:34 am, Walter H. <[email-masked]> wrote:
> 
> you've forgotten something essential: anything in this draft can also be faked by intermediaries ..., so where is the guarantee the PDF or whatever is the real one you expect?
> 
> this should be enough to see, that this is ONLY an increase of the attack vector, and nothing else;
> 
> your example with PDF and bank: when this occurs we have another problem, which can't be prevented by this draft nor by something else ...
> 
> we should be realistic: an increase of attack vector and no new features is no useful use case; it is reason enough to destroy this draft;
> from the view of malware ...; from the view of good-ware there is no new feature, which already exists as alternative before;

--
Mark Nottingham   https://www.mnot.net/

---

From: "Walter H." <[email-masked]>
Date: Thu, 03 Dec 2015 05:06:49 +0100

On 02.12.2015 15:59, Roland Zink wrote:
> and some JS to decrypt it. Even worse steganography may be used to 
> hide the fact that encryption was used at all.
and with this draft you need no JS at all -> absolute unacceptable 
increase of attack vector.

---

From: Mike Bishop <[email-masked]>
Date: Thu, 3 Dec 2015 23:21:02 +0000

Without wading into the morass of arguments already rehashed, +1 on adopting this.  It doesn't have much stand-alone value, but it's a necessary building block in some things that *are* valuable. 

-----Original Message-----
From: Mark Nottingham [mailto:[email-masked]] 
Sent: Tuesday, November 24, 2015 8:53 PM
To: HTTP Working Group <[email-masked]>
Subject: Call for Adoption: Encrypted Content Encoding

We've discussed this document a few times:
 <https://tools.ietf.org/html/draft-thomson-http-encryption>

WEBPUSH now has a normative requirement upon it in
  <https://tools.ietf.org/html/draft-ietf-webpush-encryption>

So, I believe that we should adopt this document as a WG product, with a target of Proposed Standard. 

Please comment on-list; we’ll make a decision about adoption at the end of next week.

Regards,

---

From: Grahame Grieve <[email-masked]>
Date: Fri, 4 Dec 2015 14:00:03 +1100

+1 one of the few reasons I get pushback against REST in favor of still
using SOAP is because in SOAP you can encrypt the body without encrypting
the headers. This creates the choice of encrypting the body end-to-end
without encrypting the headers. You might argue that a well formed
architecture wouldn't get to that point, but there are already many
architectures that are.

Grahame

On Fri, Dec 4, 2015 at 10:21 AM, Mike Bishop <[email-masked]>
wrote:

> Without wading into the morass of arguments already rehashed, +1 on
> adopting this.  It doesn't have much stand-alone value, but it's a
> necessary building block in some things that *are* valuable.
>

-- 
-----
http://www.healthintersections.com.au / [email-masked]
/ +61 411 867 065

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 04 Dec 2015 06:48:23 +0000

--------
In message <[email-masked].
outlook.com>, Mike Bishop writes:

If I havn't done so before:

+1 because this is what encryption sensibly should look like to stand a
fair chance of being acceptable to modern societies.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Cory Benfield <[email-masked]>
Date: Fri, 4 Dec 2015 10:53:35 +0000

> On 4 Dec 2015, at 06:48, Poul-Henning Kamp <[email-masked]> wrote:
> 
> --------

(Replying to Poul-Henning, but this is a question for Mike and Grahame as well):

Earlier in this thread I raised a concern I have about the way this draft accesses keys. In particular, it does not appear to specify any requirement that keys be tied to specific origins or in some way limited in scope: a conforming implementation would be able to have a single global registry of keys that can be used to decrypt content coming from anywhere.

I believe this represents a security risk and should either be addressed in Section 6, or this draft should be accompanied by another that specifies key management in this case.

Can you elaborate on whether you believe my concern is valid or not? If not, why not? If yes, it would be helpful to hear that from you so that I don’t think I’m losing my mind.

Cory

---

From: Eliot Lear <[email-masked]>
Date: Fri, 4 Dec 2015 14:00:50 +0100

Hi Cory,

> I believe this represents a security risk and should either be addressed in Section 6, or this draft should be accompanied by another that specifies key management in this case.

I'm not particularly certain of your specific concern, but I would
suggest that at least some non-normative mention of key management would
be a helpful addition.

Eliot

---

From: Mike Bishop <[email-masked]>
Date: Fri, 4 Dec 2015 18:46:41 +0000

Likewise on the non-normative text.  The draft shouldn't specify how the key to decrypt the content is obtained.  This is a building block for a larger solution which would have to describe how/where clients obtain keys securely and validate them -- this draft isn't something you'd implement stand-alone.  Pointing out that when you use this building block in a system, that's something you have to handle properly is a reasonable cautionary note to add.

-----Original Message-----
From: Eliot Lear [mailto:[email-masked]] 
Sent: Friday, December 4, 2015 5:01 AM
To: Cory Benfield <[email-masked]>; Poul-Henning Kamp <[email-masked]>; Mike Bishop <[email-masked]>; [email-masked]
Cc: Mark Nottingham <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: Re: Call for Adoption: Encrypted Content Encoding

Hi Cory,

> I believe this represents a security risk and should either be addressed in Section 6, or this draft should be accompanied by another that specifies key management in this case.

I'm not particularly certain of your specific concern, but I would suggest that at least some non-normative mention of key management would be a helpful addition.

Eliot

---

From: Martin Thomson <[email-masked]>
Date: Sat, 5 Dec 2015 06:25:28 +1100

I suppose that the very top of the security considerations section wasn't
obvious enough for folks:
https://martinthomson.github.io/http-encryption/#rfc.section.6 :)
On Dec 5, 2015 5:56 AM, "Mike Bishop" <[email-masked]> wrote:

> Likewise on the non-normative text.  The draft shouldn't specify how the
> key to decrypt the content is obtained.  This is a building block for a
> larger solution which would have to describe how/where clients obtain keys
> securely and validate them -- this draft isn't something you'd implement
> stand-alone.  Pointing out that when you use this building block in a
> system, that's something you have to handle properly is a reasonable
> cautionary note to add.
>
> To: Cory Benfield <[email-masked]>; Poul-Henning Kamp <
> [email-masked]>; Mike Bishop <[email-masked]>;
> [email-masked]
> > Earlier in this thread I raised a concern I have about the way this
> draft accesses keys. In particular, it does not appear to specify any
> requirement that keys be tied to specific origins or in some way limited in
> scope: a conforming implementation would be able to have a single global
> registry of keys that can be used to decrypt content coming from anywhere.
> >
> > I believe this represents a security risk and should either be addressed
> in Section 6, or this draft should be accompanied by another that specifies
> key management in this case.
>
> I'm not particularly certain of your specific concern, but I would suggest
> that at least some non-normative mention of key management would be a
> helpful addition.
>
> Eliot
>
>
>
>

---

From: "Walter H." <[email-masked]>
Date: Sat, 05 Dec 2015 08:51:55 +0100

shouln't you then think about the REQUIREMENTS before and then thinking 
of this draft;

you wouldn't build the roof of a building first, would you?

I'd say that it is a MUST to ensure, that the keys won't be retrieved 
without the knowledge of the user and only with user's permission;
else this will become a security desaster;

take it serious and help to make internet smarter;

Thanks

On 04.12.2015 19:46, Mike Bishop wrote:
> To: Cory Benfield<[email-masked]>; Poul-Henning Kamp<[email-masked]>; Mike Bishop<[email-masked]>; [email-masked]
> Cc: Mark Nottingham<[email-masked]>; HTTP Working Group<[email-masked]>
I'd say this is a REQUIREMENT not just something non-normative;

---

From: Cory Benfield <[email-masked]>
Date: Sat, 5 Dec 2015 08:19:55 +0000

So to be clear, Martin: Eliot and Mike wanted something like the text you have. I wanted something substantially stronger than that. =)

> On 4 Dec 2015, at 19:25, Martin Thomson <[email-masked]> wrote:
> 
> I suppose that the very top of the security considerations section wasn't obvious enough for folks: https://martinthomson.github.io/http-encryption/#rfc.section.6 <https://martinthomson.github.io/http-encryption/#rfc.section.6> :)
> 
> On Dec 5, 2015 5:56 AM, "Mike Bishop" <[email-masked] <mailto:[email-masked]>> wrote:
> From: Eliot Lear [mailto:[email-masked] <mailto:[email-masked]>]
> To: Cory Benfield <[email-masked] <mailto:[email-masked]>>; Poul-Henning Kamp <[email-masked] <mailto:[email-masked]>>; Mike Bishop <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> Cc: Mark Nottingham <[email-masked] <mailto:[email-masked]>>; HTTP Working Group <[email-masked] <mailto:[email-masked]>>

---

From: Martin Thomson <[email-masked]>
Date: Sat, 5 Dec 2015 20:28:47 +1100

On 5 December 2015 at 19:19, Cory Benfield <[email-masked]> wrote:
> So to be clear, Martin: Eliot and Mike wanted something like the text you
> have. I wanted something substantially stronger than that. =)

As I'm fond of saying, pull requests are always welcome.  Especially
well-considered and articulate ones, which I'm sure that yours will
be.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 7 Dec 2015 15:51:58 +0100

For me I'd like to see a few more words, since we know a bit more about
risks associated with at least one form of key management.  Specifically
around automated key management.  Probably this should be its own
subsection, but here at least is a start (consider this an old fashioned
pull request):

<-->snip<-->
It is possible for an attacker to encrypt the content in the public
key(s) of one or more individuals, where a file sharing service or a
blind cache is either broken into or otherwise populated, leading to the
potential infection of one or more recipients who process the content.

There are several different approaches to addressing this problem.  The
first would be for end user systems to apply a high amount of scrutiny
on any such encrypted content, regardless of the sender (since the
sender may have been compromised) in much the same way that unwanted
email messages are retreated today.  A second method would be for the
recipient to have the message scanned for viruses, either on-board or
through some network service.  A third method would be for a model to be
developed where content is attested to by an agent that the publisher
trusts with the content whose signature intermediaries and recipients
might also trust.  These methods are not mutually exclusive.
<-->snip<-->

Eliot

On 12/5/15 9:19 AM, Cory Benfield wrote:
> So to be clear, Martin: Eliot and Mike wanted something like the text
> you have. I wanted something substantially stronger than that. =)
>
>> On 4 Dec 2015, at 19:25, Martin Thomson <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> I suppose that the very top of the security considerations section
>> wasn't obvious enough for folks:
>> On Dec 5, 2015 5:56 AM, "Mike Bishop" <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>     Likewise on the non-normative text.  The draft shouldn't specify
>>     how the key to decrypt the content is obtained.  This is a
>>     building block for a larger solution which would have to describe
>>     how/where clients obtain keys securely and validate them -- this
>>     draft isn't something you'd implement stand-alone.  Pointing out
>>     that when you use this building block in a system, that's
>>     something you have to handle properly is a reasonable cautionary
>>     note to add.
>>
>>     To: Cory Benfield <[email-masked] <mailto:[email-masked]>>;
>>     Poul-Henning Kamp <[email-masked]
>>     <mailto:[email-masked]>>; Mike Bishop
>>     <[email-masked]
>>     <mailto:[email-masked]>>;
>>     <mailto:[email-masked]>
>>     Cc: Mark Nottingham <[email-masked] <mailto:[email-masked]>>; HTTP
>>     Working Group <[email-masked] <mailto:[email-masked]>>
>>     > Earlier in this thread I raised a concern I have about the way
>>     this draft accesses keys. In particular, it does not appear to
>>     specify any requirement that keys be tied to specific origins or
>>     in some way limited in scope: a conforming implementation would
>>     be able to have a single global registry of keys that can be used
>>     to decrypt content coming from anywhere.
>>     >
>>     > I believe this represents a security risk and should either be
>>     addressed in Section 6, or this draft should be accompanied by
>>     another that specifies key management in this case.
>>
>>     I'm not particularly certain of your specific concern, but I
>>     would suggest that at least some non-normative mention of key
>>     management would be a helpful addition.
>>
>>     Eliot
>>
>>
>>
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 8 Dec 2015 07:57:35 +1100

Old-fashioned pull requests are great.  I'm just not sure that this is
right.  I don't think that you have provided enough context.

On 8 December 2015 at 01:51, Eliot Lear <[email-masked]> wrote:
> <-->snip<-->
> It is possible for an attacker to encrypt the content in the public key(s)

I can't make sense of this statement.  Is the intent to describe a
scenario where malware is encrypted so that only the intended victim
can decrypt it?  And that the victim relies on some intermediation for
defense against this kind of thing?  Why not say that?

Of course, you need to approach this in a more careful fashion.  Your
model - if I'm right - presumes a lot about where malware
countermeasures are best deployed.  There's an unrecognized
architectural question that you are implying a particular answer to.
Having the text acknowledge that this is a choice is important, unless
you want to open that up for debate.

> of one or more individuals, where a file sharing service or a blind cache is
> either broken into or otherwise populated, leading to the potential
> infection of one or more recipients who process the content.

Note that there isn't any context in the draft that suggests that this
applies to blind caching (a very specific concept) or even file
sharing.

> first would be for end user systems to apply a high amount of scrutiny on
> any such encrypted content, regardless of the sender (since the sender may
> have been compromised) in much the same way that unwanted email messages are
> retreated today.  A second method would be for the recipient to have the
> message scanned for viruses, either on-board or through some network
> service.

I don't see any practical difference between the first and second
suggestions here.

> A third method would be for a model to be developed where content
> is attested to by an agent that the publisher trusts with the content whose
> signature intermediaries and recipients might also trust.  These methods are
> not mutually exclusive.

Your third method seems impractical given that no such system exists.

>> To: Cory Benfield <[email-masked]>; Poul-Henning Kamp
>> <[email-masked]>; Mike Bishop <[email-masked]>;

---

From: Eliot Lear <[email-masked]>
Date: Mon, 7 Dec 2015 22:23:28 +0100

Hi Martin,

Thanks for the comments.  I'll take another pass at this based on your
feedback.  With that in mind, please see below.

> defense against this kind of thing?  Why not say that?

Maybe partially that in as much as an end system confers trust on an
intermediary (think dropbox.com or some such), but as much that the
intermediary itself might be unwittingly participating in a malware
attack, in which case its resources are misappropriated.

> you want to open that up for debate.

I'm not quite certain what you're saying.  I'm happy to acknowledge an
unrecognized architectural question so long as we can state state that
clearly (whatever it is) ;-)
> applies to blind caching (a very specific concept) or even file

What got me going were these two use cases that got discussed up
thread.  I think they're fine use cases, but they pose certain risks
that would be worth highlighting.  They can be mitigated as discussed
below.  Perhaps the wording should be more general?

> I don't see any practical difference between the first and second

The 2nd remediation might be a specific means of the 1st to be fair. 
But as Cory mentioned upthread, maybe be a little more cautious about
opening such files automatically, but rather posting an appropriate
warning.  Apple does this for any code that they would execute, for
instance.  The precise mitigation will depend on the client
application.  Think non-browser for things to get weird.  That's why I
didn't get into details.  Implementers will need to think about it.

> Your third method seems impractical given that no such system exists.

It may be, but you have also done some work that could be the basis of
such a system, which again I mentioned up thread.  I'd be happy to
suggest more when that draft gets adopted :-)

Eliot

---

From: Martin Thomson <[email-masked]>
Date: Tue, 8 Dec 2015 08:51:49 +1100

> attack, in which case its resources are misappropriated.

I think that's a good angle to use.  I honestly doubt than many
intermediaries would be happy to be misappropriated like that :)

> clearly (whatever it is) ;-)

I think that your proposal had some sort of implication that malware
scanning was the responsibility of some sort of intermediary.  That's
probably unintentional.  I think that all we need to do is acknowledge
that this is a (value-neutral) choice.

> below.  Perhaps the wording should be more general?

Maybe this can be more compact:

Some clients rely on an intermediary to filter unwanted content, such
as malware.  If such an intermediary is unable to decrypt content,
then it could be unable to fulfill its task. In this case, clients
might need to use other means of protection, such as acquiring
information about the acceptability of content via other channels.

This does provide fewer clues about what you might do.  I'm not
opposed to providing more explicit hints.  But we don't really have
anything concrete to point out, so I don't really want to get into too
much detail.

> suggest more when that draft gets adopted :-)

Sure, but like I note above, that's only a tiny piece of what we'd need.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 8 Dec 2015 08:16:08 +0100

Hi Martin,

Thanks for your response.  Please see below.

> that this is a (value-neutral) choice.

Based on your explanation I now understand what you're saying.  You have
indeed surfaced unstated architectural claim here by both of us.  Mine
is this:

    The more opportunities there are for bad links, the more infections
    there will be.  And the converse holds true, of course. 
    Furthermore, not all systems will be inoculated from malware.

Let us assume that this statement is true, or Google and Yahoo! are
spending needlessly spending a whole lot of money scrubbing such links.

Yours, I think, is this:

    The end system is in the best position to protect itself against
    malware.

I largely agree.  Let's agree that these two architectural principles
are not mutually exclusive.

I will add one more assertion that I believe we also can agree on, which
is that some people can be fooled into clicking on links.  Phishing is
not the only threat vector.  A full scale automated system that uses
this encryption mechanism would also be at risk, and perhaps more
dangerous.  But that there is at least one threat that is well
understood by a lot of people is enough to recognize the problem.

The threat we must address is exacerbation of attacks (an example being
phishing) as relates to encrypted files where attackers have access to
recipients' public keys/certs.

Stating that "clients might need to use other means of protection..."
addresses  the latter architectural statement without acknowledging the
former.  We need to go just a bit further and simply state that "all
systems that receive the encrypted object are advised to take what
precautions they can to have some confidence that the object is free of
malware."   And then I would suggest several examples are in order, so
as not to be too opaque.

As an aside, part of the problem with this discussion is with the use of
the term "intermediary".  While perhaps correct in some sense, it is so
vague as to introduce an ambiguity that may further cause additional
confusion when having such discussions.  In one of the cases I
mentioned, we have a classic cache which neatly fits the term
"intermediary" as everyone understands it.  The term is expansive in its
use, and thus a tad misleading, regarding the case where the server is
The origin server for the object.  The above change covers both cases,
by the way.

Eliot

---

From: Martin Thomson <[email-masked]>
Date: Wed, 9 Dec 2015 07:39:31 +1100

On 8 December 2015 at 18:16, Eliot Lear <[email-masked]> wrote:
> former.  We need to go just a bit further and simply state that "all systems
> that receive the encrypted object are advised to take what precautions they
> can to have some confidence that the object is free of malware."   And then
> I would suggest several examples are in order, so as not to be too opaque.

Yeah, I'm totally on board with that.

Your point regarding "intermediary" is well-taken.  It was just a
convenient handle.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 22 Dec 2015 17:00:40 +1100

Sorry, I thought I'd sent this out a while back.

It's clear there's broad support for adopting this draft. Martin, please go ahead and at it to the extensions repo and submit an -00.

Cheers,