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

As a reminder of some of the difficulties, without an integrity MAC or
equivalent, you can ensure nothing :)
Though James' draft includes an integrity frame, it doesn't require its
usage, and thus suffers from downgrade attacks.
Requiring its usage would be helpful... :)
-=R


On Sun, Nov 17, 2013 at 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/
>
>
>
>
>