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

On Tue, Nov 19, 2013 at 9:06 PM, Ilari Liusvaara
<> wrote:
> On Tue, Nov 19, 2013 at 08:47:43PM -0800, James M Snell wrote:
>> On Tue, Nov 19, 2013 at 8:39 PM, Ilari Liusvaara
>> <> wrote:
>> >
>> > 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.
> CONNECT isn't end-to-end.

The CONNECT method itself is not, but the payload of the DATA frames
in a CONNECT stream are. Specifically,

   The payload of any DATA frames sent by
   the client are transmitted by the proxy to
   the TCP server; data received from the TCP
   server  is assembled into DATA frames by
   the proxy.

So the client would encrypt that data and pass it along via the
intermediary, which would just see an opaque blob of bytes. All that's
required is some way of indicating which negotiated key is being used
(thus the reason I have the first four bytes of every data frame
payload specify the key identifier). And yes, I'm fully aware that
there are still unanswered questions that would need to be worked out.
Like I said from the beginning, this is an *experimental* idea :-) I'm
no where near close to having this thing proven

- James

> -Ilari

Received on Wednesday, 20 November 2013 05:15:34 UTC