- From: HAYASHI, Tatsuya <lef.mutualauth@gmail.com>
- Date: Sun, 15 Jul 2012 08:02:03 +0900
- To: Phillip Hallam-Baker <hallam@gmail.com>
- Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Willy Tarreau <w@1wt.eu>, Tim Bray <tbray@textuality.com>, James M Snell <jasnell@gmail.com>
Hummm. I think that it is right. Thanks. On Sun, Jul 15, 2012 at 6:00 AM, Phillip Hallam-Baker <hallam@gmail.com> wrote: > If this is worth doing at all it is something that can be most easily > performed in a HTTP/2.0 context where the whole legacy question > becomes moot-ish > > > > On Sat, Jul 14, 2012 at 2:32 PM, HAYASHI, Tatsuya > <lef.mutualauth@gmail.com> wrote: >> PHK's ideal world, I also share it. >> >> However, it is not understood whether it is contained in the present >> WG charter. >> I still think that our goal is ambiguous. >> >> To speak of extremes, we have a two targets. >> >> 1) >> Efficiency is improved. and compatibility is maintained as much as possible. >> 2) >> The ideal which deserves HTTP/2.0 and which can be used for 20 years >> or more is aimed at. >> >> These are not contrary. >> We have to pursue the both as much as possible. >> But, The semantics must not change. >> >> I think that the name of HTTP/2.0 is making a goal difficultly. >> >> I thinking... >> ex) HTTP layer Session is necessity? >> If it is HTTP/1.1tris? >> If it is HTTP/1.2? >> and If it is HTTP/2.0? >> >> We need to deepen an concrete discussion more. >> >> -- >> HAYASHI, Tatsuya >> Lepidum Co. Ltd. >> >> On Sat, Jul 14, 2012 at 2:52 PM, Willy Tarreau <w@1wt.eu> wrote: >>> On Fri, Jul 13, 2012 at 08:21:03PM -0700, Tim Bray wrote: >>>> On Fri, Jul 13, 2012 at 11:21 AM, Poul-Henning Kamp <phk@phk.freebsd.dk>wrote: >>>> >>>> >>>> > TLS communication today already have an envelope consisting of >>>> > IP# + TCP port numbers, and unless your adversary is totally >>>> > incompetent, he also has the DNS lookup that gave you that IP#. >>>> > >>>> > QED: Putting the "Host:" in the HTTP envelope does not leak any >>>> > information your adversary doesn't already have or can guess. >>>> > >>>> >>>> That?s just not true. There are lots of ways to get to a particular origin >>>> server, and I would think that for a malicious person in the middle, the >>>> Host header would be more interesting than the ostensible IP address. On >>>> the other hand, I do understand why a payload-oblivious load balancer would >>>> need to see that header. It is simply the case that we have two objectives >>>> which are apparently in conflict. No, I don?t have a solution (or even a >>>> strong opinion, yet, although I?m inclined to err on the side of protecting >>>> user privacy at the expense of almost all else). -Tim >>> >>> Well, TLS offers SNI which also reveals the Host header in clear text, so >>> your extreme view of privacy doesn't seem to be shared as much wich even >>> these guys. Also, building a protocol fortress that prevents anyone from >>> implementing it in real life is an effective way of protecting user privacy >>> since the user won't have access to anything and thus won't reveal his >>> intents. Maybe some people would even consider that revealing they have >>> access to the internet affects their privacy so they need an invisible >>> connection... At one point a limit must be set, otherwise it becomes >>> totally non-sense. Host and IP are reasonably interchangeable, are used >>> for routing the protocol to its destination, and if someone doesn't want >>> to show what host he's going to, he'd better leave the net. And if even >>> the TLS guys accept this, then I think this is a much acceptable limit. >>> >>> Regards, >>> Willy >>> >>> > > > > -- > Website: http://hallambaker.com/ -- HAYASHI, Tatsuya Lepidum Co. Ltd.
Received on Saturday, 14 July 2012 23:02:30 UTC