W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: explicitly authenticated proxy: new draft

From: Martin Nilsson <nilsson@opera.com>
Date: Sun, 15 Jun 2014 21:47:54 +0200
To: "Salvatore Loreto" <salvatore.loreto@ericsson.com>, "Mark Nottingham" <mnot@mnot.net>
Cc: "<ietf-http-wg@w3.org>" <ietf-http-wg@w3.org>
Message-ID: <op.xhig9407iw9drz@beryllium.bredbandsbolaget.se>
On Fri, 13 Jun 2014 20:12:30 +0200, Mark Nottingham <mnot@mnot.net> wrote:

> Hi Sal,
> Thanks for the update, and sorry for the belated response.
> Easy things first - yes, the draft should be HTTP version-neutral.
> The parts that are specific to TLS and PKI need to be done in the TLS WG  
> (or other appropriate venues); we don’t specify new key usages in this  
> WG (Section 3.1), for example.

I agree that the direction this is taking is more suitable for TLS WG.

> Requiring Forwarded (Section 5) is likely to be controversial, both from  
> the standpoint of making optional features MTI, and privacy. Is that  
> really integral to this proposal?

I think the major thing is to signal that the connection has an  
intermediary. I would probably prefer that the proxy certificate is sent  
to the TLS endpoint so that it is possible to use an authenticated proxy  
for anonymization while not hiding this from the endpoint (unless done so  
explicitly by withholding it). I don't think it is specified what happens  
if the client sends a certificate unrequested though. But that is a TLS  

> What’s left is (mostly) the “h2c” protocol identifier; however, that  
> identifier is already defined by the WG to mean “HTTP/2 over cleartext”  
> <http://http2.github.io/http2-spec/#versioning>. In light of that, what  
> would you like to see? This came up in a couple of reviews, but I  
> haven’t seen an answer yet.

Continuing guessing the rationales behind the draft, I think "h2c" was  
used because the intent in ALPN as in alt-svc is the same: HTTP/2 without  
security. But we agree that a version neutral approach is better, and that  
would probably need another TLS extension.

> However, the bigger issue is getting implementation; AIUI Opera Turbo is  
> *not* HTTP; it’s a proprietary protocol with HTTP semantics, and  
> therefore out-of-scope for this WG.

True, but I would like to push it towards HTTP/2 with extensions so that  
it, if possible, is completely standards compliant. I know of about five  
different similar protocols in active use, so defining the framework they  
live in is of value. Possibly not (only) in this WG though.

/Martin Nilsson

Using Opera's mail client: http://www.opera.com/mail/
Received on Sunday, 15 June 2014 19:48:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC