Subject: new version trusted-proxy20 draft

From: Salvatore Loreto <[email-masked]>
Date: Fri, 14 Feb 2014 18:56:14 +0000

dear wg

we have submitted a new version of the "Explicit Trusted Proxy in HTTP/2.0" draft

I want to highlight that
the only change asked by this draft in order to support an Explicit Trusted Proxy
is the definition of a new ALPN protocol id value as you can read in the Abstract below.
No other changes to HTTP2 spec neither to the TLS protocol are required.

Abstract:
  The purpose of this Internet Draft is to continue the discussion on
  explicit and trusted proxy as intermediary of HTTP2 traffic.

  The httpbis wg has agreed on the HTTP2 usage with HTTP URIs, with or
  without TLS, without any constraints from the standard (see: issue
  314).

  To distinguish between an HTTP2 connection meant to transport "https"
  URIs resources and an HTTP2 connection meant to transport "http" URIs
  resource, the draft proposes to

     register a new value in the Application Layer Protocol negotiation
     (ALPN) Protocol IDs registry specific to signal the usage of HTTP2
     to transport "http" URIs resources: h2clr.

  This document describes two alternative methods for an user-agent to
  automatically discover and for an user to provide consent for a
  Trusted Proxy to be securely involved when he or she is requesting an
  HTTP URI resource over HTTP2 with TLS.

   Section 3.1 proposes a solution based on sending a proxy certificate
   in the TLS handshake.

   Section 3.2 proposes a solution based on the presence of a Captive
   Proxy.

  The consent is supposed to be per network access.

  The draft also describes the role of the Trusted
  Proxy in helping the user to fetch HTTP URIs resource when the user
  has provided consent to the Trusted Proxy to be involved.

URL:            http://www.ietf.org/internet-drafts/draft-loreto-httpbis-trusted-proxy20-01.txt
Status:         https://datatracker.ietf.org/doc/draft-loreto-httpbis-trusted-proxy20/
Htmlized:       http://tools.ietf.org/html/draft-loreto-httpbis-trusted-proxy20-01
Diff:           http://www.ietf.org/rfcdiff?url2=draft-loreto-httpbis-trusted-proxy20-01

Comments, suggestion and feedback are really welcome

best regards
Salatore

---

From: Patrick McManus <[email-masked]>
Date: Fri, 14 Feb 2014 17:42:39 -0500

>   resource, the draft proposes to
HTTP/2 doesn't require a connection to transport a consistent scheme as
long as the underlying properties of the connection are sufficient for
carrying all of the schemes on it. (i.e. you can't carry https:// without a
minimum security set, but you can certainly mix https:// and http://)

>      to transport "http" URIs resources: h2clr.

(1)  A User-Agent that makes a request to an "http" URI without prior
      knowledge about support for HTTP2 uses TLS, with the application
      level protocol negotiation extension inserting the h2clr tag, to
      start the HTTP2 connection.  The Proxy intercepts the TLS
      ClientHello analyses the application layer protocol negotiation
      extension field and if it contains "h2clr" value it blocks the TLS
      ClientHello.

>   HTTP URI resource over HTTP2 with TLS.

This has the effect of signaling to an on path observer which transactions,
in a large stream of them, will not be able to detect a MITM interaction.
I'm not in favor.

---

From: Thomas Fossati <[email-masked]>
Date: Sun, 16 Feb 2014 21:24:44 +0000

Hi Sal, thanks for the draft.

On 14/02/2014 18:56, "Salvatore Loreto" <[email-masked]<mailto:[email-masked]>> wrote:
I want to highlight that
the only change asked by this draft in order to support an Explicit Trusted Proxy
is the definition of a new ALPN protocol id value as you can read in the Abstract below.
No other changes to HTTP2 spec neither to the TLS protocol are required.

I think one very important change that you propose (for good reasons, IMHO) is to explicitly separate TLS tunnels that are intended for http URIs from those that are to carry https traffic.

Maybe this bit of information deserves to be stated more clearly in the document?

This is the only part of your draft where I have a bit of difficulties in understanding the mechanics.

In step (2), in order to distinguish between a genuine HTTP/1.1 request (one that needs no redirection to the Portal) from a "downgraded” HTTP/2.0 request (i.e. one which is the result of a previously tried&failed “h2clr” handshake and has to go to the Portal), the trusted proxy needs to keep some kind of state about the re-trying user agent.

However, at the point the redirection decision is made, the trusted proxy has no other information than IP address of the user agent.

What’s the heuristics that you envisage to make this work in practice?

Cheers

---

From: Thomas Fossati <[email-masked]>
Date: Sun, 16 Feb 2014 21:50:28 +0000

On 14/02/2014 22:42, "Patrick McManus" <[email-masked]<mailto:[email-masked]>> wrote:
On Fri, Feb 14, 2014 at 1:56 PM, Salvatore Loreto <[email-masked]<mailto:[email-masked]>> wrote:

HTTP/2 doesn't require a connection to transport a consistent scheme as long as the underlying properties of the connection are sufficient for carrying all of the schemes on it. (i.e. you can't carry https:// without a minimum security set, but you can certainly mix https:// and http://)

Exactly: the explicit separation of the TLS connections that are intended for https vs http URIs is the core of Sal’s proposal.  And a significant delta from the current HTTP/2 spec.

This has the effect of signaling to an on path observer which transactions, in a large stream of them, will not be able to detect a MITM interaction.

A couple of questions to try and understand your concern:
1) Provided that a “h2clr” TLS tunnel, when established, is not retrospectively MITM-able, what advantage an on-path adversary would get from just observing it?
2) While TLS handshaking, what makes “h2clr” more prone to stealthy MITM’s than “h2”?

Cheers

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 16 Feb 2014 18:58:57 -0800

Thanks for the new draft. I hope the comments below help make it a stronger
proposal.

- I suspect that the Captive Proxy example in 3.2 is missing something. It
indicates that the proxy, before it sends back the ServerHello for TLS,
redirects the User-Agent to stop doing TLS and do some rounds of HTTP. And
somehow the GET has HTTPS in it. This seems all wrong. Please consider
removing the whole idea of "I'm a proxy you don't know, but a web page will
convince you to trust me".

- The requirement for EV certs is silly for proxies. The proxy will often
have a domain name or IP address that the CA cannot reach, and therefore it
cannot do EV validation. This is security theater that is not helpful.

--Paul Hoffman

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 17 Feb 2014 06:42:28 +0000

Hi Thomas,

thanks for your comments,

On Feb 16, 2014, at 11:24 PM, Thomas Fossati <[email-masked]<mailto:[email-masked]>>
 wrote:

yes the separation between TLS tunnels intended for http URI and TLS tunnels intended to transport https
is the main change, really important change, even if the only one the draft is proposing for the HTTP2 protocol.

I think you are right, I will do my best to make it stated more clearly in the next version.

this is a good question.
you are right that at the time of receiving the TLS Client Hello the trusted proxy has to keep some kind of state/information about
the re-trying user agent.

In the wireless telephone world the proxy is facilitated because it receives not only the IP address of the user agent but also
the MSISDN.

However also in general that should be so difficult as the solution we are proposing is for access network
so the UA IP address should be enough for a trusted proxy in the same network to discriminate the UA.

Cheers
/Sal

Cheers

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 17 Feb 2014 06:55:46 +0000

On Feb 15, 2014, at 12:42 AM, Patrick McManus <[email-masked]<mailto:[email-masked]>> wrote:

This has the effect of signaling to an on path observer which transactions, in a large stream of them, will not be able to detect a MITM interaction. I'm not in favour.

a trusted proxy signals it presence during the first UA attempt to establish an "h2clr" tunnel:
it honestly declares its presence
So it does not do or attempt to do any MITM behaviour.
Of course here it is a matter of trust, that way a UA has the possibility to *opt out* if does not trust
the access network

/Sal

---

From: Patrick McManus <[email-masked]>
Date: Mon, 17 Feb 2014 09:00:44 -0500

On Mon, Feb 17, 2014 at 1:55 AM, Salvatore Loreto <
[email-masked]> wrote:

