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

From: Paul Hoffman <[email-masked]>
Date: Tue, 3 Dec 2013 07:24:44 -0800

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 3 Dec 2013 09:11:20 -0800

On 3 December 2013 07:24, Paul Hoffman <[email-masked]> wrote:
> draft-hoffman-httpbis-minimal-unauth-enc

I have a lot of questions, but here's a few to start with:

Why headers and not frames?

Why did you choose to submit a draft that doesn't tackle the key
question of what is being encrypted?

Why did you choose to invent a new security protocol and not repurpose
something like DTLS?

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 3 Dec 2013 09:32:37 -0800

> Why headers and not frames?

- Could be headers or frames, as long as it is some place that is in the
control plane. That's for the grizzled HTTP/2 experts (as in, not me) to
pick.

> question of what is being encrypted?

Because the goal is to "encrypt more", and there is disagreement about what
"more" means. The WG seemed more wedged on how to encrypt than what to
encrypt. I trust the WG to resolve the latter if they figure out the former.

> Why did you choose to invent a new security protocol and not repurpose

DTLS assumes a transport layer after the negotiation is done. DTLS takes
many more round trips. DTLS has the concept of authenticating the server
mostly built-in. If the WG wants DTLS, I would strongly suggest using TLS
instead.

And, this isn't inventing a new protocol: it is instantiating what is known
to be the minimum needed to get an encryption key. "Here is some key
material and a description of it; yes, that's fine, and here we go" or
"Here is some key material and a description of it; no, I'd rather use this
algorithm so here is my initial keying material; yes, that's fine, and here
we go" plus rejection messages. This is sufficient for borking passive
surveillance but not active attacks.

--Paul Hoffman

---

From: Martin Thomson <[email-masked]>
Date: Tue, 3 Dec 2013 09:44:46 -0800

> encrypt. I trust the WG to resolve the latter if they figure out the former.

You are far more trusting than I :)

The reason I asked this question was not because I wanted you to stick
your neck out that much further.  I really wanted to get some of the
more difficult questions answered with respect to how the keying
material was applied.  Sequence numbers, IVs, all that sort of muck.
Maybe that's just an inherent aversion to hand-waving over the
details.

> mostly built-in. If the WG wants DTLS, I would strongly suggest using TLS

Yes, that's the unasked question.  What's wrong with TLS exactly?

> to be the minimum needed to get an encryption key.

You seem to have a very different definition of "protocol" and "new"
to me.  Not important.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 3 Dec 2013 10:25:29 -0800

On Tue, Dec 3, 2013 at 9:44 AM, Martin Thomson <[email-masked]>wrote:

> material was applied.

Once the parties have an agreed-to encryption algorithm and shared secret
keys, there details of how to apply them are fairly trivial. Documents
about how to do this for S/MIME, TLS, and IPsec are usually about two pages
of real material and then a bunch of fluff. The fact that MUE will re-use
known encryption algorithms (like AES-GCM) should make such documents
trivially short.

> Sequence numbers, IVs, all that sort of muck.

They are details that need to be worked out, but not until the WG decides
if it likes the advantages of MUE more than the advantages of
upgrade-to-TLS. That decision should absolutely be based on "which style
makes more sense", not "which early proposal had more details".

> Yes, that's the unasked question.  What's wrong with TLS exactly?

I was about to say "it's in the document" and now see that the
Markdown-to-XML converter ate that. <sigh>. Please see Section 6 in the -01
draft (
http://tools.ietf.org/html/draft-hoffman-httpbis-minimal-unauth-enc-01)
just published for a recap of the pros and cons of what people have said on
the list.

--Paul Hoffman

---

From: James M Snell <[email-masked]>
Date: Tue, 3 Dec 2013 10:57:41 -0800

Great to see this. I'm fairly tied up currently but definitely want to
look at this in comparison to my intra-connection negotiation draft.
Perhaps these can be brought together into a single proposal. I'll see
about getting some feedback later this week.

On Tue, Dec 3, 2013 at 7:24 AM, Paul Hoffman <[email-masked]> wrote:
> 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

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 3 Dec 2013 21:24:16 +0200

> encrypt. I trust the WG to resolve the latter if they figure out the former.

Just encrypting the complete frames and appending tags doesn't work. For two
reasons:
1) For some AEAD modes, decrypting the start of frame without knowing length might
not be possible (albeit it seems to be possible for most common ones, like GCM
and EAX, and maybe also OCB).
2) Pretty much no crypto library implements unauhenticated partial decryption of
AEAD schemes.

