W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: Response to HTTP2 expresions of interest

From: HAYASHI, Tatsuya <lef.mutualauth@gmail.com>
Date: Sun, 15 Jul 2012 08:02:03 +0900
Message-ID: <CAGipQFkFqeKoP8bD6Bhovo2K8-Wv2RxC0BrbvfERNEjBr9okRQ@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 14 July 2012 23:02:37 GMT