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

It's very old and needs to be updated.  It was based on some very early
brainstorming so feel free to rip it apart. The whole idea was to just get
something started.

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

> I somehow hadn't seen that... great minds :)
>
> I'd encourage folks to look at this draft and have a play if they're
> inclined.
>
> Cheers,
>
>
>
> On 18/11/2013, at 12:48 PM, James M Snell <jasnell@gmail.com> wrote:
>
> > 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/
> >
> >
> >
> >
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>