>
>  On Feb 15, 2014, at 12:42 AM, Patrick McManus <[email-masked]>
> wrote:
>
>
> carrying all of the schemes on it. (i.e. you can't carry https:// without
> a minimum security set, but you can
>
>  This has the effect of signaling to an on path observer which
> transactions, in a large stream of them, will not be able to detect a MITM
> interaction. I'm not in favour.
>
>

you're focused on the device you envision deploying. what about a
traditional MITM attacker  (i.e something not adhering to your draft)?

secondly, any interception proxy - especially those terminating flows not
addressed to them - is a MITM - almost tautologically so. Perhaps not an
attacker - maybe a frenemy - but definitely a MITM.

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Mon, 17 Feb 2014 16:11:54 +0100

> we have submitted a new version of the "Explicit Trusted Proxy in

Thank you for the new draft!

One small remark:

EV won't fly on private networks, the network owner won't pay an external
semi-trusted CA for its internal users, it will deploy self-signed or
signed-by-internal PKI certificates (and that's better that way it limits
the number of signed-by-external-CA certs that can leak outside the org)

Anyway I feel there are too many different modes in the draft, could not
it be simplified with:

  A. web client sends direct request with h2 or h2clr ALPN protocolname
     → if it succeeds nothing more to do
     → web clients that do not want to help transparent caches MAY use h2
by default

  B. otherwise it receives a firewall hello with a proxy network location
    → it is not necessary at this stage to establish trust, trust is only
needed when you start talking to the proxy,
    → trust is not needed with the firewall since it has already proved
ability to block direct communication and that's all that matter from
the client POW
    → firewall http smarts need to be kept at minimum to avoid costly
interactions with the proxy

  C. Web client sends a new hello to the proxy network location, and
checks the certificate in the answer
    → if cert untrusted return to A but the web client may have to give up
on the network if the firewall insists

  D. Otherwise, establish TLS connexion with the proxy
    → after this point the web client MAY choose to use the proxy for
other connexions if it does not want to try direct before

  E. web client sends new request through the proxy TLS connexion (either
h2clr or CONNECT-like tunnel-in-a-tunnel for h2)

  F. If the requests succeeds we're finished

The following optional errors can be sent at any time by the proxy once
the TLS connexion is established
  1. ??A: rebalance: pac-like proxy info files with the list of preferred
proxies to use at this moment and sites that can be reached directly
  2. 511: portal → go authenticate or click through this location before
continuing
     a. do web clients need a separate re-auth code or will they be smart
enough to replay auth if they receive a new 511 to the same location
after a while? Question for web client people
     b. I assume the location needs to be https using the same kind of
cert as the proxy node
  3. ??B: downgrade → operator only allows h2clr to this site, downgrade
h2 to h2clr or go away (direct has already failed at this stage)
  4. 666: forbidden → proxy operator really does not want you to go there,
life sucks
  5. ??C: dns error → proxy can't find your site
  6. ??D: timeout   → web site does not answer

I assume that to avoid HOL problems the web client may have several
requests in fly so proxy errors must contain an identifier of the request
that triggered them.

Web clients can try another network or refuse the connexion at any time if
they don't like what the proxy told them.

Is this not sufficient to cover all cases? It lets proxy-adverse clients
try to avoid them as much as possible before falling back on proxies, and
describes a single generic mode instead of multiplying them. You need to
specify 4 proxy-specific error codes and nothing more (proxy can get by
without those codes but it results in silent hangs so it's better to be
explicit)

Regards,

-- 
Nicolas Mailhot

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 18 Feb 2014 09:49:39 +0000

On Feb 17, 2014, at 4:58 AM, Paul Hoffman <[email-masked]> wrote:

> Thanks for the new draft. I hope the comments below help make it a stronger proposal.
> 
> - I suspect that the Captive Proxy example in 3.2 is missing something. It indicates that the proxy, before it sends back the ServerHello for TLS, redirects the User-Agent to stop doing TLS and do some rounds of HTTP. And somehow the GET has HTTPS in it. This seems all wrong. Please consider removing the whole idea of "I'm a proxy you don't know, but a web page will convince you to trust me".

good point!

> 
> - The requirement for EV certs is silly for proxies. The proxy will often have a domain name or IP address that the CA cannot reach, and therefore it cannot do EV validation. This is security theater that is not helpful.

not sure I understand all the aspects behind your comment here, so I am trying to analysing from two different angles 

- if the question is how would be possible for the browser/client to run OCSP  to check the validity of certificates from the CA if the OCSP is ran over TLS
I want to clarify that Trusted Proxy is only analyses the ALPN application tag (i.e.: H2clr and H2) in order to ask for consent only for H2clr
all the rest of TLS connections will be pass. So OSCP will work.

- if the question is that not all the companies that usually deploy proxies in their access network have all the 
requisites to have a EV certs then I don't know if it is  worth to relax this requirement in order to broader the mechanism's adoption.
I am open to any change. My only concern is that we need to come up with something that bring enough trust to the end user
to convince her/him to provide consent to the proxy.

br
Salvatore

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 18 Feb 2014 10:16:49 +0000

On Feb 17, 2014, at 4:00 PM, Patrick McManus <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Feb 17, 2014 at 1:55 AM, Salvatore Loreto <[email-masked]<mailto:[email-masked]>> wrote:

HTTP/2 doesn't require a connection to transport a consistent scheme as long as the underlying properties of the connection are sufficient for carrying all of the schemes on it. (i.e. you can't carry https:// without a minimum security set, but you can

you're focused on the device you envision deploying. what about a traditional MITM attacker  (i.e something not adhering to your draft)?

The draft proposal to define "h2clr" for http traffic does not make the environment more prone to stealthy MITMs then just having "h2"

However I agree that we should work on reducing or completely eliminate the possibility of MITM

secondly, any interception proxy - especially those terminating flows not addressed to them - is a MITM - almost tautologically so.

yes but a trusted proxy only terminates flows not addressed to itself for the sake of explicitly advertise its presence and request consent:
only the first time!
If the user provides consent then browser will become proxy aware and configured (i.e. using pac file) and the flows will be addressed to proxy.

If the user decides not to provide consent or to opt out then it will not terminate any flow...

Perhaps not an attacker - maybe a frenemy - but definitely a MITM.

why not just call it a configured Trusted Proxy?

---

From: Fabian Keil <[email-masked]>
Date: Tue, 18 Feb 2014 11:17:50 +0100

> we have submitted a new version of the "Explicit Trusted Proxy in HTTP/2.0" draft
[...]
> Comments, suggestion and feedback are really welcome

From 1. Introduction:
| HTTPS tunnels, while speeding up the deployment, makes it difficult
| for a forward proxy and other intermediaries to be used to allow
| caching, to provide anonymity to a User-Agent, or to provide security
| by using an application-layer firewall to inspect the HTTP traffic on
| behalf of the User-Agent (e.g. to protect it against cross-site
| scripting attacks).

I'd prefer "provide anonymity" and "provide security" to be reworded
to something less optimistic like "enhance privacy" and "enhance security".
Expecting a proxy to provide anonymity and/or security doesn't seem
realistic to me.

Even the mentioned cross-site scripting "protection" is unlikely to
work for all attacks and all clients.

From "3.1. Proxy certificate":
| As the user needs to have high trust in the Proxy, the validation
| procedure for proxy certificates should be more rigorous than for
| ordinary SSL certificates. All proxy certificates should therefore
| be Extended Validation (EV) SSL Certificates.

I don't think the text should promote EV certificates as being
more trustworthy than "ordinary" certificates.

From "3.1.1. TLS Handshake with Proxy certificate":

| When a (TLS and HTTP) User-Agent receives a Server Certificate
| message, it checks whether the certificate contains an Extended Key
| Usage extension and if so whether the "proxyAuthentication" key
| purpose id is included.  If it is included, the User-Agent concludes
| that the certificate belongs to a proxy.  It then verifies that the
| proxy certificate is a valid EV certificate.  The user-agent then
| SHOULD secure user consent.

What is the user-agent supposed to do if it's not a EV certificate
or an invalid EV certificate?

| When the user has given consent to the use of a proxy, the User-Agent
| SHOULD store this consent so that the user does not have to give
| consent for each new TLS connection involving the proxy.  The consent
| SHOULD be limited to the specific access and MAY be limited to a
| single connection to that access or limited in time. 

I'd prefer to be able to limit consent to certain websites.

Section "3.1.2. Opt Out" doesn't mention how the proxy opts
out of serving a user who didn't consent to the interception.

Fabian

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 18 Feb 2014 10:32:28 +0000

Hi Fabian

thanks for the comments
see in line

> work for all attacks and all clients.

fair enough, I will use the suggested terminology in the next version

> or an invalid EV certificate?

it is supposed to opt out…
only use h2 ALPN tag for all the traffic

> I'd prefer to be able to limit consent to certain websites.

yes it sound a reasonable thing to do

> out of serving a user who didn't consent to the interception.

you are right, it is not explicitly there
but it will switch to only use h2 ALPN tag for all the traffic

/Salvatore

---

From: Patrick McManus <[email-masked]>
Date: Tue, 18 Feb 2014 09:29:31 -0500

On Tue, Feb 18, 2014 at 5:16 AM, Salvatore Loreto <
[email-masked]> wrote:

>
>  On Feb 17, 2014, at 4:00 PM, Patrick McManus <[email-masked]>
> wrote:
>
>
> The draft proposal to define "h2clr" for http traffic does not make the
> environment more prone to stealthy MITMs then just having "h2"
>
>
 Assume the traffic has a mix of resources on port 443 using TLS. some will
insist on strong TLS semantics (i.e. https) and some that will not (http).
When blocked by an attacker the strong ones throw a visible error and the
weak ones do something like fall back to cleartext http/1. The attacker
does not want to be detected via visible error.

If all of those transactions are labeled "h2" then an active attacker has
to guess which flows can be attacked without being detected. The risk  of
getting it wrong is a barrier to the attack. All the better if the
transactions are muxxed together into the same TLS connection.

Splitting them into 2 connections with 2 different ALPN tokens is pretty
much labeling one of them "mess with me". Which is also pretty much the
point of your proposal afaict - you're just doing it on behalf of a
firewall instead of someone installing an illicit fiber tap.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 18 Feb 2014 11:37:06 -0800

On Tue, Feb 18, 2014 at 1:49 AM, Salvatore Loreto <
[email-masked]> wrote:

> > - I suspect that the Captive Proxy example in 3.2 is missing something.
> It indicates that the proxy, before it sends back the ServerHello for TLS,

Does this mean that you will remove 3.2? If so, reviewing the proposal will
be much easier.

> >
> > - The requirement for EV certs is silly for proxies. The proxy will
> often have a domain name or IP address that the CA cannot reach, and
> therefore it cannot do EV validation. This is security theater that is not
> helpful.
>
> not sure I understand all the aspects behind your comment here, so I am
> trying to analysing from two different angles
>
> - if the question is how would be possible for the browser/client to run
> OCSP  to check the validity of certificates from the CA if the OCSP is ran
> over TLS
> I want to clarify that Trusted Proxy is only analyses the ALPN application
> tag (i.e.: H2clr and H2) in order to ask for consent only for H2clr
> - if the question is that not all the companies that usually deploy
> proxies in their access network have all the
> requisites to have a EV certs then I don't know if it is  worth to relax
> this requirement in order to broader the mechanism's adoption.
> I am open to any change. My only concern is that we need to come up with
> something that bring enough trust to the end user

What do you mean by "enough trust" and how does someone get there with EV
certs? If you believe that EV certs are actually more trustworthy, that's
fine, but that is not the general perception. Further, the rules for
issuing EV certs will probably preclude many proxies from getting them. So,
you are adding a layer of security theater that actually prevents adoption
of the protocol for many organizations.

--Paul Hoffman

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 18 Feb 2014 20:06:10 +0000

On Feb 18, 2014, at 9:37 PM, Paul Hoffman <[email-masked]<mailto:[email-masked]>>
 wrote:

On Tue, Feb 18, 2014 at 1:49 AM, Salvatore Loreto <[email-masked]<mailto:[email-masked]>> wrote:

good point!

Does this mean that you will remove 3.2? If so, reviewing the proposal will be much easier.

yes I will!

What do you mean by "enough trust" and how does someone get there with EV certs? If you believe that EV certs are actually more trustworthy, that's fine, but that is not the general perception. Further, the rules for issuing EV certs will probably preclude many proxies from getting them. So, you are adding a layer of security theater that actually prevents adoption of the protocol for many organisations.

and I don't want anything that actually prevents a large adoption of the protocol
so I don't have any problem to remove the requirements on EV certs

/Sal

--Paul Hoffman

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 18 Feb 2014 18:02:18 -0800

My first instinct was to agree with Patrick's analysis here. Then I
looked at the draft in more detail. IIUC, the connection we're talking
about is the encrypted user-agent<=>forward proxy connection, where
the forward proxy is authenticated. Even though the connection is
carrying http:// schemed traffic, the connection to the proxy is fully
authenticated and I think user agents should show an error page if
someone MITM'd this connection, even though it only carried http://
schemed traffic. Did I understand things correctly? Are we talking
about just the proxy connection here?

That said, it's not immediately obvious to me why the forward proxy
needs to have things separated out on a separate connection. Is it
that you'd like to provide different QoS for http:// and https://
traffic? If so, I disagree with this on principle. https:// traffic
should not be discriminated against. I agree with Patrick that it's
overall better, were a user agent to support http:// schemed traffic
over HTTP/2/TLS, to serve it on the same connection as https://
traffic. I'd appreciate a section in the document that explained the
reasoning behind separating out the connections. Sorry if I'm being
dense or missed it somewhere, but it isn't obvious to me why this is
necessary or desirable.

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?

On Tue, Feb 18, 2014 at 6:29 AM, Patrick McManus <[email-masked]> wrote:
>
>
>
> On Tue, Feb 18, 2014 at 5:16 AM, Salvatore Loreto
> <[email-masked]> wrote:
>>
>>
>> On Feb 17, 2014, at 4:00 PM, Patrick McManus <[email-masked]> wrote:
>>
>>
> weak ones do something like fall back to cleartext http/1. The attacker does
> not want to be detected via visible error.
>
> If all of those transactions are labeled "h2" then an active attacker has to
> guess which flows can be attacked without being detected. The risk  of
> point of your proposal afaict - you're just doing it on behalf of a firewall
> instead of someone installing an illicit fiber tap.
>

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 18 Feb 2014 20:15:05 -0800

> about just the proxy connection here?

The draft is far from clear here, but I would certainly hope that is the
case: if there is an failure in the TLS handshake between the client and
the proxy, *regardless of what caused the connection to the proxy to start
up*, an error would be shown.

> dense or missed it somewhere, but it isn't obvious to me why this is

+

> does
> firewall

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 18 Feb 2014 20:18:39 -0800

> 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.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 18 Feb 2014 20:54:00 -0800

On Tue, Feb 18, 2014 at 8:18 PM, Paul Hoffman <[email-masked]> wrote:
> On Tue, Feb 18, 2014 at 6:02 PM, William Chan (陈智昌) <[email-masked]>
> wrote:
>>
>>

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.

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 19 Feb 2014 06:08:30 +0000

On Feb 19, 2014, at 6:15 AM, Paul Hoffman <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Feb 18, 2014 at 6:02 PM, William Chan (陈智昌) <[email-masked]<mailto:[email-masked]>> wrote:

The draft is far from clear here, but I would certainly hope that is the case: if there is an failure in the TLS handshake between the client and the proxy, *regardless of what caused the connection to the proxy to start up*, an error would be shown.

I apologise to have not been so clear in the draft (working against the deadline is always a challenge)
 but yes of course there will be an error

br
Salvatore

+

On Tue, Feb 18, 2014 at 6:29 AM, Patrick McManus <[email-masked]<mailto:[email-masked]>> wrote:
> <[email-masked]<mailto:[email-masked]>> wrote:
>>
>>

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 19 Feb 2014 06:57:09 +0000

On 19/02/2014 02:02, "William Chan (陈智昌)" <[email-masked]> wrote:
>all their https traffic.

It’s not the https traffic that would be snooped, but the http traffic
carried over HTTP/2.0 + TLS

>I don't really see the value for end users in
>standardizing any mechanism for doing this.

E.g. getting lower latencies on mobile networks (due to improved caching
at the edge).

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 19 Feb 2014 06:57:49 +0000

On 18/02/2014 14:29, "Patrick McManus" <[email-masked]<mailto:[email-masked]>> wrote:
On Tue, Feb 18, 2014 at 5:16 AM, Salvatore Loreto <[email-masked]<mailto:[email-masked]>> wrote:
On Feb 17, 2014, at 4:00 PM, Patrick McManus <[email-masked]<mailto:[email-masked]>> wrote:
This has the effect of signaling to an on path observer which transactions, in a large stream of them, will not be able to detect a MITM interaction. I'm not in favour.
The draft proposal to define "h2clr" for http traffic does not make the environment more prone to stealthy MITMs then just having "h2"

Assume the traffic has a mix of resources on port 443 using TLS. some will insist on strong TLS semantics (i.e. https) and some that will not (http). When blocked by an attacker the strong ones throw a visible error and the weak ones do something like fall back to cleartext http/1. The attacker does not want to be detected via visible error.

If all of those transactions are labeled "h2" then an active attacker has to guess which flows can be attacked without being detected. The risk  of getting it wrong is a barrier to the attack. All the better if the transactions are muxxed together into the same TLS connection.

Splitting them into 2 connections with 2 different ALPN tokens is pretty much labeling one of them "mess with me". Which is also pretty much the point of your proposal afaict - you're just doing it on behalf of a firewall instead of someone installing an illicit fiber tap.

The threat that you see is an undetectable downgrade (2.0 overTLS => cleartext 1.x), correct?

In fact, that can actually happen when using the “captive proxy” as described in Section 3.2, whereas the mechanism that uses the proxy certificate (3.1) is robust.

I think that the “captive proxy” could be hammered a bit to counter the downgrade attack — e.g. by forcing the TLS handshake to proceed up to the point where the trusted proxy has sent its certificate to the browser, before aborting TLS and restarting with cleartext HTTP/1.x — or maybe it could just be removed, or harmonised with 3.1.

Anyway, stepping back for a moment from the actual mechanics described by Sal, to me the basic principles on which this proposal is based are sound:

  *   the service is optional;
  *   the choice of using the service is user-driven with clear opt-in/out flow;
  *   the trusted proxy must provide cogent evidence about its identity, so it’s not easy to impersonate it;
  *   there is a clear path for establishing the trust relationship;
  *   it should be easy to implement and deploy.

So, this is possibly the most promising solution I’ve heard in terms of balance between the user needs & rights, and the network operators interests.
That’s why I’d hope we do not shelve it in a hurry.

Cheers

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 18 Feb 2014 23:37:38 -0800

> carried over HTTP/2.0 + TLS

If this is the case, I'm less concerned. I misinterpreted the
"trusted" part of the proxy proposal as implying that the proxy would
be trusted to snoop on https traffic, as that's how we've previously
used the term. If this proxy has no more privilege than any other
forward proxy, that sounds mostly fine to me. That said, I still agree
with Patrick that there doesn't seem any reason to allow
differentiation of http vs https traffic. If the user agent and origin
agree to put http traffic over a user-agent<=>origin TLS connection,
then they should be allowed to do so without having to mark it via
ALPN. If the user agent really wanted to opt into letting the proxy
server see the http request, it can issue the http request to the
proxy and let the proxy fetch it from the origin, just like we do for
all other HTTP forward proxies today.

I recommend rephrasing this as a secure proxy proposal, rather than a
trusted proxy proposal. Securing the user-agent<=>proxy connection
sounds like a fine endeavor to me (indeed, Chromium already supports
this behavior), and I'd like to see it standardized.

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Wed, 19 Feb 2014 09:51:37 +0100

Le Mer 19 février 2014 05:54, William Chan (陈智昌) a écrit :
> consensus on in the near future.

Are there still people who deny the law (even in democratic countries)
requires such snooping in some contexts? For example traders have to
enable snooping to prove they are not performing insider trading at work
and I'm sure there are lots of other cases I don't know of.

> Let me ask another question. Is there

Let me reverse the proposition: there are lots of proxy-using
organisations which have refused all user-agent attempts to remove proxies
for more than a decade. They represent a significant part of the http1
user base. If there is no plan to support this use case there is no point
on this workgroup since its charter is not met.

Of course user agents representatives may be working on another proposal
I'm not aware of. If that's the  case all is fine, please share it!

Regards,

-- 
Nicolas Mailhot

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Wed, 19 Feb 2014 09:53:57 +0100

Le Mar 18 février 2014 10:49, Salvatore Loreto a écrit :

> OCSP  to check the validity of certificates from the CA if the OCSP is ran

When OSCP refers to an external validation server accessing it requires
going through the proxy first…

-- 
Nicolas Mailhot

---

From: Fabian Keil <[email-masked]>
Date: Wed, 19 Feb 2014 12:13:59 +0100

> standardizing any mechanism for doing this. Is there any?

A couple of examples have already been given.

Another example would be proxies like Privoxy which are most of the
time running on the same system as the user agent and administrated
by the end user.

In this scenario it's in the end user's interest to be able to allow
the proxy to read, modify and block at least some of the requests
and responses and it would be great if the user agent could clearly
indicate whether or not a given website could be modified by the proxy.

Fabian

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 20 Feb 2014 01:23:15 +1300

> going through the proxy first…

Which circles back to DANE being far better than OSCP for most of these
scenarios. So the thing which should be mandated IMHO.
As this whole scenario is new there is no reason to stick with the
verification methods known to be unworkable.

Amos

---

From: Peter Lepeska <[email-masked]>
Date: Wed, 19 Feb 2014 10:30:01 -0500

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

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 19 Feb 2014 08:10:55 -0800

On Tue, Feb 18, 2014 at 8:54 PM, William Chan (陈智昌)
<[email-masked]>wrote:

> all said we do not support this.

How can any vendor know whether or not they support a feature that has not
even been well described?

> If that's in error, please speak up.

The value has been stated repeatedly. If we don't standardize it, then the
security of your users measurably goes down. Getting users to install
private trust anchors that are known to be not as well protected as the
rest of the trust anchors does a disservice to Internet security.

--Paul Hoffman

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 19 Feb 2014 16:27:33 +0000

On 19/02/2014 15:30, "Peter Lepeska" <[email-masked]<mailto:[email-masked]>> wrote:
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.

Actually, it looks like the extended key usage bit in the proxy certificate (http://tools.ietf.org/html/draft-loreto-httpbis-trusted-proxy20-01#section-3.1) would be a handy hook to customise the UX for this use case.

---

From: Patrick McManus <[email-masked]>
Date: Wed, 19 Feb 2014 12:12:30 -0500

I apologize I was AFK for a couple days.

On Tue, Feb 18, 2014 at 9:02 PM, William Chan (陈智昌)
<[email-masked]>wrote:

> the forward proxy is authenticated.

There seems to be some confusion. This reply makes it sound like I was
talking about the connection between the UA and the proxy - which I did not
mean to. I am talking about the connection between the UA and the origin
server prior to proxy detection - perhaps in cases where there is no proxy
present.

In particular am talking about section 3.2.. which envisions a connection
to the origin over TLS for an http URI. The proposal suggests that the ALPN
token of h2clr be used to distinguish this connection from ones carrying
https URIs. The IP destination address of the request is that of the origin.

According to the description, a proxy hijacks that TCP connection based on
the ALPN token before forwarding the Client Hello and inserts a TLS Alert
on the data stream with the src IP of the origin.

The user agent is expected to fallback to HTTP/1 in cleartext and repeat
the query to the origin. According to the draft, the proxy again hijacks
that TCP session and replies with a HTTP/1 redirect to an authenticated
proxy credential page on https://. That page helps you configure your UA so
that future queries are addressed to the proxy instead of to the origin
based on PKI trust.

No error page is described and there is an explicit dependency on the
fallback to cleartext when the original transaction is blocked.

A major concern here is that a traditional MITM attacker is pretty much
inseperable from the proxy envisioned by the draft. i.e. in the absence of
a proxy the MITM sees "h2clr" and forces a downgrade via an injected (and
unauthenticated) Alert and the UA repeats the transaction in cleartext.
MITM wins.

The proposal to use h2clr makes this problem more severe than it would
normally be because the http transactions can no longer mix themselves into
the https stream unobtrusively. Thus they are identifying to the attacker
that they can be messed with and that's an advantage to the attacker who
would ordinarily run the risk of getting an error when they injected the
TLS Alert.

I'm trying not to comment directly on the merits of the overall proxy
proposal other than the change it is proposing to the core http/2 protocol.
So I'm opposed to the change in ALPN tokens on these grounds as well as the
efficiency grounds of requiring the use of more connections to carry
multiple schemes via the same route.

---

From: Patrick McManus <[email-masked]>
Date: Wed, 19 Feb 2014 12:25:43 -0500

> this behavior), and I'd like to see it standardized.

I'm would also like to see TLS to the proxy for both http and https
resources (where https resources contain an e2e TLS session tunneled inside
the connection to the proxy) when the UA has chosen to use the proxy.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 19 Feb 2014 10:03:45 -0800

> indicate whether or not a given website could be modified by the proxy.

Use a browser add-on/extension. Or use TorBrowser.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 19 Feb 2014 10:09:19 -0800

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.

On Wed, Feb 19, 2014 at 7:30 AM, Peter Lepeska <[email-masked]> wrote:
> 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.
> 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.
>
> 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 (陈智昌) <[email-masked]>
> wrote:
>>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 19 Feb 2014 10:16:07 -0800

On Wed, Feb 19, 2014 at 8:10 AM, Paul Hoffman <[email-masked]> wrote:
> On Tue, Feb 18, 2014 at 8:54 PM, William Chan (陈智昌) <[email-masked]>
> wrote:
>
>>

Sorry, my last sentence in that above paragraph was misleading. There
was a discussion at Zurich about how user agents felt about trusting
proxies to snoop on https traffic, and all user agents present (I
mentioned them already) did not support it. You're right, we didn't
discuss this *specific* proposal here. I will let other user agents
speak for themselves here. My point is, if no user agent supports this
direction, then I don't think we should standardize, since I don't
think we'll have running code.

> private trust anchors that are known to be not as well protected as the rest
> of the trust anchors does a disservice to Internet security.

You ignored the conditional in my statement. I shall repeat it. *If no
user agent plans on supporting this*, I don't see the value of
standardizing it. You may reasonably argue that user agents *should*
support this. Therefore, I'm asking if there are user agents that
support this.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 19 Feb 2014 10:20:48 -0800

Sorry, I was confused. Indeed, I agree with you that, were we to send
http schemed requests over a HTTP/2/TLS connection, we should not
separate the http schemed requests and https schemed requests into
separate connections that are identifiable via ALPN.

On Wed, Feb 19, 2014 at 9:12 AM, Patrick McManus <[email-masked]> wrote:
> On Tue, Feb 18, 2014 at 9:02 PM, William Chan (陈智昌) <[email-masked]>
> wrote:
>>
> In particular am talking about section 3.2.. which envisions a connection to
> the origin over TLS for an http URI. The proposal suggests that the ALPN
> the ALPN token before forwarding the Client Hello and inserts a TLS Alert on
> the data stream with the src IP of the origin.
>
> The user agent is expected to fallback to HTTP/1 in cleartext and repeat the
> query to the origin. According to the draft, the proxy again hijacks that
> TCP session and replies with a HTTP/1 redirect to an authenticated proxy
> credential page on https://. That page helps you configure your UA so that
> future queries are addressed to the proxy instead of to the origin based on
> PKI trust.
>
> inseperable from the proxy envisioned by the draft. i.e. in the absence of a
> proxy the MITM sees "h2clr" and forces a downgrade via an injected (and
> unauthenticated) Alert and the UA repeats the transaction in cleartext. MITM
> wins.
>
> would ordinarily run the risk of getting an error when they injected the TLS
> Alert.
>

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 19 Feb 2014 20:46:29 +0000

On Feb 19, 2014, at 3:02 AM, William Chan (陈智昌) <[email-masked]> wrote:

> authenticated

yes exactly the connection between the UA and Proxy is fully authenticated

> and I think user agents should show an error page if

yes

> traffic?

No, there isn't any QoS reason behind 

> If so, I disagree with this on principle. https:// traffic
> should not be discriminated against.

 it is not the intention of our draft really!

> I agree with Patrick that it's
> reasoning behind separating out the connections.

the main is to leave  the HTTPS flows completely untouched, to make crystal clear that the Proxy
won't do anything for those flows.
the proposal also minimise the change in the specification;
and as we are also playing with some code we thought it was a solution that could be straightforward and easy to implement

anyway 
point taken, I will add an explanatory section on the reason to differentiate the HTTPS from the HTTP flow … in the next version
if we will still be convinced that is the right solution

> Sorry if I'm being

and we are not proposing that
secure proxy that is described in the draft won't do that

/Sal

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 19 Feb 2014 20:55:53 +0000

> E.g. getting lower latencies on mobile networks (due to improved caching

caching is one of the benefit of course.

even a HTTP2 or SPDY connection is not able to fully utilise the access link due to the fact
that there is not always content to send. This is because the Browser may 'wait' until sending
subsequent request (i.e. parsing, JS processing, etc).
Such request would then causes an RTT latency in the reply even assuming 'warm' TCP.
In our internal measurements there have been many such cases for a page thus the RTT impact multiplies.
With the presence of a statically cached proxy, the request/response pattern become faster.

another benefit is that a proxy in an access network is the one that is in the best position to know the real
status of the network and can use those information to play with the HTTP2 flow control mechanism
in order to provide a better user experience to the end user

a forward trusted proxy, not necessarily one in the access network, can also provide anonymity to a User-Agent
in the case the User does not trust the content provider 

/Sal

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 19 Feb 2014 21:04:28 +0000

On Feb 19, 2014, at 8:37 AM, William Chan (陈智昌) <[email-masked]> wrote:

> trusted proxy proposal.

thanks for the suggestion
the terminology is always a slippery field, let's consolidate it

I will change to "secure proxy" in the next version

> Securing the user-agent<=>proxy connection

+1

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 19 Feb 2014 21:17:52 +0000

> 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

/Sal

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 19 Feb 2014 21:24:50 +0000

On 19/02/2014 07:37, "William Chan (陈智昌)" <[email-masked]> wrote:
>That said, I still agree
>ALPN.

As far as I understand, the browser could just decide to use h2 for
everything and thus opt-out completely.

The h2clr flag is a hint that the user agent can give to the network.  It
allows an on-path proxy to jump in, provide strong identity proof, and (if
explicitly allowed) MITM the user’s http requests sent over HTTP/2.0+TLS.

Thus, under user consent, the cache/inspection/whatever function for
non-https traffic that used to work with cleartext HTTP/1.x is re-enabled.
 Win-win?

Cheers

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 19 Feb 2014 16:32:11 -0800

> everything and thus opt-out completely.

I see, if this is just an option, then I'm less concerned. But let's
only standardize an option that implementations plan on using. What
user agent plans on supporting this? I can't see Chromium doing this.

> non-https traffic that used to work with cleartext HTTP/1.x is re-enabled.

Users will not grok this prompt for the user consent, so I can't
imagine prompting the user in Chromium. I'm curious what other user
agent implementers think.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 19 Feb 2014 16:40:08 -0800

> 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?

---

From: Liliana Dinale <[email-masked]>
Date: Thu, 20 Feb 2014 11:47:10 +0000

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: [email-masked] [mailto:[email-masked]] 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; [email-masked]; GUS BOURG
Subject: Re: new version trusted-proxy20 draft

On Wed, Feb 19, 2014 at 1:17 PM, Salvatore Loreto <[email-masked]> wrote:
> 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?

>>> 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.
>>> 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 8:18 PM, Paul Hoffman 
>>>> <[email-masked]>
>>>> 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.
>>>>
>>>
>

---

From: Roland Zink <[email-masked]>
Date: Thu, 20 Feb 2014 19:25:59 +0200

> agent implementers think.

If I would need to implement an app then I would prefer to avoid a second HTTP1/1 infrastructure for environments where a connection without inspection is not allowed. In the app there might be a general setting to allow this based on the needed privacy of the data. A app may have better knowledge about the problem domain than a browser.

Roland

---

From: Patrick McManus <[email-masked]>
Date: Fri, 21 Feb 2014 08:21:20 -0500

On Wed, Feb 19, 2014 at 3:53 AM, Nicolas Mailhot <
[email-masked]> wrote:

> going through the proxy first...
>
> --

OCSP Stapling would be the answer here. (the proxy presents the OCSP
response as part of the TLS handshake.. it is still signed by the CA though
with a short lifetime - so the client doesn't need to go to the CA directly)

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 24 Feb 2014 17:31:37 +1100

On 20 Feb 2014, at 11:40 am, William Chan (陈智昌) <[email-masked]> wrote:

> 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.

There seems to be a reasonable amount of support for this, and no dissent that I've heard. 

What needs to be specified here? We don't say much about proxies yet. I suppose we might need something like RFC2818 for secure proxies, but that seems somewhat straightforward, and it might be better for that to happen in the TLS WG (indeed, our charter pretty much says so).

Note that I've just opened <https://github.com/http2/http2-spec/issues/413> to talk about proxies a bit more in general.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: William Chan (陈智昌) <[email-masked]>
Date: Sun, 23 Feb 2014 22:35:40 -0800

> What needs to be specified here? We don't say much about proxies yet. I suppose we might need something like RFC2818 for secure proxies, but that seems somewhat straightforward, and it might be bet…

I don't think that there's anything HTTP/2 specific about "secure"
proxies. Should we decouple it and just standardize it separately from
HTTP/2 (although I think it's likely that the HTTP/2 spec may want to
reference it)?

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 24 Feb 2014 17:37:06 +1100

On 24 Feb 2014, at 5:35 pm, William Chan (陈智昌) <[email-masked]> wrote:

> I don't think that there's anything HTTP/2 specific about "secure" proxies.

That's kind of what I'm getting at...

> Should we decouple it and just standardize it separately from HTTP/2 (although I think it's likely that the HTTP/2 spec may want to reference it)?

Well, my point was that I wasn't even sure it's something "we" need to do (i.e., this WG). What actually would need to be written down?

Cheers,

---

From: William Chan (陈智昌) <[email-masked]>
Date: Sun, 23 Feb 2014 22:41:05 -0800

> That's kind of what I'm getting at...

Apologies, I clearly missed that sentence later in your email :) I'm
going to blame it on my cold.

> Well, my point was that I wasn't even sure it's something "we" need to do (i.e., this WG). What actually would need to be written down?

Uh, good point. I dunno :)

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 24 Feb 2014 11:00:49 +0200

> URL:            http://www.ietf.org/internet-drafts/draft-loreto-httpbis-trusted-proxy20-01.txt

Some comments:

1) As others have said, unnecressarily admitting to possible attackers
that connections aren't really protected is not a good idea.

2) The downgrade to HTTP/1.1 for proxy setup looks really odd, and
should be over TLS too.

