Re: Comments on Explicit/Trusted Proxy

Agreed, agreed, ditto :)
-=R
On May 4, 2013 11:35 AM, "Stephen Farrell" <stephen.farrell@cs.tcd.ie>
wrote:

>
>
> On 05/04/2013 04:30 PM, Roberto Peon wrote:
> > Ugh. The last part of the email means that you are being deliberately
> > insulting. This is, in the long-run, rarely effective.
>
> No, I'm not insulting anyone nor trying to. I am describing
> the purported requirements here as mainly-bogus which is
> pejorative but entirely different and is IMO justified. I
> think emphasis on the bogosity of the purported requirements
> is deserved.
>
> I won't respond blow by blow because I think we're talking
> at cross purposes as I wasn't commenting specifically about
> your draft but about the entire set of proposals for MITMing
> TLS. But to address your points:
>
> - My approach is not ideological at all, but based solely
> on good engineering and security practices.
>
> - Possible government mandated MITM attacks on IETF protocols
> were a major factor in why we ended up with RFC2804. I suggest
> that's required reading for people proposing work on this
> topic.
>
> - We are not talking about privacy at all here but about
> confidentiality. Confusing those, in this context, is a
> bad idea.
>
> - Yes, I do believe that MITM is happening in enterprises,
> that we should not standardise it because of the bad
> outcomes I mentioned in my mail and that we should try
> use whatever mechanisms we can to make it detectable
> (e.g. pinning or certificate transparency). The reason
> for all that is not ideological but because it is an
> attack on the protocol.
>
> I also think we can leave the discussion at this point,
> given that there is no WG chartered for this. At least
> I'm happy to leave it there.
>
> S.
>
>
> > responses inline.
> >
> > On Sat, May 4, 2013 at 3:29 AM, Stephen Farrell
> > <stephen.farrell@cs.tcd.ie>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" <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 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 <adrien@qbik.com>
> >>>> wrote:
> >>>>>
> >>>>> 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/
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> >
>