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

as they keep telling us, http is a _message_ based protocol after all.



------ Original Message ------
From: "Roberto Peon" <grmocg@gmail.com>
To: "Nicolas Mailhot" <nicolas.mailhot@laposte.net>
Cc: "Adrien de Croy" <adrien@qbik.com>; "Mike Belshe" <mike@belshe.com>; 
"ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Sent: 18/11/2013 11:30:03 a.m.
Subject: Re: TLS at transport level vs stream multiplexing and 
aggregation (http "routers")
>Sounds like an interesting experiment (as Mike already said, we 
>considered this way back when).
>-=R
>
>
>On Sun, Nov 17, 2013 at 1:58 PM, Nicolas Mailhot 
><nicolas.mailhot@laposte.net> wrote:
>>
>>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).
>>
>>Awesome!
>>
>>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
>>
>>Regards,
>>
>>--
>>Nicolas Mailhot
>>
>>
>