Subject: Call for Adoption: Encrypted Content Encoding

From: Mark Nottingham <[email-masked]>
Date: Wed, 25 Nov 2015 15:53:07 +1100

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,

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

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 25 Nov 2015 07:44:33 +0100

Hi Mark,

On Wed, Nov 25, 2015 at 03:53:07PM +1100, Mark Nottingham wrote:
> Please comment on-list; we???ll make a decision about adoption at the end of next week.

I agree we should adopt it. I've been working in bank environments where
in-house payload encryption was used everywhere so that headers could
be kept in clear for message routing / load balancing. TLS doesn't
allow this since each node can see everything in clear once decrypted.
Such a proposal makes it much simpler to design such a system and keep
it standards-compliant.

So +1 for me.

Willy

---

From: John Mattsson <[email-masked]>
Date: Wed, 25 Nov 2015 10:01:07 +0000

>Such a proposal makes it much simpler to design such a system and keep

This is a very useful and very well written document. Definitely adopt.

+1 for me as well.

John

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 26 Nov 2015 01:13:42 +1300

> This is a very useful and very well written document. Definitely adopt.

+1 from me too for adoption.

Amos

---

From: Cory Benfield <[email-masked]>
Date: Wed, 25 Nov 2015 15:12:14 +0000

> On 25 Nov 2015, at 04:53, Mark Nottingham <[email-masked]> wrote:
> 

In general, I’m +1 on this, and can also claim Intent to Implement for the Python Requests library.

I do have a few general concerns with the spec as written. Firstly, some of the text remains fairly unclear, though that could just be the problem of an early draft. I am however concerned a bit with the padding model: it seems remarkably unusual to front-pad, and the draft makes no effort to explain why it was done the way it was. Can someone elaborate on that decision?

---

From: Martin Thomson <[email-masked]>
Date: Wed, 25 Nov 2015 15:27:14 -0800

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

n.b., I've received a bit of security review offline.  There are some
changes that I have currently staged in pull requests.  Web push will
want to use the modified key derivation.

Just in case anyone was thinking of jumping the gun, as we already did
in Firefox :)

---

From: "Walter H." <[email-masked]>
Date: Fri, 27 Nov 2015 05:48:56 +0100

Hello,

can someone tell me REAL USEFUL use case where someone would need
this way of having something encrypted on a webserver?

HTTP means hypertext transport protocol and nothing more;

there has always been the alternative to transfer an encrypted file
(e.g. a .rar file, or .zip file or whatever) using any way of transfer 
(e.g. FTP, HTTP, HTTPS, ...)
there is no reason not doing so now.

Walter

---

From: Martin Thomson <[email-masked]>
Date: Fri, 27 Nov 2015 18:43:32 -0800

> this way of having something encrypted on a webserver?

The two use cases where this is likely to appear in the short term are:

1. web push - where an encrypted resource is created on a server by
one entity and retrieved by another.  The server doesn't get to see
the contents.

2. blind caching - the same as in web push actually.  An origin server
uses an untrusted cache and wants to encrypt data so that the cache
can't modify or view the content.

---

From: "Walter H." <[email-masked]>
Date: Sun, 29 Nov 2015 11:20:57 +0100

On 28.11.2015 03:43, Martin Thomson wrote:
> On 26 November 2015 at 20:48, Walter H.<[email-masked]>  wrote:
I'd say this is the wrong answer, this can be done alternativly as used 
to do
(pushing an encrypted .rar or .zip is exactly this use case with advantage,
there is no implicit malware impact ...)

for security reason exactly this way you mentioned must be forbidden;
there mustn't be a way pushing malware to a server,
which the server itself has no possibility to clean it ...

> can't modify or view the content.
as I think this is a security hole, too.

now where is a REAL USEFUL use case?

---

From: John Mattsson <[email-masked]>
Date: Mon, 30 Nov 2015 07:45:13 +0000

>which the server itself has no possibility to clean it ...

Using .rar or .zip for encryption is not an option. Not only are they
proprietary, non-standardized compression algorithms, the encryption parts
are based on passwords and at least the .zip encryption is seriously
flawed…

---

From: "Walter H." <[email-masked]>
Date: Mon, 30 Nov 2015 11:32:32 +0100

On 30.11.2015 08:45, John Mattsson wrote:
>
> On 29/11/15 11:20, "Walter H."<[email-masked]>  wrote:
>
I didn't say that these are the only alternative ways, .zip or .rar is 
just an example;
it depends on what you want to encrypt;
if for is only something standarized an option, then use the 
OpenDocument standard;
these can be encrypted, too;

by the way: the need of this nonsense;
because its like open the door and shooting down anybody non-blind who 
comes in ...

use HTTPS ...

---

From: John Mattsson <[email-masked]>
Date: Mon, 30 Nov 2015 10:42:59 +0000

>because its like open the door and shooting down anybody non-blind who

