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

Just a memory refresher..  The draft needs to be updated but I'm waiting
until stuff is more stable

http://tools.ietf.org/html/draft-snell-httpbis-keynego-00

- james
On Nov 17, 2013 5:45 PM, "Mark Nottingham" <mnot@mnot.net> wrote:

> Hi Adrien,
>
> I'm personally *very* interested in this as well; I've been thinking about
> it for a while, and talking to people about it too. There are a number of
> significant benefits possible with such an approach (which is very similar
> to SHTTP of old).
>
> Currently, I'm planning to prototype something once I have a Python
> implementation going (insert running joke here).
>
> Conceptually, it's pretty simple in HTTP/2; you'd just need a handful of
> new frame types to negotiate per-origin session keys, a flag to indicate
> that encryption is in use, and the first few bytes of the payload to
> indicate which session key is in use (since there can be more than one).
>
> The really interesting stuff comes in when you can selectively sign frames
> instead of encrypting them; that would allow a HTTP response to look like
> this:
>
> HEADERS [signed]
> HEADERS [encrypted]
> DATA [encrypted]
> DATA [encrypted]
> ...
>
> so that you can selectively expose headers (e.g., Cache-Control, Host) to
> intermediaries to allow them to do interesting things.
>
> Talking to security and other folks about this, the main concerns seem to
> be:
>   a) Security evaluation of a Whole New Protocol is hard. There are lots
> of new potential attacks
>   b) Taking what was a generic security function (TLS) and making it
> effectively application-specific -- with corresponding loss of value to the
> rest of the ecosystem
>   c) Greater information leakage because an attacker can see message
> boundaries
>   d) Exposing finer gradations of encryption / signature (as above) can
> lead to very subtle security properties; i.e., it's really easy to mess
> things up here.
>
> As Mike said, implementation experience will be critical before we can
> take something this big seriously; sucking TLS into HTTP2 is not a trivial
> task.
>
> Cheers,
>
>
> On 18/11/2013, at 7:59 AM, 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
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>
>