Re: Call for Adoption: Encrypted Content Encoding

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

On Tue, Dec 1, 2015 at 12:01 PM, Kyle Rose <krose@krose.org> wrote:
>> 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

Received on Tuesday, 1 December 2015 18:26:08 UTC