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

Re: Proposal for doing unauthenticated encryption inside of HTTP/2

From: James M Snell <jasnell@gmail.com>
Date: Tue, 3 Dec 2013 20:03:50 -0800
Message-ID: <CABP7RbfQZMMV9QP12fU+Nd-tuRjeirCtrah_oAzy1uSvGfbpEg@mail.gmail.com>
To: Paul Hoffman <paul.hoffman@gmail.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Ok, now that I've had a chance to digest this, a few comments...
(setting aside the "just use TLS" argument).. Many of these are
obvious questions given the currently incomplete state of the draft
(I'm quite sure you're aware of the questions and may have answers in
mind already..)

1. So far this appears only to sketch out a rough key derivation
strategy... it doesn't really say, however, *what* parts of the
message are being encrypted. DATA frame payloads only? HEADERS frame
payloads? What about PUSH_PROMISE? Extension frames? These will all
need to be addressed at some point.

2. Who exactly is S1? What is the relationship between S1 and Origin?
How does C1 know who it is communicating with? Is the negotiation
hop-by-hop or end-to-end? Can there be multiple keys derived and used
within a single HTTP/2 connection?

3. Taking an initial stab at combining the ideas you describe with my
Intra-Connection Negotiation draft... we could easily perform your
negotiation protocol using my proposed NEGOTIATE pseudo-method,
allowing the requesting agent to negotiate a key with a specific
origin... Specifically:

  Client sends:

    HEADERS
      END_MESSAGE (flag 0x2)
      :method = NEGOTIATE
      :authority = example.org
      :id = 1
      :algorithm = mue
      {clients-initial-key-material, nonce, etc as header fields}

  Server responds with:

    HEADERS
      END_STREAM (flag 0x1)
      END_MESSAGE (flag 0x2)
      :status = 200
      :id = 1
      {server-key-material.. section 2.3.1 of your draft.. as header fields}

  Client sends empty DATA frame with END_STREAM (essentially ack'ing
the server response and closing the negotiation successfully)

This process would bind agreement #1 to the origin example.org and the
negotiated key. The derivation would occur exactly as you describe.
Once the agreement is established, the client and origin can use that
to encrypt the flow. (And yes, like you, I'm leaving that specific
detail undefined at the moment).

I can play around with this more. Still definitely not all that
satisfied with the approach yet but this, at the very least, gives us
something to play around with.

- James


On Tue, Dec 3, 2013 at 7:24 AM, Paul Hoffman <paul.hoffman@gmail.com> wrote:
> Greetings again. The WG's discussion of how to get authentication in HTTP/2
> for http: URLs has gone in two general directions:
>
>   - Include HTTP/2 headers that will indicate an upgrade path that uses TLS
>
>   - Do unauthenticated encryption within HTTP/2
>
> I have just posted draft-hoffman-httpbis-minimal-unauth-enc-00 to help spur
> ideas about the second option. It has some advantages and disadvantages when
> compared to the first option, and hopefully this lets the WG get more
> clarity as to which might be a more preferable mechanism to work on. (There
> is still another option, to define HTTP/2 only for https: URLs, but that is
> an orthogonal discussion.)
>
> --Paul Hoffman
Received on Wednesday, 4 December 2013 04:04:37 UTC

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