I think this should be used in addition to HTTPS. TLS is not the solution
to everything. In the WebPush scenario, using only HTTPS would lead to the
Push Service having access to, and being able to modify the content.
Content-enryption + HTTPS looks like a good general solution that can be
used independently of content-type.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 30 Nov 2015 12:06:53 +0100

Hi,

On 11/29/15 11:20 AM, Walter H. wrote:
> I'd say this is the wrong answer, this can be done alternativly as
> used to do

I have to agree that this is a big issue.  Here's the problem: we like
to say that we would devolve the responsibility to the end user who is
pushing the file.  The problem occurs when the end user who is pushing
the file has been broken into and her credentials have been stolen. 
That's the classic BOTnet model.  And so this poses a new vector that
wasn't there before.

But I would suggest that there are mitigations to this attack, one such
being that the content is attested to by a malware protection system
(McAfee, Kaspersky, etc) such that server might trust it, and might
otherwise reject such content.

In as much as we can have the discussion as to how to mitigate the
attack, I'm +1 for adopting.  Otherwise -1.

Eliot

---

From: Roland Zink <[email-masked]>
Date: Mon, 30 Nov 2015 12:50:14 +0100

> That's the classic BOTnet model.  And so this poses a new vector that
How is this different from the current web model allowing ads to be 
served from everywhere? There is no guarantee that the content can't be 
hijacked.
> otherwise reject such content.
Do you want to allow third parties access to the content?
> attack, I'm +1 for adopting.  Otherwise -1.
Regards,
Roland

---

From: Eliot Lear <[email-masked]>
Date: Mon, 30 Nov 2015 13:18:06 +0100

Hi Roland,

On 11/30/15 12:50 PM, Roland Zink wrote:
> served from everywhere? There is no guarantee that the content can't
> be hijacked.
I would say that those who reference those ads have a certain
responsibility to see that they are clean, but other than that I'm not
sure how the question is relevant.  The approach introduces a new vector
and it should thus be addressed.

> Do you want to allow third parties access to the content?

"Want" may be a bit strong.  Would I suffer it?  Possibly.  I would not
want to receive infected content.  But heck, what I wrote above was
meant more as way to prove to myself, if nobody else, that there is at
least one approach that can be employed to mitigate the threat.  Whether
server administrators use that method is another story.  Whether there
are other approaches is also a very fair question as far as I am concerned.

Eliot

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 1 Dec 2015 01:22:28 +1300

>> these can be encrypted, too;

By the same logic there is no need to send C-E:gzip on any responses.
Because one can simply deliver .gz files instead of the raw content.

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.

> used independently of content-type.

HTTPS is point-to-point.

Content-Encoding is truly end-to-end in a way that HTTPS can never
achieve: from uploader to downloader, regardless of what intermediary
action is taking place to optimize the traffic delivery.

Amos

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 1 Dec 2015 01:33:27 +1300

> served from everywhere? There is no guarantee that the content can't be

Also how is this different from malware infected machines uploading
encrypted payloads today?

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.

>> attack, I'm +1 for adopting.  Otherwise -1.

Mitigate in the same ways that transferring encrypted files over
HTTP/FTP/gopher/etc right now are handled. I.e. this is not a new vector.

Amos

---

From: "Walter H." <[email-masked]>
Date: Mon, 30 Nov 2015 20:53:32 +0100

> encrypted payloads today?
in case this malware is encrypted in an archive container, there is no 
problem, because
no key, no harm;

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

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

---

From: "Walter H." <[email-masked]>
Date: Mon, 30 Nov 2015 21:10:37 +0100

On 30.11.2015 13:22, Amos Jeffries wrote:
> 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 ...

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

---

From: "Walter H." <[email-masked]>
Date: Mon, 30 Nov 2015 21:13:52 +0100

On 30.11.2015 11:42, John Mattsson wrote:
> I think this should be used in addition to HTTPS. TLS is not the 
> solution to everything. In the WebPush scenario, using only HTTPS 
> would lead to the Push Service having access to, and being able to 
> modify the content. Content-enryption + HTTPS looks like a good 
> general solution that can be used independently of content-type. 
and how would this prevent the security impact I mentioned?

---

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

> publishing the public keys to the wide ...

TLS is also end-to-end

> I don't say that the malware detection on client side is not as good 
> as that on any server side; I'd say,
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.

---

From: Roland Zink <[email-masked]>
Date: Tue, 1 Dec 2015 01:19:11 +0100

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

RFC 7469 section 2.6. Validating Pinned Connections

  ...

  It is acceptable to allow Pin
    Validation to be disabled for some Hosts according to local policy.
    For example, a UA may disable Pin Validation for Pinned Hosts whose
    validated certificate chain terminates at a user-defined trust
    anchor, rather than a trust anchor built-in to the UA (or underlying
    platform).

---

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

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