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

Re: TLS at transport level vs stream multiplexing and aggregation (http "routers")

From: Nicolas Mailhot <nicolas.mailhot@laposte.net>
Date: Sun, 17 Nov 2013 22:58:30 +0100
Message-ID: <d292b30211ec148de94fe36d65405cbd.squirrel@arekh.dyndns.org>
To: "Adrien de Croy" <adrien@qbik.com>
Cc: "Mike Belshe" <mike@belshe.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>

Le Dim 17 novembre 2013 22:44, Adrien de Croy a écrit :
> ------ Original Message ------
> From: "Mike Belshe" <mike@belshe.com>
> To: "Adrien de Croy" <adrien@qbik.com>
> Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
> Sent: 18/11/2013 10:24:44 a.m.
> Subject: Re: TLS at transport level vs stream multiplexing and
> aggregation (http "routers")
>>I think this is an interesting concept.  We did consider a number of
>>scenarios like this for SPDY as well - with a small amount of extra
>>certificate/meta data changes you could do it.
>>But you should probably try to garner some implementation experience
>>with it.  There are a lot of details.  I'm also unclear what the goals
>>would be.
> the main goals would be:
> a) allow aggregation of streams
> b) allow flexibility around whether crypto is used or not
> c) allow point to point (e.g. router to router) authentication and
> privacy (e.g. traversing public networks)
> d) allow for fault-tolerant system architectures (e.g. by allowing a
> stream to be handed to another path/router).


and I'd add

e) reuse a security model everyone is knowledgeable and comfortable with,
physical mail (where routing is public and content -not)

d) clearly separate intermediary auth and messages from endpoint auth and
messages without requiring to stuff them in a single tls channel that
requires intermediaries to open to communicate with the client


Nicolas Mailhot
Received on Sunday, 17 November 2013 21:59:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:20 UTC