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

Re: new version trusted-proxy20 draft

From: Thomas Fossati <TFossati@velocix.com>
Date: Sun, 16 Feb 2014 21:50:28 +0000
To: Patrick McManus <pmcmanus@mozilla.com>, Salvatore Loreto <salvatore.loreto@ericsson.com>
CC: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <DA86AAEF6E448540808AFA696EA47E5A71FE371C@EXB01-MLT.corp.velocix.com>
On 14/02/2014 22:42, "Patrick McManus" <pmcmanus@mozilla.com<mailto:pmcmanus@mozilla.com>> wrote:
On Fri, Feb 14, 2014 at 1:56 PM, Salvatore Loreto <salvatore.loreto@ericsson.com<mailto:salvatore.loreto@ericsson.com>> wrote:

  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

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

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

Received on Sunday, 16 February 2014 21:51:02 UTC

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