3) Leaving manual configuration aside, there is certain merit to the
idea that network is able to force a proxy. OTOH, the arising security
issues aren't trivial (understatement).

4) One idea would be h2p / h2pxy / h2proxy protocol, which would be
HTTP/2 with some extensions for proxy operation, like additional
response codes, proxy being able to respond for itself, browser being
able to send request to proxy, proxy relaying certificate info, etc...

5) Regarding to usescases, protocol conforming to principle of
least priviledge and accomodiating all or even most of those (goes
up to "Tom's Rural broadband" right now) would likely be hideously
complicated mess of crypto.

6) Because of the last, one is pretty much limited to no trust (CONNECT)
or full trust (GET/POST/PUT).

-Ilari

---

From: Amos Jeffries <[email-masked]>
Date: Mon, 24 Feb 2014 22:05:30 +1300

> Well, my point was that I wasn't even sure it's something "we" need to do (i.e., this WG). What actually would need to be written down?

I think a BCP statement that connections to explicit proxy should be
doen or at least allowed to use a TLS encrypted connection.
Along with a list of the current explicit proxy discovery mechanisms in
use and how TLS should be signalled in each (ie. environment variable
http_proxy="https://..." vs. https_proxy="...")

Guidance for implementers to follow that will provide interoperable code.

