W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2015

Re: Call for Adoption: Encrypted Content Encoding

From: Cory Benfield <cory@lukasa.co.uk>
Date: Tue, 1 Dec 2015 08:33:59 +0000
Cc: Roland Zink <roland@zinks.de>, Jim Manico <jim@manicode.com>, ietf-http-wg@w3.org
Message-Id: <DC6A3F5D-A64F-484A-A2A1-89DE3F4629CD@lukasa.co.uk>
To: "Walter H." <Walter.H@mathemainzel.info>

> On 1 Dec 2015, at 08:22, Walter H. <Walter.H@mathemainzel.info> wrote:
> 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;

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.

Received on Tuesday, 1 December 2015 08:34:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:40 UTC