RE: Secure Proxy definition [was: "Secure" proxies for HTTP URIs]

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: emile.stephan@orange.com [mailto:emile.stephan@orange.com]
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

+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:bizzbyster@gmail.com]
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.

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 <salvatore.loreto@ericsson.com<mailto:salvatore.loreto@ericsson.com>> wrote:
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 (陈智昌) <willchan@chromium.org<mailto:willchan@chromium.org>> wrote:

On Sun, Feb 23, 2014 at 10:31 PM, Mark Nottingham <mnot@mnot.net<mailto:mnot@mnot.net>> wrote:

On 20 Feb 2014, at 11:40 am, William Chan (陈智昌) <willchan@chromium.org<mailto:willchan@chromium.org>> 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).

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


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

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.