Amos

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 24 Feb 2014 09:35:19 +0000

On Feb 24, 2014, at 11:05 AM, Amos Jeffries <[email-masked]>
 wrote:

>> That's kind of what I'm getting at…

I tend to agree...
the only thing that can be seen as strictly related even if not specific is
the usage of http URIs over TLS
and the role of "secure" proxies in the http URIs over TLS flow

> Guidance for implementers to follow that will provide interoperable code.

I agree with Amos here
that seems to be something reasonable to have in the main spec…

but it would be great also to have a separate draft talking about new discovery
mechanisms and the proxy interaction 

br
Salvatore

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Mon, 24 Feb 2014 11:10:45 +0100

Le Lun 24 février 2014 07:31, Mark Nottingham a écrit :
>> supportive of standardizing this.
>
> What needs to be specified here?

1. how the proxy link can be authentified and re-authentified (when auth
expires) in a secure manner (not the current auth mess that does not work
for tls)
2. some replacement for pac mecanism that uses declarative mode and not a
software language, and is not fixed after web client startup
3. status codes for various proxy events
  1. ??A: rebalance: pac preplacement proxy info with the list of preferred
proxies to use at this moment and sites that can be reached directly
  2. 511: portal → go authenticate or click through this location before
continuing
     a. do web clients need a separate re-auth code or will they be smart
