W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: New Version Notification for draft-snell-httpbis-keynego-01.txt

From: James M Snell <jasnell@gmail.com>
Date: Tue, 19 Nov 2013 20:47:43 -0800
Message-ID: <CABP7Rbfr+KK_srMTJxdp4Rf4DXZUZpa8PY2EJKV3+bK4Vyp5Ew@mail.gmail.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Cc: Roberto Peon <grmocg@gmail.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Mark Nottingham <mnot@mnot.net>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On Tue, Nov 19, 2013 at 8:39 PM, Ilari Liusvaara
<ilari.liusvaara@elisanet.fi> wrote:
> On Tue, Nov 19, 2013 at 05:52:57PM -0800, James M Snell wrote:
>
>> Also, keep in the mind the CONNECT tunnel option. One could negotiate
>> an agreement and use that along with a CONNECT tunnel. Once that's
>> done, any traffic that passes back and forth within that tunnel would
>> be protected, limiting potential leakage. If we add incremental
>> integrity checking to the picture, this becomes more reliable (albeit
>> more complex as well).
>
> How would that work? CONNECT is essentially TCP stream carried within
> HTTP/2 mux.
>

CONNECT within HTTP/2 consists of a HEADERS frame followed by any
number of DATA frames. If, before sending the CONNECT we negotiate a
key agreement with the authority/origin, every DATA frame in the
CONNECT stream would be encrypted in accordance with the agreement. An
intermediary would be less able to inspect the DATA frame payload to
see what's going on inside.

- James

> -Ilari
Received on Wednesday, 20 November 2013 04:48:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:19 UTC