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

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

From: Roberto Peon <grmocg@gmail.com>
Date: Mon, 14 Jan 2013 10:05:22 -0800
Message-ID: <CAP+FsNcfkNahrt-wW5hDRsrNXvtAmACbTeGT_LOYRpQ4oh=3HA@mail.gmail.com>
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>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 14 January 2013 18:05:54 GMT