Re: Comments on Explicit/Trusted Proxy
"Adrien W. de Croy" <adrien@qbik.com> Fri, 03 May 2013 20:28 UTC
Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4F721F91BC for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 3 May 2013 13:28:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4yJrZrFxTVZ for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 3 May 2013 13:28:33 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id E452121F9080 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 3 May 2013 13:28:32 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UYMa2-0002Cw-Nk for ietf-http-wg-dist@listhub.w3.org; Fri, 03 May 2013 20:27:46 +0000
Resent-Date: Fri, 03 May 2013 20:27:46 +0000
Resent-Message-Id: <E1UYMa2-0002Cw-Nk@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <adrien@qbik.com>) id 1UYMZt-0002CC-U0 for ietf-http-wg@listhub.w3.org; Fri, 03 May 2013 20:27:37 +0000
Received: from smtp.qbik.com ([210.55.214.35]) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <adrien@qbik.com>) id 1UYMZq-0007XP-JA for ietf-http-wg@w3.org; Fri, 03 May 2013 20:27:37 +0000
Received: From [192.168.0.10] (unverified [192.168.0.10]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v8.0.0 (Build 4550)) with SMTP id <0019691551@smtp.qbik.com>; Sat, 04 May 2013 08:27:06 +1200
From: "Adrien W. de Croy" <adrien@qbik.com>
To: Roberto Peon <grmocg@gmail.com>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, HTTP Working Group <ietf-http-wg@w3.org>
Date: Fri, 03 May 2013 20:27:06 +0000
Content-Type: multipart/alternative; boundary="------=_MB4F5BAE41-78D8-4A08-B1A9-B4F6F083D6CC"
In-Reply-To: <CAP+FsNfDRYv+rL9-aaV574m0i3O=-fDujVSJdUPHU6HPF-N+zg@mail.gmail.com>
Message-Id: <em09a61c11-4e1a-4202-800a-d847be074471@bombed>
Mime-Version: 1.0
Reply-To: "Adrien W. de Croy" <adrien@qbik.com>
User-Agent: eM_Client/5.0.17944.0
Received-SPF: pass client-ip=210.55.214.35; envelope-from=adrien@qbik.com; helo=smtp.qbik.com
X-W3C-Hub-Spam-Status: No, score=-4.7
X-W3C-Hub-Spam-Report: AWL=-2.123, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.581, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UYMZq-0007XP-JA 8c5ff1a7a9edc3529dd785ae76c2c0f4
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Comments on Explicit/Trusted Proxy
Archived-At: <http://www.w3.org/mid/em09a61c11-4e1a-4202-800a-d847be074471@bombed>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17810
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
my next question, is how can the server tell the difference between a proxy and a client? ------ Original Message ------ From: "Roberto Peon" <grmocg@gmail.com> To: "Adrien W. de Croy" <adrien@qbik.com> Cc: "Stephen Farrell" <stephen.farrell@cs.tcd.ie>; "HTTP Working Group" <ietf-http-wg@w3.org> Sent: 4/05/2013 4:23:10 a.m. Subject: Re: Comments on Explicit/Trusted Proxy > >A proxy can represent the interests of a 3rd party which has nothing to >do with the client or server. The motivations of this 3rd party may not >be known, and are often enough antithetical to the wishes of the client >or server. > >The motivation of the client is more likely known-- they simply want >the content the server is providing, without allowing it to be modified >in ways which make for a poor experience (not just that page load, but >overall, including things like not having their bank account >mysteriously go to zero). > >-=R > > >On Fri, May 3, 2013 at 4:16 AM, Adrien W. de Croy <adrien@qbik.com> >wrote: >> >>As far as a server is concerned, why would a client be any more >>trustable than a proxy? >> >> >> >>Adrien >> >>------ Original Message ------ >>From: "Stephen Farrell" <stephen.farrell@cs.tcd.ie> >>To: "HTTP Working Group" <ietf-http-wg@w3.org> >>Sent: 3/05/2013 8:16:33 p.m. >>Subject: Re: Comments on Explicit/Trusted Proxy >>> >>>The contrast between this arm-waving nonsense and the precision >>>with which this wg are tackling HTTP/2.0 performance is frankly >>>astounding. >>> >>>Every web site in the world (and all the non-HTTP uses of TLS) >>>are supposed to be able to authenticate every proxy in the world >>>and know when its ok for a particular set of proxies to MITM an >>>TLS session? That's just BS. >>> >>>Note, I'm not specifically directing this at Roberto - I mean >>>the entire discussion rests on BS notions like the above. >>> >>>S. >>> >>>On 05/03/2013 01:53 AM, Roberto Peon wrote: >>>> The scheme allows for injection of bytes, but not within any of the >>>>secure >>>> tunnels. Instead, the proxy's bytes are clearly demarqued as >>>>different. >>>> >>>> The idea here is that the client or server should always know when >>>>the >>>> proxy has changed bytes, and it shouldn't, though it may inject >>>> bytes/requests/whatever in either direction. >>>> >>>> >>>> Sure, a client cert is one way of authenticating to the server. I >>>>didn't go >>>> into that much detail, but rather pointed out that the scheme >>>>proposed in >>>> that doc, that servers may decide they don't want to service >>>>queries from >>>> (some) proxies, and direct the client to either try directly, or >>>>allow the >>>> request to fail. >>>> >>>> -=R >>>> >>>> On Thu, May 2, 2013 at 5:48 PM, Adrien W. de Croy <adrien@qbik.com> >>>>wrote: >>>> >>>>> >>>>> proxies need to be able to modify the bytes or at least inject >>>>>messages >>>>> back to the client. >>>>> >>>>> e.g. >>>>> >>>>> * request denied by policy (e.g. you can't POST to that site due >>>>>to DLP >>>>> rules) >>>>> * serving from cache >>>>> * ad stripping >>>>> * malware blocking >>>>> * etc etc etc >>>>> >>>>> let alone stripping hop-by-hop headers etc >>>>> >>>>> So I don't think anyone will bother with a scheme that doesn't >>>>>allow for >>>>> that. If the only option of the intermediary is to delay or drop >>>>>the >>>>> connection, the client is going to be in the dark as to why. >>>>>Already the >>>>> user experience in this area is poor. >>>>> >>>>> As for intercepting proxies. Whilst I agree they are a PITN, they >>>>>are >>>>> strongly favoured by customers for several obvious reasons. >>>>> >>>>> Until we can get a wide-spread mechanism deployed to securely >>>>>FORCE >>>>> clients to use a proxy, we're going to see interception. >>>>> >>>>> As for MITM. Whilst we continue to think of it as an attack, we >>>>>will >>>>> continue to see resistance. It's clear some people see it only >>>>>negatively, >>>>> where others see this as an opportunity to improve things compared >>>>>to >>>>> current MITMs. >>>>> >>>>> Personally I would rather know what is going on, than be in the >>>>>dark and >>>>> be forced to swallow whatever I receive simply because I was >>>>>forced (by >>>>> company policy) to install a root cert for the spoofed certs. >>>>>Sites using >>>>> EV certs will show me what is going on if I know a site uses EV >>>>>certs, >>>>> since the EV breaks on spoofed certs. Or I need to check the cert >>>>>path on >>>>> any site to see if I can find the forced cert at the root. But >>>>>that's me, >>>>> not everyday punters. >>>>> >>>>> As for the server trusting the proxy. Why is that any different to >>>>>the >>>>> server trusting the client. Use a client cert. Can always fall >>>>>back to a >>>>> tunnel if the server indicates it needs a client cert. Currently >>>>>there's >>>>> no way around this issue in today's MITM systems except for >>>>>installing the >>>>> client cert on the proxy. >>>>> >>>>> Adrien >>>>> >>>>> >>>>> ------ Original Message ------ >>>>> From: "Roberto Peon" <grmocg@gmail.com> >>>>> To: "Peter Lepeska" <bizzbyster@gmail.com> >>>>> Cc: "HTTP Working Group" <ietf-http-wg@w3.org> >>>>> Sent: 3/05/2013 12:13:21 p.m. >>>>> Subject: Re: Comments on Explicit/Trusted Proxy >>>>> >>>>> responses inline. >>>>> >>>>> >>>>> On Thu, Apr 25, 2013 at 1:38 PM, Peter Lepeska >>>>><bizzbyster@gmail.com> >>>>> wrote: >>>>> >>>>>> Some comments on Roberto's doc: >>>>>> >>>>>> In the case where the user-agent has been configured with Chris >>>>>>as a >>>>>> trusted-proxy, either Anne's connect-stream MUST use either a >>>>>>null- >>>>>> cipher, or Anne MUST provide the decryption key material to >>>>>>Chris >>>>>> immediately after tunnel establishment, and before any data >>>>>>traverses >>>>>> the tunnel. >>>>>> >>>>>> >>>>>> This seems like a showstopper to me. Even if we can get past the >>>>>>problems >>>>>> associated with a trusted proxy in general, I can't see getting >>>>>>acceptance >>>>>> of any approach that involves sending a session key from one >>>>>>machine to >>>>>> another. But why not just use two full SSL sessions like the >>>>>>typical MITM >>>>>> proxy >>>>>>(http://crypto.stanford.edu/ssl-mitm/orhttp://mitmproxy.org/) >>>>>> approach? But instead of forging certificates like they do, just >>>>>>give the >>>>>> trusted proxy its own certificate and then display both the >>>>>>trusted proxy >>>>>> certificate and the content server certificate in the browser >>>>>>when the user >>>>>> wants info about the two point-to-point SSL sessions. >>>>>> >>>>>> >>>>> Using two connections may require two separate connections at the >>>>>eventual >>>>> endpoint, and it contributes to bufferbloat. >>>>> Also, the proxy may wish to influence the private channel (e.g. >>>>>don't talk >>>>> to site X). With connection sharing, this is difficult/impossible >>>>>otherwise >>>>> (that other connection may not only go to example.com). >>>>> >>>>> >>>>>> "For the purpose of this document, it is assumed that the user >>>>>>locates >>>>>> >>>>>> a piece of paper upon a wall and reads it, typing these proxy >>>>>> settings into a configuration field for their user-agent. This >>>>>>is >>>>>> obviously not the only possible configuration mechanism, but >>>>>>it may, >>>>>> sadly, be the most secure. It is assumed that alternate >>>>>>distribution >>>>>> techniques may be discussed. >>>>>> >>>>>> " >>>>>> >>>>>> While explicit proxy configuration may be the most secure, it is >>>>>>very >>>>>> difficult to manage for mobile devices especially, as others have >>>>>>mentioned >>>>>> on this list. Transparent interception is the more widely adopted >>>>>>approach >>>>>> -- not because of security but because of stability and >>>>>>manageability. >>>>>> >>>>>> >>>>> There is no secure automatic proxy configuration unless a >>>>>completely >>>>> separate trust chain is somehow created and is reliable (or at >>>>>least moreso >>>>> than what we have with TLS today). >>>>> Transparent proxying causes problems in upgrading the protocol as >>>>>nobody >>>>> knows where the problem lies. If this wasn't such a painful point, >>>>>we'd >>>>> have been using SPDY over port 80... >>>>> I'm fundamentally opposed to transparent proxying because it makes >>>>> protocol evolution next to impossible when you can't figure out >>>>>who is >>>>> messing up... >>>>> >>>>> >>>>> >>>>>> What about "transparent" proxies that advertise themselves? Is >>>>>>it >>>>>> possible to use NPN ( >>>>>> https://technotes.googlecode.com/git/nextprotoneg.html) to >>>>>>advertise the >>>>>> presence of an intercepting proxy for 443 traffic? Then the user >>>>>>can be >>>>>> notified that a proxy wants to be trusted for X reasons and the >>>>>>user would >>>>>> then make the opt in or opt out decision. Then, similar to SPDY, >>>>>>the >>>>>> presence of the trusted proxy in the end-to-end path could be >>>>>>signaled to >>>>>> the end user via icons in the browser. >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> MITM is used today with no user knowledge. At least in this >>>>>>approach, a >>>>>> user has the ability to opt in or out and to also be aware of the >>>>>>presence >>>>>> of the intermediate proxy. >>>>>> >>>>> >>>>> That is the idea. >>>>> Additionally, and this is important, the server gets to decide if >>>>>the MITM >>>>> is acceptable, and, in the proposed scheme the MITM doesn't get to >>>>>modify >>>>> bytes. It merely gets to advise the recipient of how to deal with >>>>>them, >>>>> delay them, or disconnect. >>>>> >>>>> -=R >>>>> >>>>> >>>>> On Thu, Apr 25, 2013 at 1:38 PM, Peter Lepeska >>>>><bizzbyster@gmail.com>wrote: >>>>> >>>>>> Some comments on Roberto's doc: >>>>>> >>>>>> In the case where the user-agent has been configured with Chris >>>>>>as a >>>>>> trusted-proxy, either Anne's connect-stream MUST use either a >>>>>>null- >>>>>> cipher, or Anne MUST provide the decryption key material to >>>>>>Chris >>>>>> immediately after tunnel establishment, and before any data >>>>>>traverses >>>>>> the tunnel. >>>>>> >>>>>> >>>>>> This seems like a showstopper to me. Even if we can get past the >>>>>>problems >>>>>> associated with a trusted proxy in general, I can't see getting >>>>>>acceptance >>>>>> of any approach that involves sending a session key from one >>>>>>machine to >>>>>> another. But why not just use two full SSL sessions like the >>>>>>typical MITM >>>>>> proxy (http://crypto.stanford.edu/ssl-mitm/ or >>>>>>http://mitmproxy.org) >>>>>> approach? But instead of forging certificates like they do, just >>>>>>give the >>>>>> trusted proxy its own certificate and then display both the >>>>>>trusted proxy >>>>>> certificate and the content server certificate in the browser >>>>>>when the user >>>>>> wants info about the two point-to-point SSL sessions. >>>>>> >>>>>> "For the purpose of this document, it is assumed that the user >>>>>>locates >>>>>> >>>>>> a piece of paper upon a wall and reads it, typing these proxy >>>>>> settings into a configuration field for their user-agent. This >>>>>>is >>>>>> obviously not the only possible configuration mechanism, but >>>>>>it may, >>>>>> sadly, be the most secure. It is assumed that alternate >>>>>>distribution >>>>>> techniques may be discussed. >>>>>> >>>>>> " >>>>>> >>>>>> While explicit proxy configuration may be the most secure, it is >>>>>>very >>>>>> difficult to manage for mobile devices especially, as others have >>>>>>mentioned >>>>>> on this list. Transparent interception is the more widely adopted >>>>>>approach >>>>>> -- not because of security but because of stability and >>>>>>manageability. >>>>>> >>>>>> What about "transparent" proxies that advertise themselves? Is it >>>>>> possible to use NPN ( >>>>>> https://technotes.googlecode.com/git/nextprotoneg.html) to >>>>>>advertise the >>>>>> presence of an intercepting proxy for 443 traffic? Then the user >>>>>>can be >>>>>> notified that a proxy wants to be trusted for X reasons and the >>>>>>user would >>>>>> then make the opt in or opt out decision. Then, similar to SPDY, >>>>>>the >>>>>> presence of the trusted proxy in the end-to-end path could be >>>>>>signaled to >>>>>> the end user via icons in the browser. >>>>>> >>>>>> MITM is used today with no user knowledge. At least in this >>>>>>approach, a >>>>>> user has the ability to opt in or out and to also be aware of the >>>>>>presence >>>>>> of the intermediate proxy. >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> Peter >>>>>> >>>>>> >>>>>> On Apr 24, 2013, at 12:49 PM, William Chan (陈智昌) >>>>>><willchan@chromium.org> >>>>>> wrote: >>>>>> >>>>>> Yep, but no, it hasn't gone anywhere. >>>>>> >>>>>> >>>>>> On Wed, Apr 24, 2013 at 7:44 AM, Peter Lepeska >>>>>><bizzbyster@gmail.com>wrote: >>>>>> >>>>>>> Hi William, >>>>>>> >>>>>>> Is this draft by Roberto Peon the one you were referring to? >>>>>>> >>>>>>> http://tools.ietf.org/html/draft-rpeon-httpbis-exproxy-00 >>>>>>> >>>>>>> Has this gone anywhere? >>>>>>> >>>>>>> I'm looking to design and build a "trusted proxy" that aligns >>>>>>>with the >>>>>>> browser development roadmap/vision in order to provide web >>>>>>>acceleration >>>>>>> functionality and so would like to get involved in this process >>>>>>>if still >>>>>>> active. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Peter >>>>>>> >>>>>>> >>>>>>> On Mon, Apr 30, 2012 at 5:57 PM, William Chan (陈智昌) < >>>>>>> willchan@chromium.org> wrote: >>>>>>> >>>>>>>> On the contrary, I think it's great to have multiple proposals. >>>>>>>>If you >>>>>>>> have your own vision for how this should work, please send it >>>>>>>>out! :) My >>>>>>>> statement was simply an FYI, not a "back off, we've got this!" >>>>>>>> >>>>>>>> On Mon, Apr 30, 2012 at 2:45 PM, Peter Lepeska >>>>>>>><bizzbyster@gmail.com>wrote: >>>>>>>> >>>>>>>>> Perfect then I'll sit tight. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Peter >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Apr 30, 2012 at 5:43 PM, William Chan (陈智昌) < >>>>>>>>> willchan@chromium.org> wrote: >>>>>>>>> >>>>>>>>>> FYI, we (google spdy team) have been discussing a "trusted >>>>>>>>>>proxy" >>>>>>>>>> internally and I think Roberto's got a draft in the works. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, Apr 30, 2012 at 2:22 PM, Peter Lepeska >>>>>>>>>><bizzbyster@gmail.com>wrote: >>>>>>>>>> >>>>>>>>>>> Hi Mark, >>>>>>>>>>> >>>>>>>>>>> Earlier this group discussed the idea of a "trusted proxy". >>>>>>>>>>>Does >>>>>>>>>>> that fall under the HTTP/2.0 category? >>>>>>>>>>> >>>>>>>>>>> I may have some cycles for this. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Peter >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Fri, Apr 27, 2012 at 1:28 AM, Mark Nottingham >>>>>>>>>>><mnot@mnot.net>wrote: >>>>>>>>>>> >>>>>>>>>>>> Just a reminder that we're still accepting proposals for: >>>>>>>>>>>> >>>>>>>>>>>> 1. HTTP/2.0 >>>>>>>>>>>> 2. New HTTP authentication schemes >>>>>>>>>>>> >>>>>>>>>>>> As per our charter >>>>>>>>>>>><http://datatracker.ietf.org/wg/httpbis/charter/ >>>>>>>>>>>>> . >>>>>>>>>>>> >>>>>>>>>>>> So far, we've received the following proposals applicable >>>>>>>>>>>>to >>>>>>>>>>>> HTTP/2.0: >>>>>>>>>>>> >>>>>>>>>>>><http://trac.tools.ietf.org/wg/httpbis/trac/wiki/Http2Proposals> >>>>>>>>>>>> >>>>>>>>>>>> But none yet for authentication schemes: >>>>>>>>>>>> >>>>>>>>>>>><http://trac.tools.ietf.org/wg/httpbis/trac/wiki/HttpAuthProposals >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> As communicated in Paris, the deadline for proposals is 15 >>>>>>>>>>>>June, >>>>>>>>>>>> 2012. It's fine if your proposal isn't complete, but we do >>>>>>>>>>>>need to have a >>>>>>>>>>>> good sense of it by then, for discussion. >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Mark Nottingham http://www.mnot.net/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >> >
- Reminder: Call for Proposals - HTTP/2.0 and HTTP … Mark Nottingham
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… James M Snell
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… Mark Nottingham
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… James M Snell
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… Willy Tarreau
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… Mark Nottingham
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… Nicolas Mailhot
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… Nicolas Mailhot
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… Willy Tarreau
- RE: Reminder: Call for Proposals - HTTP Authentic… lionel.morand
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… Nicolas Mailhot
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… James M Snell
- RE: Reminder: Call for Proposals - HTTP Authentic… lionel.morand
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… Peter Lepeska
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… William Chan (陈智昌)
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… Peter Lepeska
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… William Chan (陈智昌)
- Re: Reminder: Call for Proposals - HTTP Authentic… Mark Nottingham
- RE: Reminder: Call for Proposals - HTTP Authentic… lionel.morand
- Re: Reminder: Call for Proposals - HTTP Authentic… Mark Nottingham
- RE: Reminder: Call for Proposals - HTTP Authentic… lionel.morand
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… Nicolas Mailhot
- RE: Reminder: Call for Proposals - HTTP Authentic… Markus.Isomaki
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… Peter Lepeska
- Re: Reminder: Call for Proposals - HTTP/2.0 and H… William Chan (陈智昌)
- Comments on Explicit/Trusted Proxy Peter Lepeska
- Re: Comments on Explicit/Trusted Proxy Stephen Farrell
- Re: Comments on Explicit/Trusted Proxy Peter Lepeska
- Re: Comments on Explicit/Trusted Proxy Yoav Nir
- Re: Comments on Explicit/Trusted Proxy Roberto Peon
- Re: Comments on Explicit/Trusted Proxy Peter Lepeska
- Re: Comments on Explicit/Trusted Proxy Stephen Farrell
- Re: Comments on Explicit/Trusted Proxy Fabian Keil
- Re: Comments on Explicit/Trusted Proxy Peter Lepeska
- Re: Comments on Explicit/Trusted Proxy Stephen Farrell
- Re: Comments on Explicit/Trusted Proxy Peter Lepeska
- Re: Comments on Explicit/Trusted Proxy Stephen Farrell
- Re: Comments on Explicit/Trusted Proxy Albert Lunde
- Re: Comments on Explicit/Trusted Proxy Stephen Farrell
- Re: Comments on Explicit/Trusted Proxy Peter Lepeska
- Re: Comments on Explicit/Trusted Proxy Peter Lepeska
- Re: Comments on Explicit/Trusted Proxy Roberto Peon
- Re: Comments on Explicit/Trusted Proxy Benjamin Carlyle
- Re: Comments on Explicit/Trusted Proxy Adrien W. de Croy
- Re: Comments on Explicit/Trusted Proxy Stephen Farrell
- Re: Comments on Explicit/Trusted Proxy Adrien W. de Croy
- Re: Comments on Explicit/Trusted Proxy Roberto Peon
- Re: Comments on Explicit/Trusted Proxy Roberto Peon
- Re: Comments on Explicit/Trusted Proxy Roberto Peon
- Re: Comments on Explicit/Trusted Proxy Adrien W. de Croy
- Re: Comments on Explicit/Trusted Proxy Roberto Peon
- Re: Comments on Explicit/Trusted Proxy Adrien W. de Croy
- Re: Comments on Explicit/Trusted Proxy Stephen Farrell
- Re: Comments on Explicit/Trusted Proxy Roberto Peon
- Re: Comments on Explicit/Trusted Proxy Stephen Farrell
- Re: Comments on Explicit/Trusted Proxy Roberto Peon
- Re: Comments on Explicit/Trusted Proxy Werner Baumann
- Re: Comments on Explicit/Trusted Proxy Stephen Farrell
- Re: Comments on Explicit/Trusted Proxy Yoav Nir
- Re: Comments on Explicit/Trusted Proxy Adrien W. de Croy
- Re: Comments on Explicit/Trusted Proxy Yoav Nir
- Re: Comments on Explicit/Trusted Proxy Adrien W. de Croy