Subject: Call for Adoption: draft-hutton-httpbis-connect-protocol-00

From: Mark Nottingham <[email-masked]>
Date: Tue, 29 Jul 2014 16:38:15 +1000

<http://tools.ietf.org/html/draft-hutton-httpbis-connect-protocol-00>

In Toronto, we had a discussion about adopting this document as a WG document:
  <https://github.com/httpwg/wg-materials/blob/gh-pages/ietf90/minutes.md#draft-hutton-httpbis-connect-protocol>

One concern raised there was regarding the model for the extension; i.e., by effectively making support for webrtc (or any other protocol) on proxy opt-in rather than opt-out, it may cause problems as more traffic goes over proxies. However, the HTTP folks in the room didn't seem to concerned about this, since bad actors were already able to (ab)use CONNECT tunnels with impunity (effectively.

Another concern briefly mentioned was that such an extension might inhibit protocol evolution; e.g., if a firewall whitelists what tunnelled protocols it accepts, it might be that we're stuck advertising "h2" in the future. However, there didn't seem to be strong concern here, since ALPN negotiation is a separate step, and HTTP can choose to omit this header when using CONNECT for its own purposes.

With that context in place, it seemed like there was general support in the room for adopting this spec. Does anyone else have additional thoughts / concerns? 

Regards,

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

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 29 Jul 2014 23:13:45 +1200

> With that context in place, it seemed like there was general support in the room for adopting this spec. Does anyone else have additional thoughts / concerns? 

I would also like to express interest and support for this.

We already have several outstanding requests from the Squid community
for features and protocol access controls this signal will enable.

Amos

---

From: Martin Thomson <[email-masked]>
Date: Tue, 29 Jul 2014 09:29:47 -0700

> Another concern briefly mentioned was that such an extension might inhibit protocol evolution; e.g., if a firewall whitelists what tunnelled protocols it accepts, it might be that we're stuck adver…

I'll note that the header field only brings the information forward.
A proxy that permits an unlabelled CONNECT can (maybe) examine the TLS
ClientHello to see what protocols are being offered.  That is, if TLS
is involved at all; though other protocols could have similarly
distinctive fingerprints.

Omitting the header field will, at least in the short term, avoid any
whitelisting issues.  However, if we start using this for "h2", then
we could end up with omission being risky.  My crystal ball tells me
that this is unlikely on any relevant timescale :)