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.

Thinking larger - I agree with you that TLS is at the wrong layer.  We've
wedged it into the application space and transport layers today.  You're
advocating moving it up a layer.   Whereas I would actually move it down a
layer :-)  Today our transport is vulnerable to numerous types of attacks.
 I think Dan Bernstein has it right with his layering in curvecp (
http://curvecp.org/) and the minion guys have some proposals that lean this
way as well.

The problem is that if your control structures are exposed in an
unauthenticated and unencrypted manner, then anyone can hijack/DoS any
connection very easily.  But this is a much larger change than HTTP/2.

Mike



On Sun, Nov 17, 2013 at 12:59 PM, Adrien de Croy <adrien@qbik.com> wrote:

>  Hi all
>
> there has been talk in the past about http message routers that forward
> messages relating to multiple concurrent streams over the same underlying
> protocol stream.
>
> I'm a big fan of this idea, but I think requiring http2 to be over TLS
> would effectively prohibit this.
>
> If the TLS is being used to establish credentials between client and
> server, and is connection-associated, then it holds the same set of badness
> that everyone holds against NTLM.
>
> This means that TLS is being applied at the wrong level.
>
> I think we should look into using TLS at the stream level, rather than
> transport.  This would allow a single TCP connection to contain multiple
> streams where each stream can be between different final endpoints, with
> different TLS layers.  And include unencrypted streams as well.
>
> Where it is desired to minimise TLS setup overhead where all streams on a
> connection will use the same TLS context, then allow for that in the
> protocol as well.
>
> That would then allow point to point links to use TLS to secure messages
> that may be themselves secured with TLS at the stream level or not.
>
> Adrien
>