- From: James M Snell <jasnell@gmail.com>
- Date: Mon, 14 Jan 2013 12:25:05 -0800
- To: Roberto Peon <grmocg@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: <CABP7Rbf5EStSRHYQigYOUiPRxwkm4Luqz77Gpu9Jwb3APRYZow@mail.gmail.com>
Possibly outside the scope for the core of http/2 but definitely something that is worth investigating orthogonally. At the very least, we ought to keep this in mind so we don't end up completely precluding the possibility of a solution here in the design of http/2. On Mon, Jan 14, 2013 at 10:05 AM, Roberto Peon <grmocg@gmail.com> wrote: > 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 20:25:55 UTC