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

Re: Call for Adoption: Encrypted Content Encoding

From: Roland Zink <roland@zinks.de>
Date: Tue, 1 Dec 2015 15:56:35 +0100
To: ietf-http-wg@w3.org
Message-ID: <565DB523.5080207@zinks.de>
Am 01.12.2015 um 15:02 schrieb Amos Jeffries:
> 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.
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.

Received on Tuesday, 1 December 2015 14:56:58 UTC

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