enough to replay auth if they receive a new 511 to the same location
after a while? Question for web client people
     b. I assume the location needs to be https using the same kind of
cert as the proxy node
  3. ??B: downgrade → operator only allows h2clr to this site, downgrade
h2 to h2clr or go away (direct has already failed at this stage)
  4. 666: forbidden → proxy operator really does not want you to go there,
life sucks
  5. ??C: dns error → proxy can't find your site
  6. ??D: timeout   → web site does not answer

Regards,

-- 
Nicolas Mailhot

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Mon, 24 Feb 2014 11:17:08 +0100

Le Lun 24 février 2014 07:35, William Chan (陈智昌) a écrit :
>> What needs to be specified here? We don't say much about proxies yet. I
>> suppose we might need something like RFC2818 for secure proxies, but
>> that seems somewhat straightforward, and it might be better for that to
>> happen in the TLS WG (indeed, our charter pretty much says so).
>
> proxies.

Proxy dialog will necessarily will be a dialect of http2. Or do you want
to force every http2 implementer to code a second protocol with no
relationship to http every time they have to deploy on proxified networks?

And proxy dialog is more than "proxy here, connect". Sure it's not a lot
more, but that's the difference between smooth operation and all the weird
failure modes we get in http1 because the proxy part has been
underspecified. Please to not make this mistake again.

Regards,

-- 
Nicolas Mailhot

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 24 Feb 2014 10:33:32 +0000

Hi Ilari

thanks a lot for your comments see my answers in line

> 2) The downgrade to HTTP/1.1 for proxy setup looks really odd, and

thanks to all the mail discussions, more thoughts and other chats on the issue
I tend to agree that the captive proxy (i.e. section 3.2) solution with the downgrade to http/1.1 is not a 
so great proposal… 

especially compared to the trusted proxy one
http://tools.ietf.org/html/draft-loreto-httpbis-trusted-proxy20-01#section-3.1

> issues aren't trivial (understatement).

security issues are never trivial

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 24 Feb 2014 11:56:52 +0100 (CET)

> or full trust (GET/POST/PUT).

So I am new to this discussion, but I'll give it a go anyway.

The "mess of crypto" mentioned above, does that relate to an "onion style" 
kind of crypto, where the web server would first encrypt/sign the object 
with its own cert, and then use another one to send traffic to the proxy?

I was thinking if it was possible to keep confidentiality of the 
communication between web browser and web server, but still give the proxy 
enough information to do its job which would be caching and/or doing 
content access control.

I guess the use-cases that are being adressed by this draft are two-fold:

1. Proxy that wants to know what URLs are being used so it can 
record/limit access.

2. Proxy that contains malware detection and so on to inspect all contents 
before it's delivered to the end systems.

With 1, if the content could be encrypted by one layer of crypto and a 
second layer for the session to/from the proxy, this would solve that 
problem. The end system could still verify the contents and that it hadn't 
been tampered with.

With 2, I don't see any other solution than the one suggested in the 
discussed draft with the proxy having full MITM capability.

If people were in the technical plenary session in Vancouver at IETF88, I 
was the one requesting more work on usability when it comes to crypto. How 
the user should be informed of current network security situation (if 
proxy can inspect the traffic or not) is also a tricky one. We also need 
settings on the devices saying what apps are allowed to communicate under 
what circumstances etc. I do not want my bank app to allow MITM, whereas I 
might be ok sometimes with my web browser when I use certain web sites 
with no important content to me.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 24 Feb 2014 14:05:23 +0200

On Mon, Feb 24, 2014 at 11:56:52AM +0100, Mikael Abrahamsson wrote:
> The "mess of crypto" mentioned above, does that relate to an "onion
> style" kind of crypto, where the web server would first encrypt/sign
> the object with its own cert, and then use another one to send
> traffic to the proxy?

Well, if you just need downstream integerity, one could just put a
random MAC key in, sign that with server's public key and then do
a streaming MAC with given key.

Doing encrypted caching... That would require client and server to
share state.

> communication between web browser and web server, but still give the
> proxy enough information to do its job which would be caching and/or
> doing content access control.
> 

