W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: FYI... In-Stream Key Negotiation Initial Draft

From: Roberto Peon <grmocg@gmail.com>
Date: Sat, 4 Aug 2012 20:38:04 -0700
Message-ID: <CAP+FsNddpddajN7WDA=GyD6k37rVnZPTUwmVmn=kD2PpMEXhQw@mail.gmail.com>
To: James M Snell <jasnell@gmail.com>
Cc: ietf-http-wg@w3.org
Awesome! This ties into possible explicit proxy with TLS.

On Aug 3, 2012 3:25 PM, "James M Snell" <jasnell@gmail.com> wrote:

> For the purposes of discussion, I have published a rough first draft of
> the SPDY KEY_NEGO mechanism I discussed previously.
>   http://www.ietf.org/id/draft-snell-httpbis-keynego-00.txt
> The short version is: this introduces the ability to perform key
> negotiation for encrypted streams *within* an established SPDY session,
> even if TLS is not being used to secure the connection. This is largely
> theoretical and experimental at this point but I have done some initial
> implementation to at least demonstrate (mostly for myself) that the basic
> idea works in theory. However, there's much that would need to be done.
> To answer the more immediate question: Why would we do this... the short
> answer is that this approach gives us a number of things that TLS currently
> does not.. specifically: the ability to multiplex secure and insecure
> traffic over a single TCP/IP connection, server-initiated security,
> in-stream end-to-end integrity checking, and dynamic, on-the-fly
> (re)negotiation of keys on the fly without having to tear down and
> reestablish the connection.
> There is much more that needs to be done to flesh this out, obviously, and
> I'm not yet convinced that it's a great idea. Much more experimentation and
> implementation would need to go into determining that, but I wanted to get
> the basic idea documented and out there for discussion and to get some
> additional eyes looking at it.
> As always, comments and feedback are welcomed.
> - James
Received on Sunday, 5 August 2012 03:38:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:06 UTC