Also, that kind of thing would be really trivial in AtE- (or E&A)-type authenticated
encryption, but unfortunately crypto people tend to really hate AtE/E&A (mostly
because padding often gets screwed up, resulting all sorts of vulernabilities[1]).

So in practice, one would have to have duplicate length values in the clear (or
swap order of some header fields and have the length in clear in front, as I
would dislike to have frame type in the clear)...

As for IVs, for most schemes that aren't flaky for other reasons (e.g. CBC-based
ones are flaky), one can just use incrementing nonces. For CBC, I don't even
pretend to understand what it takes to use it securely[2]...

Also, for switching modes, maybe a new frame type to signal key switch (a'la TLS)?
That wouldn't add any latency, because it always can be bundled with pre-existing
flight.

[1] TLS has had padding oracles and Lucky13. Both from padding done in a bad
way.

[2] TLS has had BEAST there (from messed up CBC mode in TLS 1.0).

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Tue, 3 Dec 2013 11:59:50 -0800

> 2) Pretty much no crypto library implements unauhenticated partial decryption of

That's a strong assertion, and I think wrong.  See the TLS 1.2 AEAD
modes.  The authenticated data includes length and some other things,
values that appear unencrypted.

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 3 Dec 2013 23:18:52 +0200

> values that appear unencrypted.

I mean encrypting the length (like SSH does with most ciphers, AES-GCM being
the notable exception).

-Ilari

---

From: James M Snell <[email-masked]>
Date: Tue, 3 Dec 2013 20:03:50 -0800

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

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 3 Dec 2013 20:18:42 -0800

> need to be addressed at some point.

Yes.

> 2. Who exactly is S1?

S1 is not a "who", it is a message. C1 is the first message from the client
to the server, S1 is the first message from the server to the client.

> What is the relationship between S1 and Origin?
> How does C1 know who it is communicating with?

C1 doesn't: that's the whole point of "unauthenticated". If I can make that
any more clear in the document, please let me know how.

> Is the negotiation
> hop-by-hop or end-to-end?

It is for a single HTTP/2 connection between a client and a server.

> Can there be multiple keys derived and used

The current draft assumes a single set of keys. There is no need for more
if the purpose is to thwart surveillance. Having multiple keys possible
seems like a feature without a problem behind it.

--Paul Hoffman

---

From: James M Snell <[email-masked]>
Date: Tue, 3 Dec 2013 20:34:01 -0800

> to the server, S1 is the first message from the server to the client.

Sorry I wasn't clear, I mean who exactly is sending S1... see below.

> any more clear in the document, please let me know how.

Yes, the unauthenticated part is quite clear... I just think it's
going to be a problem... particularly if the intent really is to
"thwart surveillance" as you suggest. At the very least I think
authenticating the origin is going to be necessary.

> The current draft assumes a single set of keys. There is no need for more if
> the purpose is to thwart surveillance. Having multiple keys possible seems
> like a feature without a problem behind it.
>

Well, the use-cases I'm exploring at this point at largely
experimental and are geared more towards the fact that a single http/2
connection could carry traffic bound to multiple origin domains. In
other words, the problem exists in a very narrow subset of cases and
it's not yet clear if those are going to be interesting enough to
pursue, but they are worth chasing down nonetheless.

- James

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 4 Dec 2013 09:12:15 -0800

Just to be clear, this draft is aimed at the use case that the WG seems to
be interested in (thwarting passive surveillance), not the one you seem to
be wanting it to point to. If you want to pursue yours, that's fine I
guess, but please don't disparage mine for meeting what seems to be the one
the WG wants.

---

From: James M Snell <[email-masked]>
Date: Wed, 4 Dec 2013 09:22:26 -0800

If you don't care about my particular use cases, that is fine, but
please understand that any criticism is meant to be constructive. I
firmly believe that we cannot adequately address the passive
surveillance issue using this form of unauthenticated encryption. I'm
all for experimentation in this area and throwing around new ideas,
but I'm definitely not convinced that your draft meets the mark as it
currently sits.

On Wed, Dec 4, 2013 at 9:12 AM, Paul Hoffman <[email-masked]> wrote:
> be wanting it to point to. If you want to pursue yours, that's fine I guess,
> but please don't disparage mine for meeting what seems to be the one the WG
> wants.
>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 4 Dec 2013 09:56:26 -0800

On Wed, Dec 4, 2013 at 9:22 AM, James M Snell <[email-masked]> wrote:

> I
> surveillance issue using this form of unauthenticated encryption.

Please say more about this firm belief. This affects both Mark's
redirection proposal and mine. I have never heard how unauthenticated
encryption can be broken by a passive watcher, but if you have references
to such attacks, they would be very useful here.