Re: Comments on Explicit/Trusted Proxy

[Roberto Peon <[e-mail]>]

Ugh. The last part of the email means that you are being deliberately
insulting. This is, in the long-run, rarely effective.

responses inline.

On Sat, May 4, 2013 at 3:29 AM, Stephen Farrell
<[e-mail]>wrote:

>
> On 05/03/2013 11:52 PM, Adrien W. de Croy wrote:
> >
> > sorry I should have been more clear, my questions weren't in the context
> > of your proposal, but in the context of what the current situation is,
> > and mostly in response to Stephen's comments.
> >
> > Concerns were raised about creating a requirement for servers to
> > authenticate proxies.
>
> Not quite. If one did accept the mainly-bogus arguments for
> MITMing TLS (and I clearly don't:-), and you want any level
> of security at all, you need a secure N-party protocol instead
> of TLS or to change HTTP significantly and use multiple but
> linked TLS sessions. I don't know of any real solution for
> these mainly-bogus requirements that does not involve web
> servers being able to authenticate every possible proxy in
> either case. Being able to do that is just not practical IMO.
>

You can state this without being pejorative, in which case I might agree.

There are two suppositions in the draft:
1) MITM may be unavoidable in the long-term, in which case the lesser of
evils is to have a MITM which is detectable and which is prevented from
modifying or falsifying information.

2) It may be interesting to have a connection to a proxy which is
point-to-point private, and which allows the proxy to perform caching
duties as it might with HTTP, but with guarantees that the content it
serves is unmodified.

I'm assuming you conflate the motivation for #1 with the rest of everything
and have an adverse ideological reaction.
I don't particularly like it either, but that (that
coporations/organizations/gov't entities, etc. will be forcing
unconstrained MITM by various means) was the supposition. If it is in
general false, *good*. If it is true, then choose some lesser of evils, and
discuss it. A discussion about whether such a mechanism would hasten the
creation of such a world is also interesting and valid. Being a pragmatist,
I see that ideology is useful until it isn't. I also know that there are
companies and organizations which *DO* do SSL MITM by installing and
configuring root certs, etc. and there is currently no protection guarantee
to users traversing such.



> The problem with claims that you don't need the ability
> for any web server to authenticate any proxy is that that
> would allow any middle-box to join any TLS session which
> would mean that TLS confidentiality would be a thing of the
> past. That'd be a hugely bad outcome.
>

You are either misinterpreting or falsifying here.

The mechanism specified in the draft requires at least three TLS sessions
which interplay, and possibly 4.

1) client<-> proxy   for point-to-point privacy
2) proxy <-> server for point-to-point privacy
3) client (tunneled through the proxy) <-> server for end-to-end privacy
and authentication
4) client (tunneled through the proxy, null-cipher or similar used,
integrity key NOT exposed) <-> server for end-to-end integrity while
allowing the proxy to examine/delay/drop and provide policy to the client
or server outside of the tunnel

In other words, the only way to don't also have a full TLS session (which
simply happens to be tunneled) with full authentication and encryption is
when you explicitly give this up by configuring it manually (like what one
does today).

In other words it is always the client's choice to do #4, and doing so does
require an explicit configuration by said client.
It is also stated that this trust relationship is likely problematic in the
public case, which is why I didn't provide for any mechanism for
automatically configuring such, and I called out that that part is
potentially problematic and needs further consideration.


None of the trust things are problematic in the caching case-- automatic
configuration would be fine there, but I didn't go into it because I didn't
want that part conflated with the much more worrisome aspects. It is fine
because if something is cached (at an intermediary) it is public
information, and all we care about in that case is that the integrity of
the item is intact.
The draft's scheme for caching does provide a potential privacy benefit
there as well, however-- since one may now speak with a caching proxy over
a channel which is point-to-point private, it is more difficult to see what
(public) resources the client is requesting.


> Requiring that web-sites can and will go through all the
> URLs they serve and decide which are ok to MITM and which
> are not also seems bogus to me. That'd either result in
> failure to establish many many TLS sessions because we'd
> have invented a bogus-standard that more or less forced
> proxies and web servers to choose non-interoperable options
> or else would mean that many many TLS sessions were MITMable
> through web-server admin inaction. Again both are hugely
> bad outcomes.
>
>
Do you write or maintain servers that serve commercial traffic?
It doesn't sound that way.

In any case, as a larger problem, you're arguing from both ends and somehow
not meeting in the middle.