Encrypting arbitrary data in upstream direction is doable. Question
is, what can be encrypted without causing smuggling issues.
 
> 2. Proxy that contains malware detection and so on to inspect all
> contents before it's delivered to the end systems.

Such system does not necressarily have to modify upstream/downstream
data, just be able to reject requests.

-Ilari

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 24 Feb 2014 13:18:04 +0100 (CET)

> Doing encrypted caching... That would require client and server to

Well, yes, but my thinking was that the key to decrypt this object could 
be shared over a control channel. If login is required to the site then 
only clients would get this key after login.

> Encrypting arbitrary data in upstream direction is doable. Question is, 
> what can be encrypted without causing smuggling issues.

I'd guess as soon as encryption is employed, smuggling is always possible. 
But if the proxy owner wants for instance to emply whitelists of what 
sites are allowed then hopefully this whitelist would only allow sites 
where smuggling is unlikely.

> data, just be able to reject requests.

Well, it still needs to inspect the data so it still needs to decrypt it. 
I agree that it doesn't need to possibility of modifying it and delivering 
it to the client with proper encryption/signature, it just has to refuse 
to serve it.

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 24 Feb 2014 14:32:10 +0200

On Mon, Feb 24, 2014 at 01:18:04PM +0100, Mikael Abrahamsson wrote:
> >Encrypting arbitrary data in upstream direction is doable.
> >Question is, what can be encrypted without causing smuggling
> >issues.
> 
> I'd guess as soon as encryption is employed, smuggling is always
> possible. But if the proxy owner wants for instance to emply
> whitelists of what sites are allowed then hopefully this whitelist
> would only allow sites where smuggling is unlikely.

I mean things like:

:method GET
:scheme http
:path /some/innocent/path
:authority foo.example
<...>
Encrypted {
:path /porn-stash/
User-Agent: foobar/1.0
Accept-Encoding: identity, gzip, deflate, bzip2, xz
<...>
}

Note two :path headers.

Or:

:method GET
:scheme http
:path /some/innocent/path
:authority foo.example
<...>
Encrypted {
User-Agent: foobar/1.0
Accept-Encoding: identity, gzip, deflate, bzip2, xz
<...>
<End of request>
:method GET
:scheme http
:path /porn-stash/
:authority foo.example
<...>
}

Where entiere request is smuggled.

-Ilari

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 24 Feb 2014 12:36:10 +0000

On Feb 24, 2014, at 12:56 PM, Mikael Abrahamsson <[email-masked]> wrote:

> The "mess of crypto" mentioned above, does that relate to an "onion style" kind of crypto, where the web server would first encrypt/sign the object with its own cert, and then use another one to send traffic to the proxy?
> 
> I was thinking if it was possible to keep confidentiality of the communication between web browser and web server, but still give the proxy enough information to do its job which would be caching and/or doing content access control.

just to be clear 
the draft proposes to separate streams (i.e. two TLS associations) one for https URIs resources and one for http URIs resources
in the proposal the draft won't do anything for the TLS association used to transport https URIs resources
and it will only ask consent to be in the loop for the TLS association for the http URIs resources (when transported over TLS)

so it will still be possible to keep confidentiality of the communication between web browser and web server

> 1. Proxy that wants to know what URLs are being used so it can record/limit access.
> 
> 2. Proxy that contains malware detection and so on to inspect all contents before it's delivered to the end systems.

yes but again only limited on "http" URLs … when transported over TLS on HTTP2

if the user (i.e. the WebBrowser) is trying to reach an "https" URLs then it will work exactly as today
with no possibility for the proxy to see anything.

> 
> With 1, if the content could be encrypted by one layer of crypto and a second layer for the session to/from the proxy, this would solve that problem. The end system could still verify the contents and that it hadn't been tampered with.
> 
> With 2, I don't see any other solution than the one suggested in the discussed draft with the proxy having full MITM capability.
> 
> If people were in the technical plenary session in Vancouver at IETF88, I was the one requesting more work on usability when it comes to crypto. How the user should be informed of current network security situation (if proxy can inspect the traffic or not) is also a tricky one. We also need settings on the devices saying what apps are allowed to communicate under what circumstances etc. I do not want my bank app to allow MITM,

neither we want, really!
and we are not proposing it.

> whereas I might be ok sometimes with my web browser when I use certain web sites with no important content to me.

and we are proposing only for the "http://" resources

so it will up to the content provider to decide if they think that there will be a benefit for their content from having a proxy in between
(i.e. providing the content as an "http://" URI resource over TLS) or they think that there should not be any proxy (and in this case they will 
provide the content as an "https://" URI resource over TLS)

moreover even if the content provider will provide the content as an "http://" URI resource
we are proposing that the user should be able to opt out and decide not to have any proxy in the middle

br
Salvatore

---

From: Patrick McManus <[email-masked]>
Date: Mon, 24 Feb 2014 07:56:49 -0500

I don't think there is anything to block http/2 on other than noting proxy
connections over tls is a perfectly sensible thing to do.

The one thing I did wonder about was whether an http/2 ua<>proxy connection
doing https:// to a http/2 server should make 1 connect per transaction or
1 connect and then multiplex its transactions on that  single stream. (I
decided on 1 connect because it minimizes the tls handshakes, but you can
argue that multiple connects allow you to better represent priorities and
windows through the proxy, etc..)

Personally I think this is an implementation choice and doesn't need
standards language, but reasonable folks may disagree.

On Mon, Feb 24, 2014 at 1:41 AM, William Chan (陈智昌)
<[email-masked]>wrote:

> >> Should we decouple it and just standardize it separately from HTTP/2
> (although I think it's likely that the HTTP/2 spec may want to reference
> it)?
> >
> > Well, my point was that I wasn't even sure it's something "we" need to
> do (i.e., this WG). What actually would need to be written down?
>

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Mon, 24 Feb 2014 14:36:57 +0100

> data, just be able to reject requests.

For the AV part, if you can't read the content, you can't match virus
signatures

Regards,

-- 
Nicolas Mailhot

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 24 Feb 2014 13:47:52 +0000

On Feb 24, 2014, at 2:56 PM, Patrick McManus <[email-masked]<mailto:[email-masked]>> wrote:

I don't think there is anything to block http/2 on other than noting proxy connections over tls is a perfectly sensible thing to do.

it is a perfectly and sensible thing to do!
but noting just that maybe it is a little to vague as the spec would not say anything about how
the proxy would be discovered and/or configured.

The one thing I did wonder about was whether an http/2 ua<>proxy connection doing https:// to a http/2 server should make 1 connect per transaction or 1 connect and then multiplex its transactions on that  single stream. (I decided on 1 connect because it minimizes the tls handshakes, but you can argue that multiple connects allow you to better represent priorities and windows through the proxy, etc..)

my preference is on multiple connects (i.e. one for origin server) in order to better represent priorities and windows thru the proxy

Personally I think this is an implementation choice and doesn't need standards language, but reasonable folks may disagree.

to be honest, I don't know if I disagree or not… let me think about it

/Salvatore

On Mon, Feb 24, 2014 at 1:41 AM, William Chan (陈智昌) <[email-masked]<mailto:[email-masked]>> wrote:
On Sun, Feb 23, 2014 at 10:37 PM, Mark Nottingham <[email-masked]<mailto:[email-masked]>> wrote:
>
> On 24 Feb 2014, at 5:35 pm, William Chan (陈智昌) <[email-masked]<mailto:[email-masked]>> wrote:
>

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 24 Feb 2014 15:05:21 +0100

>Diff:           http://www.ietf.org/rfcdiff?url2=draft-loreto-httpbis-trusted-proxy20-01

The first phrase in the document is "HTTPBis Working Group". Apparently
that has lead some people to think this is a document by the HTTPBis
Working Group, but the filename does not follow the appropriate conven-
tion and http://tools.ietf.org/wg/httpbis/ does not identify it as a WG
document.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 24 Feb 2014 19:57:45 +0000

> proxy if you want to let it see it, just like we do for configured

The value proposition here is that the user-agent does not have to be configured to use the proxy, but is still able to take advantage of the benefits it can provide.

Think about the situation where you're on vacation in a remote area with limited network resources. You wish to download an application.  The network you're on has a caching proxy with the application cached.  You are able to download the application faster, without tying up the resources in the remote location.  That's the value proposition.

I have also tried to explain those benefit here [1]

And yes, the response is "well why not just configure the user-agent to use the caching proxy?" Technically, this suggestion is completely correct, but from a practical standpoint it makes no sense at all: users will not manually configure address http proxies.  
What we're proposing here is providing better security for the user-agent (all content encrypted), preserving existing functionality (caching proxies, virus scanning proxies, etc), and providing a mechanism where the user is completely aware of any entity in the middle of their normal "http://" traffic.  

Https traffic, is still there, providing private end to end encryption.

br
Sal

[1]http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/0602.html

---

From: William Chan (陈智昌) <[email-masked]>
Date: Mon, 24 Feb 2014 12:10:18 -0800

> >> indeed we are only proposing the possibility for the proxy to ask
consent
> The value proposition here is that the user-agent does not have to be
configured to use the proxy, but is still able to take advantage of the
benefits it can provide.
>
> Think about the situation where you're on vacation in a remote area with
limited network resources. You wish to download an application.  The
network you're on has a caching proxy with the application cached.  You are
able to download the application faster, without tying up the resources in
the remote location.  That's the value proposition.
> And yes, the response is "well why not just configure the user-agent to
use the caching proxy?" Technically, this suggestion is completely correct,
but from a practical standpoint it makes no sense at all: users will not
manually configure address http proxies.
> What we're proposing here is providing better security for the user-agent
(all content encrypted), preserving existing functionality (caching
proxies, virus scanning proxies, etc), and providing a mechanism where the
user is completely aware of any entity in the middle of their normal
"http://" traffic.

Oic, I had assumed we were only talking about configured proxies. This
makes more sense now, but I still disagree with it because it weakens
opportunistic encryption (which I also don't support but I don't see why we
should weaken that).

