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

Re: Call for Adoption: Encrypted Content Encoding

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Wed, 2 Dec 2015 04:21:34 +1300
To: ietf-http-wg@w3.org
Message-ID: <565DBAFE.1020508@treenet.co.nz>
On 2/12/2015 3:56 a.m., Roland Zink wrote:
> 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.

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

Received on Tuesday, 1 December 2015 15:22:12 UTC

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