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

+1
On Nov 17, 2013 5:58 PM, "Roberto Peon" <grmocg@gmail.com> wrote:

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