Subject: explicitly authenticated proxy: new draft

From: Salvatore Loreto <[email-masked]>
Date: Mon, 5 May 2014 06:49:34 +0000

we have produced a new draft that proposes the definition of an Explicitly Authenticated
Proxy as intermediary of normally unprotected "http://" URI scheme requests and responses of HTTP2 traffic.

The Explicitly Authenticated Proxy is defined as a message forwarding agent that  is selected, with explicit user's consent, 
and configured by the user agent to receive exclusively "http" URI scheme requests and attempt 
to satisfy those requests on behalf of the user agent.  
A client is connected to an Explicitly Authenticated Proxy through an authenticated TLS secured connection.

The document describes also a method for a user agent to automatically discover and authenticate, 
and for an user to provide consent for an Explicitly Authenticated Proxy. 
This enables proxies communication to be encrypted and authenticated, explicitly acknowledged by the
user agent and visible to the server end point.

URL:            http://www.ietf.org/internet-drafts/draft-loreto-httpbis-explicitly-auth-proxy-00.txt
Status:         https://datatracker.ietf.org/doc/draft-loreto-httpbis-explicitly-auth-proxy/
Htmlized:       http://tools.ietf.org/html/draft-loreto-httpbis-explicitly-auth-proxy-00

comments, suggestions and feedback are welcome

br
Salvatore

---

From: "Richard Wheeldon (rwheeldo)" <[email-masked]>
Date: Mon, 26 May 2014 03:21:25 +0000

Sorry for taking so long to get round to this. I've finally read through it. Whilst I fully appreciate the effort in trying to address the proxy cases, I'm a little bit concerned that by limiting it in scope to HTTP-only URLs we're still leaving the elephant in the room of organization-based HTTPS Inspection == MITM attack largely unaddressed. Also, I'd like to see an alteration such that either end-point could accept or reject connections based on TLS properties of the other - which is currently (and still in your draft) impossible. However, addressing these might put this in the scope of the TLS WG rather than the HTTP one but that's not my call to make.

It's a bit of a minor point, but I also find the use of "h2c" in a TLS negotiation ugly. Assuming that the c in h2c implies clear text, using it for an encrypted channel seems to be asking for confusion,

Richard

-----Original Message-----
From: Salvatore Loreto [mailto:[email-masked]] 
Sent: 05 May 2014 07:50
To: [email-masked]
Subject: explicitly authenticated proxy: new draft

we have produced a new draft that proposes the definition of an Explicitly Authenticated Proxy as intermediary of normally unprotected "http://" URI scheme requests and responses of HTTP2 traffic.

The Explicitly Authenticated Proxy is defined as a message forwarding agent that  is selected, with explicit user's consent, and configured by the user agent to receive exclusively "http" URI scheme requests and attempt to satisfy those requests on behalf of the user agent.  
A client is connected to an Explicitly Authenticated Proxy through an authenticated TLS secured connection.

The document describes also a method for a user agent to automatically discover and authenticate, and for an user to provide consent for an Explicitly Authenticated Proxy. 
This enables proxies communication to be encrypted and authenticated, explicitly acknowledged by the user agent and visible to the server end point.

br
Salvatore

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 26 May 2014 10:41:32 +0000

Hi Richard

thanks for reading the draft and providing your comments

On May 26, 2014, at 6:21 AM, Richard Wheeldon (rwheeldo) <[email-masked]> wrote:

> Sorry for taking so long to get round to this. I've finally read through it. Whilst I fully appreciate the effort in trying to address the proxy cases, I'm a little bit concerned that by limiting it in scope to HTTP-only URLs we're still leaving the elephant in the room of organization-based HTTPS Inspection == MITM attack largely unaddressed.

that has been intentionally left out, as it is a subject that touch several protocols not only HTTP
and would require at least IMO some not trivial changes in the Web Architecture as well as in the
https:// URI semantic

> Also, I'd like to see an alteration such that either end-point could accept or reject connections based on TLS properties of the other - which is currently (and still in your draft) impossible.

While I understand the importance of involving both the ends in the scenario like the organisation-based HTTPS Inspection
you have in mind,

I do not think it is necessary in the scenario where the http:// URI traffic is transported over TLS, for several reasons.
The first one is that the http:// URI semantic does not mandate end-to-end security/privacy/confidentiality 
so if a WebSite decide to distribute a resource as http:// it implicitly provides consent for that resource to pass true
intermediaries and eventually to be cached 

> However, addressing these might put this in the scope of the TLS WG rather than the HTTP one but that's not my call to make.

> It's a bit of a minor point, but I also find the use of "h2c" in a TLS negotiation ugly. Assuming that the c in h2c implies clear text, using it for an encrypted channel seems to be asking for conf…

my reading is that h2c implies transport of http:// uri traffic that is a slightly different interpretation.
However I am fully aware that different people have different opinion and that the Opportunistic Encryption proposal suggest to use h2
for http:// uri traffic transported over opportunistic unauthenticated TLS

br
Salvatore

---

From: "Martin Nilsson" <[email-masked]>
Date: Tue, 27 May 2014 01:46:41 +0200

On Mon, 26 May 2014 05:21:25 +0200, Richard Wheeldon (rwheeldo)  
<[email-masked]> wrote:

> It's a bit of a minor point, but I also find the use of "h2c" in a TLS  
> negotiation ugly. Assuming that the c in h2c implies clear text, using  
> it for an encrypted channel seems to be asking for confusion,

I was confused about that as well, but I guess the counter argument is  
that why would you use different identifiers for http-URL-originating  
http/2 traffic for different transports?

/Martin Nilsson

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/