Can you clarify whether the "secure" proxy (TLS to the proxy) part of your
proposal is also for transparent proxies? I don't see how that would be
possible, so I assume at least that part is for a configured proxy.

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 24 Feb 2014 20:57:10 +0000

On Feb 24, 2014, at 10:10 PM, William Chan (陈智昌) <[email-masked]<mailto:[email-masked]>>
 wrote:

On Feb 24, 2014 11:57 AM, "Salvatore Loreto" <[email-masked]<mailto:[email-masked]>> wrote:
>
>
> On Feb 20, 2014, at 2:40 AM, William Chan (陈智昌) <[email-masked]<mailto:[email-masked]>> wrote:
>
> >> On Feb 19, 2014, at 7:09 PM, William Chan (陈智昌) <[email-masked]<mailto:[email-masked]>> wrote:
> >>

Oic, I had assumed we were only talking about configured proxies. This makes more sense now, but I still disagree with it because it weakens opportunistic encryption (which I also don't support but I don't see why we should weaken that).

Can you clarify whether the "secure" proxy (TLS to the proxy) part of your proposal is also for transparent proxies? I don't see how that would be possible, so I assume at least that part is for a configured proxy.

let me start clarifying my previous answer, when I said
"The value proposition here is that the user-agent does not have to be configured to use the proxy, but is still able to take advantage of the benefits it can provide."

I meant "the user-agent does not have to be *manually configured* to use the proxy"
the proposal DOES NOT propose a transparent proxy solution

we are proposing that the proxy always advertises itself and its presence to the user
the user is fully in control, she/he has to provide or deny consent to use the proxy…
if the user provides consent to the proxy then and only then the proxy becomes configured within the user agent

so the answer is YES we are talking about configured proxy

---

From: William Chan (陈智昌) <[email-masked]>
Date: Mon, 24 Feb 2014 13:25:39 -0800

OIC now. Thanks for the continued explanations. So, *if* (1) the user
agent is using opportunistic encryption to the origin *and if* (2) the
user agent opts into identifying MITM'able connections via ALPN
(through some unspecified UI, but one that might be agnostic to a
specific proxy), then a proxy can interpose itself in this fashion.
This is one method of discovering "secure" proxies.

I still don't understand why a user agent who supports HTTP requests
over unauthenticated TLS would want to identify the unauthenticated
TLS connections.

I've asked this before, and I still think it's a reasonable question.
Is there another vendor that wants to interop with this kind of proxy?
I'm asking this because I think that the purpose of standardizing such
a proposal is for interoperability across vendors, and I don't see the
point if the only implementations are Ericsson. But I may be
misunderstanding IETF policy here.

On Mon, Feb 24, 2014 at 12:57 PM, Salvatore Loreto
<[email-masked]> wrote:
>
> On Feb 24, 2014, at 10:10 PM, William Chan (陈智昌) <[email-masked]>
>  wrote:
>
>> limited network resources. You wish to download an application.  The network
>> you're on has a caching proxy with the application cached.  You are able to
>> download the application faster, without tying up the resources in the
>> remote location.  That's the value proposition.
>>
>> (all content encrypted), preserving existing functionality (caching proxies,
>> virus scanning proxies, etc), and providing a mechanism where the user is
>> completely aware of any entity in the middle of their normal "http://"
>> traffic.
>
> Oic, I had assumed we were only talking about configured proxies. This makes
> more sense now, but I still disagree with it because it weakens
> "The value proposition here is that the user-agent does not have to be
> benefits it can provide."
>

---

From: Paul Ferguson <[email-masked]>
Date: Mon, 24 Feb 2014 15:06:18 -0800

Below:

> Https traffic, is still there, providing private end to end encryption.

I do not believe that to be true (end to end encryption) if a proxy is
removing SSL headers and then reapplying them. Or do I misunderstand?

If that is the case, then data is in clear text at the proxy between
rewriting SSL headers?

- ferg

-- 
Paul Ferguson
VP Threat Intelligence, IID
PGP Public Key ID: 0x54DC85B2

---

From: James Cloos <[email-masked]>
Date: Mon, 24 Feb 2014 21:58:59 -0500

There are only a few things http/2 should say about proxies:

Proxies MAY use http/2 to grab the resources for which clients ask.

Proxies MAY offer http/2 to clients.

Clients seeking https URIs via a proxy MUST use CONNECT and end-to-end tls.

If anyone wants a proxy to cache anything, and also wants to use http/2,
they MUST use http-upgrade (rather than alpn) to specify their preference
for http/2 instead of http/1.

(If anyone has a legal requirement to avoid end-to-end encryption, they
MUST accomplish that by avoiding TLS between client and proxy.  Such
requirements MUST not affect the rest of us.)

-JimC
--
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Tue, 25 Feb 2014 08:49:59 +0100

Le Mar 25 février 2014 03:58, James Cloos a écrit :
>if anyone has a legal requirement to avoid end-to-end encryption, they

This forbids an http/1 use case and as such is outside the workgroup charter

-- 
Nicolas Mailhot

---

From: Roland Zink <[email-masked]>
Date: Tue, 25 Feb 2014 10:40:45 +0100

> misunderstanding IETF policy here.
There are other implementations of "secure proxies" like Chrome on 
Android can use a Google proxy. Why should a user trust the Google proxy 
more than a proxy from <insert your favorite mobile network operator>? 
An interoperability would be good.

---

From: Ryan Hamilton <[email-masked]>
Date: Tue, 25 Feb 2014 07:31:01 -0800

I think that Will is supportive of secure proxies as he said upthread:

Chrome currently supports specifying such proxies via pac files:

http://www.chromium.org/developers/design-documents/secure-web-proxy

Cheers,

Ryan

On Tue, Feb 25, 2014 at 1:40 AM, Roland Zink <[email-masked]> wrote:

> There are other implementations of "secure proxies" like Chrome on Android
> can use a Google proxy. Why should a user trust the Google proxy more than
> a proxy from <insert your favorite mobile network operator>? An
> interoperability would be good.
>
>
>

---

From: Peter Lepeska <[email-masked]>
Date: Tue, 25 Feb 2014 20:09:55 -0500

Hi Salvatore,

As you know, I'm all for new proposals that support both Secure Proxy and
Trusted Proxy. So thanks for writing and posting this. I'm struggling to
understanding how http URIs over TLS work as described in your draft. My
main question is:

If the content server supports authenticated TLS, then why isn't the
content just hosted via "https"-schemed URIs? What is the reason that the
content server would make this content available via http schemes?

Thanks,

Peter

On Tue, Feb 25, 2014 at 10:31 AM, Ryan Hamilton <[email-masked]> wrote:

>> more than a proxy from <insert your favorite mobile network operator>? An

---

From: Jeff Pinner <[email-masked]>
Date: Tue, 25 Feb 2014 18:35:08 -0800

Currently, "http" and "https" conflate the browser security model with the
transport security model. The "https" browser security model might not be
acceptable for certain resources even if the transport security model is
preferable.

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 26 Feb 2014 23:37:24 +1300

> This forbids an http/1 use case and as such is outside the workgroup charter

There is also no sound reason so far presented behind forbidding that
same use-case in HTTP/2. Just a few implementers choosing not to do it
for reasons which have all be countered by other implementers who do.

Also, in my (medium-low) familiarity with such laws TLS or any other
mechanism used to transport packets to the collection point (proxy) is
not relevant to the criterion placed upon the ISP. Only the ability to
accurately and *fully* collect and report is prescribed.
 End-to-end TLS violates that legal requiremet, TLS-to-proxy does not.

Amos

---

From: Peter Lepeska <[email-masked]>
Date: Wed, 26 Feb 2014 08:10:33 -0500

Okay. But currently no "http"-schemed traffic runs over TLS. Do we think
this will account for a significant portion of web traffic in the future?

On Tue, Feb 25, 2014 at 9:35 PM, Jeff Pinner <[email-masked]> wrote:

> On Tue, Feb 25, 2014 at 5:09 PM, Peter Lepeska <[email-masked]>wrote:
>
>> Hi Salvatore,
>>

---

From: Peter Lepeska <[email-masked]>
Date: Wed, 26 Feb 2014 10:25:34 -0500

One question for browser vendors who have said they will not support HTTP2
over plaintext (Firefox, chrome): will you support HTTP2 when http-schemed
URIs are being proxied via a Secure Proxy?

This allows firefox and chrome users to get the performance benefit of
HTTP2 at least across the segment between the ua and the proxy for
http-schemed URLs.

Thanks,

Peter

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 26 Feb 2014 07:55:55 -0800

Chromium indeed supports this today [1][2], and Firefox has indicated plans
for future support, and Patrick seems to have whiteboarded it out [3].

[1]: https://developers.google.com/chrome/mobile/docs/data-compression
[2]: https://sites.google.com/a/chromium.org/dev/spdy/spdy-proxy
[3]: https://plus.google.com/+PatrickMcManusDucksong/posts/SnDYxHQoUiq

On Wed, Feb 26, 2014 at 7:25 AM, Peter Lepeska <[email-masked]> wrote:

> On Wed, Feb 26, 2014 at 5:37 AM, Amos Jeffries <[email-masked]>wrote:
>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 26 Feb 2014 08:04:23 -0800

What Ryan said.

Roland: The "this proxy" that I was referring to above was not the "secure"
proxy proposal, but the part of the proposal that wants to identify TLS
connections carrying http URIs via ALPN for proxies to MITM.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 26 Feb 2014 08:12:57 -0800

That's false, but pretty close to true, so I'll ignore it. In any case, it
depends if opportunistic encryption takes off. I think Patrick was
experimenting on this in collaboration with mnot@. I expect we'll hear an
update in London, and perhaps have some more discussion on the topic.

On Wed, Feb 26, 2014 at 5:10 AM, Peter Lepeska <[email-masked]> wrote:

>> Currently, "http" and "https" conflate the browser security model with
>> the transport security model. The "https" browser security model might not
>> be acceptable for certain resources even if the transport security model is
>> preferable.
>>
>>
>>> As you know, I'm all for new proposals that support both Secure Proxy
>>> and Trusted Proxy. So thanks for writing and posting this. I'm struggling
>>> to understanding how http URIs over TLS work as described in your draft. My
>>> main question is:
>>>