You're seem to be asserting that MITM proxies are bad and won't happen
(i.e. you dispute the premise behind #1), but then you're also asserting
that when they do happen, that servers should completely ignore it and
happily serve content through servers which are unauthenticated to the
user, unknown to the user, and unknown to the server.

So, which is it?
Do you believe that MITM is not happening and never will?
Or do you believe that MITM will happen, and if so that clients and servers
should be blind to it, and should accept mutated data without comment or
reaction?



> Oh, and I've left out the fact that there are many non-web
> uses for TLS any of which could be screwed if we standardised
> a way to MITM TLS designed to satisfy mainly-bogus HTTP proxy
> driven requirements. I don't see any of the proponents of these
> mainly-bogus requirements doing the security analysis of the
> impact their mainly-bogus solutions would have on those other
> protocols. Hey - there's likely another hugely bad outcome
> or 10.
>

The draft was submitted to the HTTP working group to help with HTTP's
particular requirement set, and as a response to the fact that, while
encrypting point-to-point communications allows for protocol evolution, it
makes caching difficult, and also as a real-world result of dealing with
schools and other entities which have legal or perceived moral reasons for
enforcing policies on communications.

In other words, problems faced because I do have to serve clients.

The scheme specified in the draft requires no change to TLS's mechanisms,
though the considered and informed input of security experts on the content
of the draft is hopefully useful.


> The answer about what to do here is obvious to anyone who
> cares about security and BCP61 says the IETF does. What to
> do here is: don't break TLS.
>
> > My questions were about how does a server know it's a proxy, so how can
> > a client be trusted more, and therefore how is a proxy less trustworthy.
>
> From any rational web server perspective, no forward proxy is
> "trustworthy" (terrible term to use btw, it means nothing as
> used above).
>

That is precisely the point!

Some resources are too sensitive to allow through any non client-controlled
proxy. Only the server has any reasonable potential of knowing which these
are, and it *should not* trust the proxy in such cases.


>
> If a web server cares, it can add an account for the user
> (not UA) and the UA is (sort of) under the control of that
> user according to our host-based security models. Proxies
> are just unknowns.
>


How would this work w.r.t proxies?

 -=R

>
> Stephen.
>
> PS: Yes, the above uses pejorative language. Apologies for
> that, but yes, it is deliberate;-)
>
>
> > HTTP auth only covers one small part of the picture, and doesn't lock a
> > proxy out of the conversation, only out of the authentication.  The
> > proxy can still modify anything else about the requests.
> >
> > Regards
> >
> > Adrien
> >
> >
> > ------ Original Message ------
> > From: "Roberto Peon" <[e-mail]>
> > To: "Adrien W. de Croy" <[e-mail]>
> > Cc: "Stephen Farrell" <[e-mail]>; "HTTP Working Group"
> > <[e-mail]>
> > Sent: 4/05/2013 9:07:44 a.m.
> > Subject: Re: Comments on Explicit/Trusted Proxy
> >> The client has no need to do TLS in TLS and wouldn't do it by default.
> >> The proxy has no choice but to do TLS in TLS (since that is what the
> >> client sends it), and, since it doesn't have the integrity keys, it
> >> can't change the data, etc. without detection by the client or server.
> >>
> >> So, if the server receives a stream which indicates that it is doing
> >> TLS, it knows this should be treated as having come through a proxy.
> >>
> >> -=R
> >>
> >>
> >> On Fri, May 3, 2013 at 1:27 PM, Adrien W. de Croy <[e-mail]>
> >> wrote:
> >>>
> >>> my next question, is how can the server tell the difference between a
> >>> proxy and a client?
> >>>
> >>>
> >>> ------ Original Message ------
> >>> From: "Roberto Peon" <[e-mail]>
> >>> To: "Adrien W. de Croy" <[e-mail]>
> >>> Cc: "Stephen Farrell" <[e-mail]>; "HTTP Working
> >>> Group" <[e-mail]>
> >>> 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 <[e-mail]>
> >>>> 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" <[e-mail]>
> >>>>> To: "HTTP Working Group" <[e-mail]>
> >>>>> 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
> >>>>>>> <[e-mail]> 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" <[e-mail]>
> >>>>>>>>  To: "Peter Lepeska" <[e-mail]>
> >>>>>>>>  Cc: "HTTP Working Group" <[e-mail]>
> >>>>>>>>  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
> >>>>>>>> <[e-mail]>
> >>>>>>>>   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
> >>>>>>>> <[e-mail]>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 (陈智昌)
> >>>>>>>>> <[e-mail]>
> >>>>>>>>>  wrote:
> >>>>>>>>>
> >>>>>>>>>   Yep, but no, it hasn't gone anywhere.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>  On Wed, Apr 24, 2013 at 7:44 AM, Peter Lepeska
> >>>>>>>>> <[e-mail]>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 (陈智昌) <
> >>>>>>>>>>  [e-mail]> 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
> >>>>>>>>>>> <[e-mail]>wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>>  Perfect then I'll sit tight.
> >>>>>>>>>>>>
> >>>>>>>>>>>>  Thanks,
> >>>>>>>>>>>>
> >>>>>>>>>>>>  Peter
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>  On Mon, Apr 30, 2012 at 5:43 PM, William Chan (陈智昌) <
> >>>>>>>>>>>>  [e-mail]> 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
> >>>>>>>>>>>>> <[e-mail]>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
> >>>>>>>>>>>>>> <[e-mail]>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/
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>
>