RE: new version trusted-proxy20 draft

[Liliana Dinale <[e-mail]>]

 
Dear all
Let me first introduce myself. I will start attending IETF at the London meeting joining your WG and looking forward to work with you. It is my pleasure to announce the fact that Ericsson plans to show a demo implmenting the UA and the Proxy solution.


Thank you and kind regards,
Liliana


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of William Chan (???)
Sent: February-19-14 7:40 PM
To: Salvatore Loreto
Cc: Peter Lepeska; Paul Hoffman; Patrick McManus; HTTP Working Group; [e-mail]; GUS BOURG
Subject: Re: new version trusted-proxy20 draft

On Wed, Feb 19, 2014 at 1:17 PM, Salvatore Loreto <[e-mail]> wrote:
>
> On Feb 19, 2014, at 7:09 PM, William Chan (陈智昌) <[e-mail]> wrote:
>
>> Yeah, I'd like to see the "secure proxy" proposal separated out from 
>> the "trusted proxy" proposal. Let's move forward on the "secure proxy"
>> one. I think the "trusted proxy" proposal is more complicated.
>
> I agree
> and the draft is really proposing a "secure proxy" solution in line 
> with your definition of "secure proxy"
>
> indeed we are only proposing the possibility for the proxy to ask 
> consent to opt in for http:// resources traffic

Let's be clear, these are two different things. There's "secure proxy"
which is securing the connection between the proxy and the client. I'm supportive of standardizing this. Then there's this opting into allowing http:// resources to be sniffed by signaling it via ALPN.
What's the value proposition here? Why not issue the request to the proxy if you want to let it see it, just like we do for configured HTTP proxies?

>
> /Sal
>
>
>>
>> On Wed, Feb 19, 2014 at 7:30 AM, Peter Lepeska <[e-mail]> wrote:
>>> My two takeaways from Zurich on trusted proxy were as follows:
>>>
>>> 1) We need to look at use cases of trusted proxy and seek 
>>> alternative technologies. I've attempted to start this process on 
>>> another thread, which I believe shows current (and future) 
>>> alternatives are partial solutions that we can conclude are 
>>> inadequate overall in delivering the functionality and performance users/admins/service providers demand.
>>> 2) Until someone proposes a UI for opt-in and opt-out of trusted 
>>> proxy that is both user friendly and does not make MITM attacks 
>>> (rogue trusted proxies) easier to execute, then the debate on this 
>>> topic is at a standstill. I am working on ideas in this area but it will take more than just a few weeks.
>>> It would be really great if others got involved.
>>>
>>> Salvatore's draft has some really good ideas but it does not attempt 
>>> to address #2 above, which most agreed was the sticking point on 
>>> trusted proxy, which we distinguish from "secure proxy" by the fact 
>>> that a trusted proxy can see https-schemed traffic in plaintext.
>>>
>>> Peter
>>>
>>>
>>> On Tue, Feb 18, 2014 at 11:54 PM, William Chan (陈智昌) 
>>> <[e-mail]>
>>> wrote:
>>>>
>>>> On Tue, Feb 18, 2014 at 8:18 PM, Paul Hoffman 
>>>> <[e-mail]>
>>>> wrote:
>>>>> On Tue, Feb 18, 2014 at 6:02 PM, William Chan (陈智昌)
>>>>> <[e-mail]>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> And furthermore, I should add that I don't really think it's in 
>>>>>> the users' interests to have an intermediary be able to snoop 
>>>>>> listen in on all their https traffic. I don't really see the 
>>>>>> value for end users in standardizing any mechanism for doing this. Is there any?
>>>>>
>>>>>
>>>>> This still comes back to the theory that a trusted, explicit 
>>>>> firewall, such as a corporate firewall, should be able to snoop on 
>>>>> all traffic leaving the protected network. There are plenty of 
>>>>> good reasons to do this, and plenty of people who disagree that 
>>>>> there are any possible reasons.
>>>>
>>>> Good point. This is a controversial topic that we're unlikely to 
>>>> see consensus on in the near future. Let me ask another question. 
>>>> Is there a user agent that plans on supporting this proposal? At 
>>>> the Zurich interim, IIRC, Patrick (Firefox), Rob (IE/WinInet), and 
>>>> I (Chromium) all said we do not support this. If that's in error, please speak up.
>>>> Otherwise, if no user agent plans on supporting this, I don't see 
>>>> the value of standardizing this.
>>>>
>>>
>