---

From: Peter Lepeska <[email-masked]>
Date: Wed, 26 Feb 2014 11:15:21 -0500

"That's false, but pretty close to true, so I'll ignore it."

Are you referring to the traffic that is HTTP-schemed but connected to a
secure proxy over TLS as per the other thread? Is there any non-proxied
http-schemed traffic running over TLS currently?

Thanks!

Peter

On Wed, Feb 26, 2014 at 11:12 AM, William Chan (陈智昌)
<[email-masked]>wrote:

> On Wed, Feb 26, 2014 at 5:10 AM, Peter Lepeska <[email-masked]>wrote:
>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 26 Feb 2014 08:23:16 -0800

Yes there is. It's pretty negligible though. One example is that Patrick's
been running experiments. There are some older examples with Chromium. I
don't know if there's any actual traffic though:
http://www.stefanwille.com/2013/04/using-spdy-with-nginx-1-4/.

On Wed, Feb 26, 2014 at 8:15 AM, Peter Lepeska <[email-masked]> wrote:

> On Wed, Feb 26, 2014 at 11:12 AM, William Chan (陈智昌) <
> [email-masked]> wrote:
>
>> That's false, but pretty close to true, so I'll ignore it. In any case,
>> it depends if opportunistic encryption takes off. I think Patrick was
>> experimenting on this in collaboration with mnot@. I expect we'll hear
>> an update in London, and perhaps have some more discussion on the topic.
>>
>>
>>> On Tue, Feb 25, 2014 at 9:35 PM, Jeff Pinner <[email-masked]>wrote:
>>>
>>>>> On Tue, Feb 25, 2014 at 10:31 AM, Ryan Hamilton <[email-masked]>wrote:
>>>>>

---

From: Peter Lepeska <[email-masked]>
Date: Wed, 26 Feb 2014 12:04:29 -0500

That's pretty exciting. It's a shame there's not a better proxy discovery
mechanism for plaintext HTTP 1.x traffic (maybe just an additional response
header PROXY-AVAILABLE-AT: https://hostname:port) because it would mean
forward proxies could immediately provide HTTP2 benefits to their users,
without having to wait for content servers to adopt HTTP2 and TLS.

Peter

On Wed, Feb 26, 2014 at 10:55 AM, William Chan (陈智昌)
<[email-masked]>wrote:

> Chromium indeed supports this today [1][2], and Firefox has indicated
> plans for future support, and Patrick seems to have whiteboarded it out [3].
>
> On Wed, Feb 26, 2014 at 7:25 AM, Peter Lepeska <[email-masked]>wrote:
>
>> One question for browser vendors who have said they will not support
>> HTTP2 over plaintext (Firefox, chrome): will you support HTTP2 when
>> http-schemed URIs are being proxied via a Secure Proxy?
>>

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 27 Feb 2014 11:14:11 +1300

> without having to wait for content servers to adopt HTTP2 and TLS.

Which party to the transaction would send that header and how would they 
determine its need to be added?
  * origin server or any reverse-proxy have no idea of forward-proxy 
client-facing capabilities.
  * client is obviously not in-band with the forward-proxy yet.
  * port 80 MITM cannot be trusted that much [1].

There is no 'permanent' version of 305 status code to redirect a client 
to a proxy. But that seems to be what we need. Something like 511 status 
but for proxy detection instead of auth detection.

[1] IIRC one of the reasons for deprecating 305 were attackers utilizing 
305 to redirect port 80 to a local proxy under their control.

Amos

---

From: Peter Lepeska <[email-masked]>
Date: Wed, 26 Feb 2014 17:39:00 -0500

I was assuming the forward proxy was in a position to modify HTTP responses
and so it would add the header. But you are right that it's probably better
to use a 3XX status code for this. But in that case, what if the proxy is
optional and the UA decides it wants to go direct? Or what if the UA
doesn't support the new 3XX status code?

Adding the header to responses just says -- "Hey I'm here and if you want
to go HTTP2 Secure Proxy mode with me feel free". Of course, a proxy could
also require its use by blocking port 80 access.

Peter

On Wed, Feb 26, 2014 at 5:14 PM, Amos Jeffries <[email-masked]> wrote:

> There is no 'permanent' version of 305 status code to redirect a client to
> a proxy. But that seems to be what we need. Something like 511 status but
> for proxy detection instead of auth detection.
>
>
>>> On Wed, Feb 26, 2014 at 7:25 AM, Peter Lepeska <[email-masked]
>>> >wrote:
>>>
>>>> On Wed, Feb 26, 2014 at 5:37 AM, Amos Jeffries <[email-masked]
>>>> >wrote:
>>>>

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 27 Feb 2014 11:50:02 +1300

There is likewise a small but very real amount of https:// schemed 
traffic happening over TCP (non-TLS) ports to proxies. For the cases 
where the proxy is performing the TLS connectivity on behalf of the 
client UA.

Amos

On 2014-02-27 05:23, William Chan wrote:
> On Wed, Feb 26, 2014 at 8:15 AM, Peter Lepeska wrote:
> 
>>>>>>>>> I'm asking this because I think that the purpose of 
>>>>>>>>> standardizing
>>>>>>>>> such
>>>>>>>>> a proposal is for interoperability across vendors, and I don't 
>>>>>>>>> see
>>>>>>>>> the

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 27 Feb 2014 08:17:19 +0000

IMO the HTTP2 spec should contain a definition of "Secure Proxy".

A definition is necessary because at moment we don't have the definition anywhere
while it is something (similar?) to what Chrome already supports and
and there something also on the Firefox roadmap (i.e. Patrick whiteboard)

So what I am asking for is just a definition,
and I guess that it also (please correct me if I have misinterpreted),
in line with William request to standardise the "Secure Proxy" in a separate spec but reference it in the HTTP/2

and it should easily fit in the #413 issue

best regards
Salvatore

On Feb 24, 2014, at 8:35 AM, William Chan (陈智昌) <[email-masked]<mailto:[email-masked]>> wrote:

On Sun, Feb 23, 2014 at 10:31 PM, Mark Nottingham <[email-masked]<mailto:[email-masked]>> wrote:

On 20 Feb 2014, at 11:40 am, William Chan (陈智昌) <[email-masked]<mailto:[email-masked]>> wrote:

Cheers,

---

From: Peter Lepeska <[email-masked]>
Date: Thu, 27 Feb 2014 08:45:30 -0500

While there is not agreement about HTTP2 for HTTP URIs without a proxy, all
may agree that if the browser is talking to a proxy over TLS, then it will
use HTTP2 if the proxy supports it. It would be great for proxies if
browsers could all agree to this. Even better would be if browsers could
agree to an improved discovery mechanism for HTTP URIs.

But in general yes +1 on including "Secure Proxy" in the HTTP2 spec.

Peter

On Thu, Feb 27, 2014 at 3:17 AM, Salvatore Loreto <
[email-masked]> wrote:

> in line with William request to standardise the "Secure Proxy" in a
> separate spec but reference it in the HTTP/2
>
>  On Feb 24, 2014, at 8:35 AM, William Chan (陈智昌) <[email-masked]>
> wrote:
>
> suppose we might need something like RFC2818 for secure proxies, but that
> seems somewhat straightforward, and it might be better for that to happen
> in the TLS WG (indeed, our charter pretty much says so).
>
>
> Note that I've just opened <https://github.com/http2/http2-spec/issues/413>
> to talk about proxies a bit more in general.
>
> Cheers,
>
>
>

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 28 Feb 2014 19:58:25 +1300

> also require its use by blocking port 80 access.

I was trying to point out that is should be a 5xx code for the same
reasons that 511 exists as part of the 401/407/403/511 set.

So that we will have pairs of temporary/permanent redirects for the
302/303 (repeat using GET as method), 301/308 (repeat with same method),
and 305/512 (use proxy) instructions respectively.

Or perhape the see-proxy redirects are both better renumbered as 512/513
so that clients not supporting the status or even simply choosing not to
obey it will display the payload safely as an error page for users about
why their Internet is broken.

Amos

---

From: <[email-masked]>
Date: Fri, 28 Feb 2014 07:23:07 +0000

Hi

+1 for  Salvatore proposal of including “Secure proxy” definition in the core spec.
+1 for peter proposal of including discovery mechanism for HTTP URIs in the core spec too.

Regards
Emile

De : Peter Lepeska [mailto:[email-masked]]
Envoyé : jeudi 27 février 2014 14:46
À : Salvatore Loreto
Cc : William Chan (陈智昌); Mark Nottingham; Paul Hoffman; Patrick McManus; HTTP Working Group
Objet : Re: Secure Proxy definition [was: "Secure" proxies for HTTP URIs]

While there is not agreement about HTTP2 for HTTP URIs without a proxy, all may agree that if the browser is talking to a proxy over TLS, then it will use HTTP2 if the proxy supports it. It would be great for proxies if browsers could all agree to this. Even better would be if browsers could agree to an improved discovery mechanism for HTTP URIs.

Peter

On Thu, Feb 27, 2014 at 3:17 AM, Salvatore Loreto <[email-masked]<mailto:[email-masked]>> wrote:
IMO the HTTP2 spec should contain a definition of "Secure Proxy".

best regards
Salvatore

Cheers,

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "DRUTA, DAN" <[email-masked]>
Date: Fri, 28 Feb 2014 09:52:38 +0000

I also support the inclusion of the “Secure proxy” definition in the core spec. It should establish a common understanding for the generally vague “proxy” term and distinguish it from the misleading “Man In the middle” terminology that is being used in the same context.

Best Regards,
Dan

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, February 27, 2014 11:23 PM
To: Peter Lepeska; Salvatore Loreto
Cc: William Chan (陈智昌); Mark Nottingham; Paul Hoffman; Patrick McManus; HTTP Working Group
Subject: RE: Secure Proxy definition [was: "Secure" proxies for HTTP URIs]

Hi

Regards
Emile

Peter

best regards
Salvatore

Cheers,

Thank you.