W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: HTTPS, proxying, and all that...

From: James M Snell <jasnell@gmail.com>
Date: Mon, 14 Jan 2013 12:25:05 -0800
Message-ID: <CABP7Rbf5EStSRHYQigYOUiPRxwkm4Luqz77Gpu9Jwb3APRYZow@mail.gmail.com>
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>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 14 January 2013 20:25:58 GMT