- From: Roberto Peon <grmocg@gmail.com>
- Date: Mon, 14 Jan 2013 10:05:22 -0800
- To: James M Snell <jasnell@gmail.com>
- Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Ilya Grigorik <ilya@igvita.com>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAP+FsNcfkNahrt-wW5hDRsrNXvtAmACbTeGT_LOYRpQ4oh=3HA@mail.gmail.com>
And this one too. https://datatracker.ietf.org/doc/draft-rpeon-httpbis-exproxy/ But, isn't all this a non-starter and outside the scope? -=R On Mon, Jan 14, 2013 at 8:52 AM, James M Snell <jasnell@gmail.com> wrote: > Well.. jumping into in a bit.. there is this draft: > > http://tools.ietf.org/html/draft-snell-httpbis-keynego-00 > > In it, I define an experimental in-session key negotiation mechanism built > around SPDY's framing mechanism. The way it's defined, it would allow for > both hop-by-hop and end-to-end encryption scenarios and provides a much > more flexible model than what exists today with TLS... for one, security > can be negotiated and renegotiated on the fly without tearing down and > reestablishing the tcp connection. Within a single SPDY session you could > actually have multiple layers of encryption going on, with the SYN_STREAM > and the DATA frames each being encrypted using distinct keys negotiated > with different entities involved in the connection. > > I will stress that, for now, this is entirely theoretical and > experimental, but something like this would address the use case. > > - James > > > On Fri, Jan 11, 2013 at 1:46 PM, Stephen Farrell < > stephen.farrell@cs.tcd.ie> wrote: > >> Ok I think this has wandered far enough for me. Send me a link to your >> draft when it's ready. >> S >> >> On 11 Jan 2013, at 20:44, "Poul-Henning Kamp" <phk@phk.freebsd.dk> wrote: >> >> > -------- >> > In message <50F0774A.6010706@cs.tcd.ie>, Stephen Farrell writes: >> > >> >>> There is nothing "state of the art" about mixing p2p and e2e >> >>> trust and security, PTT's and banks have been doing it for >> >>> centuries. >> >> >> >> Feel free to post details. I at least don't know what >> >> you mean. >> > >> > I'm sure you do, you just don't know that you know it. >> > >> > If you are working in a big organization, I'm sure you don't >> > go to the post-office yourself, you have an intern mail-service >> > that will do so for you, and thanks to the separation of >> > envelope from message, they can do so, without opening your >> > letter. >> > >> >> (I'm also not aware of how 16th century PTT's operated >> >> to be honest. RFC 1149 perhaps?:-) >> > >> > Amongst other technologies. >> > >> > I'm sure the chinese and the romans would beg to differ, but >> > read for instance: >> > >> > >> http://www.scotsman.com/lifestyle/heritage/the-oldest-post-office-in-the-world-1-465812 >> > >> >>> The problem the HTTPbis effort has, is that it's trying to >> >>> improve on one of the worlds most popular and used protocols[1]. >> >>> >> >>> Addressing some of its actual user-perceived shortcomings would >> >>> be a very smart move from a marketing point of view. >> >> >> >> Yes, but this isn't a marketing exercise. >> > >> > Ask the IPv6 people if they still think that was a smart >> > position to take. >> > >> > Catering to your users needs is a good way to win adoption. >> > >> > -- >> > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 >> > phk@FreeBSD.ORG | TCP/IP since RFC 956 >> > FreeBSD committer | BSD since 4.3-tahoe >> > Never attribute to malice what can adequately be explained by >> incompetence. >> > >> >> >
Received on Monday, 14 January 2013 18:05:50 UTC