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

------ 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).

All these things would require end-to-end crypto and authentication to 
be at stream layer.  The stream is the only end to end thing, therefore 
the crypto would need to be at that layer.

Transport layer crypto would serve a different purpose and could still 
be useful in some cases.  E.g. 2 routers establishing mutual trust for 
relaying messages.

Sure it's a bigger change, but if we went to port 100, the sky's the 
limit.

I wonder if we need to take a step back and re-evaluate what we are even 
trying to do and why.

If we're building a new and better web, based on the things we have 
learned from http/1.0, http/1.1, https and SPDY then if a new port 
number is on the cards, then we shouldn't arbitrarily limit ourselves.

>
>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.
there's already IPSEC.  It can't deal with per-stream auth and crypto 
contexts.

>
>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.
very easily?  Breaking into a TCP stream?  Maybe then TCP should be 
fixed.

Adrien


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