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

From: James M Snell <[email-masked]>
Date: Tue, 19 Nov 2013 13:13:45 -0800

At Mark's urging, I've posted a significantly updated draft of the
"in-session key negotiation" draft that I had published last year.
Please treat this as purely experimental at this point. I am not
pushing this as a proposal just yet, just offering it up as one
possible approach to providing message-level security as opposed to
transport-level security. What this proposal does, in effect, is make
it possible to negotiate and use cryptographic keys from *inside* an
HTTP/2 connection as opposed to the TLS approach. A key benefit of
this approach is that it allows peers to establish secure
communication even over potentially insecure transports. Of course,
it's not a perfect solution.

As always, feedback is welcomed and requested.

- James

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Tue, Nov 19, 2013 at 1:08 PM
Subject: New Version Notification for draft-snell-httpbis-keynego-01.txt
To: "James M. Snell" <[email-masked]>

A new version of I-D, draft-snell-httpbis-keynego-01.txt
has been successfully submitted by James M Snell and posted to the
IETF repository.

Filename:        draft-snell-httpbis-keynego
Revision:        01
Title:           HTTP/2.0 Intra-Connection Negotiation
Creation date:   2013-11-19
Group:           Individual Submission
Number of pages: 6
URL:
http://www.ietf.org/internet-drafts/draft-snell-httpbis-keynego-01.txt
Status:          http://datatracker.ietf.org/doc/draft-snell-httpbis-keynego
Htmlized:        http://tools.ietf.org/html/draft-snell-httpbis-keynego-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-snell-httpbis-keynego-01

Abstract:
   This memo describes a proposed modification to HTTP/2.0 that
   introduces the concepts of Intra-Connection Negotiation and Secure
   Framing.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 20 Nov 2013 00:41:25 +0200

On Tue, Nov 19, 2013 at 01:13:45PM -0800, James M Snell wrote:
> transport-level security.
> 

First the trivial:

Considering the importance of id header, should it be marked as
HTTP/2 internal header (:id)?

And then what makes me bit nervous:

What about proxy doing things like:
- Changing the protected payload. Including a MAC will prevent this.
- Changing the order or replaying protected payload segments. Adding
  sequence number or nonce to MAC will prevent this.
- Changing the stream of protected payload segments. No idea how to
  protect against this. Stream number would have to be included, but
  server's and client's views differ.

Those may or may not matter, depending on the application.

-Ilari

---

From: Roberto Peon <[email-masked]>
Date: Tue, 19 Nov 2013 14:46:42 -0800

My basic fear here is that, in order to make this work, we will essentially
be required to reinvent much of TLS.
I strongly suspect it would be easier to start with TLS providing only
integrity and go from there.
-=R

---

From: James M Snell <[email-masked]>
Date: Tue, 19 Nov 2013 14:49:17 -0800

> HTTP/2 internal header (:id)?

Possibly yes.

> - Changing the protected payload. Including a MAC will prevent this.

Yep.  I intentionally left this out and define it as a property of the
negotiated agreement. In other words,  I decided to punt on it for now :)

---

From: Roberto Peon <[email-masked]>
Date: Tue, 19 Nov 2013 14:54:16 -0800

The bigger problem is that the proxy might prevent the negotiation from
occurring.
The only way to prevent this downgrade is to always require end-to-end
integrity. Without it, one can make no assertions.
-=R

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 20 Nov 2013 10:50:21 +1100

Thanks, James. A number of people have contacted me privately to express interest in a SHTTP-like approach, so it's good to see proposals written down.

For me, one of the key questions about this general approach is whether the extra information leakage will be acceptable. I.e., an attacker will now know the "shape" of messages -- request and response -- on the wire, including their timing, size, relationships, etc. 

It's easy to imagine a way to characterise interactions with a given Web site and thus be able to correlate the observed messages with certain activities; e.g., "Bob is surfing the login page now, because he sent four requests, one request was significantly larger (due to a payload body on a POST), and the responses were of such-and-such a size." 

Is this significantly worse than HTTPS? AIUI TLS has leakage too, but it doesn't seem like it's as much as this would offer. I'd love to hear the security folks' opinions on that.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: James M Snell <[email-masked]>
Date: Tue, 19 Nov 2013 16:21:14 -0800

This approach definitely leaves room for some additional leakage.
Using the CONNECT tunnel approach described in the draft would address
at least *some* of this but even that is no where near a "complete"
answer".

Agreements negotiated with this model could be defined in such a way
as to introduce obfuscating factors, such as space and time padding,
out-of-sequence frames, etc) but you're absolutely right that there is
an increased risk.

Another potential risk factor is introduced by multiplexing. With
attacks like CRIME, part of the overall attack technique is to send
multiple slightly different requests over time, then statistically
analyzing the results. With TLS, we (at the very least) have the added
"benefit" that establishing each secured connection is relatively
expensive. That cost drops significantly when running over a
multiplexed connection.

- James

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 20 Nov 2013 00:43:52 +0000

In message <[email-masked]>

>The bigger problem is that the proxy might prevent the negotiation from

...In which case it is very likely also blocking any attempt to avoid
using the proxy, so your end-to-end attempt is not going to work either.

Or if it works, it's probably on a trojaned cert.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 20 Nov 2013 00:54:29 +0000

In message <[email-masked]>, Mark Nottingham wri
tes:

>For me, one of the key questions about this general approach is whether 
>the extra information leakage will be acceptable. I.e., an attacker will 
>now know the "shape" of messages -- request and response -- on the wire, 
>including their timing, size, relationships, etc. 

I think those are only relevant concerns in the 'targeted attack'
model, in which case, based on what we have learned, you're likely
totally screwed, even if you use TOR.

I think this is a much better model for HTTP in the long run, since
it opens the door to protected traffic sharing connections with
unprotected traffic, for instance between outgoing proxies and
servers, and it has the potential to only protect the bits which
really matter, at the level of protection they need.

---

From: Roberto Peon <[email-masked]>
Date: Tue, 19 Nov 2013 16:57:14 -0800

The distinct and important difference is that at least one party would be
able to figure out that something odd is happening when integrity is
available, where it is much more difficult when integrity isn't present.
-=R

On Tue, Nov 19, 2013 at 4:43 PM, Poul-Henning Kamp <[email-masked]>wrote:

> In message <
> [email-masked]>
> , Roberto Peon writes:
>

---

From: Roberto Peon <[email-masked]>
Date: Tue, 19 Nov 2013 17:03:35 -0800

I don't buy the argument that you're screwed anyway so don't worry about it.

I do agree that it is sometimes good to allow other entities to route one's
opaque bytestreams-- terminating the transport at various locations within
the path can help reduce the effects of packet loss on lossy segments,
reducing jitter and increasing throughput/goodput. Exposing the
framing/length of things that would be in an encrypted-by-TLS bytestream
today, however, does worry me-- it makes BEAST/CRIME-like attacks
significantly more difficult to protect against.
-=R

---

From: James M Snell <[email-masked]>
Date: Tue, 19 Nov 2013 17:04:42 -0800

You're absolutely right that integrity checking needs to be built into
this.  Exactly how that happens is still up in the air.  A few months ago
at the face to face in SF I mentioned the need for fail fast able
Incremental integrity checking.  I still want that.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 20 Nov 2013 01:23:16 +0000

In message <[email-masked]>
, Roberto Peon writes:

>Exposing the framing/length of things that would be in an
>encrypted-by-TLS bytestream today, however, does worry me-- 
>it makes BEAST/CRIME-like attacks significantly more difficult
>to protect against.

Absolutely.

And there is no doubt either that there is an UI challenge in
communicating the security situation, if the various elements you
see are protected to different levels and degrees.

But there are also many benefits, for instance being able to
run the crypto-handshake in parallel with delivery of the first
unprotected page elements, rather than stall everything until TLS
has gotten its bits sorted out.

---

From: Roberto Peon <[email-masked]>
Date: Tue, 19 Nov 2013 17:33:18 -0800

More of a nightmare than a challenge, but such is UI, and I thank my lucky
stars to not have to deal with it right now!

Being able to run a handshake in parallel with whatever else can only
happen when one doesn't need or want the integrity handshake, which is
necessary for detecting a malicious filtering MITM (and yes one can never
*prevent* such, but detection is quite important).
-=R

On Tue, Nov 19, 2013 at 5:23 PM, Poul-Henning Kamp <[email-masked]>wrote:

> In message <
> [email-masked]>
> , Roberto Peon writes:
>

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 20 Nov 2013 01:35:59 +0000

In message <[email-masked]>

>*prevent* such, but detection is quite important).

My impression of the average site needing protection is that they
send me 100k of graphics to wrap around the two protected entry
fields for "username" and "password".

I dont get the impression that they're particularly worried about
the integrity of the stock-photo of some smiling model or for
that matter the company logo or...

---

From: Roberto Peon <[email-masked]>
Date: Tue, 19 Nov 2013 17:40:03 -0800

I'm not talking about protecting those images-- I'm saying that without
integrity *always*, a MITM can always downgrade anything, and you can't
tell it was done.
-=R

On Tue, Nov 19, 2013 at 5:35 PM, Poul-Henning Kamp <[email-masked]>wrote:

> In message <
> [email-masked]>
> , Roberto Peon writes:
>

---

From: James M Snell <[email-masked]>
Date: Tue, 19 Nov 2013 17:52:57 -0800

> stars to not have to deal with it right now!

That's why I'm definitely *not* a UI developer ;-)

> Being able to run a handshake in parallel with whatever else can only happen
> when one doesn't need or want the integrity handshake, which is necessary
> for detecting a malicious filtering MITM (and yes one can never *prevent*
> such, but detection is quite important).

One of the key design goals for this draft was to allow for
experimentation with a variety of approaches. One could, for instance,
perform an initial "quick" negotiation for integrity to get the ball
rolling, then later on (in parallel to less-important activity)
perform much more expensive negotiation for the more important stuff.
This approach also makes it possible to protect individual streams at
different levels, depending on need and sensitivity. If you wanted to
get fancy, you could even separately protect each direction of a
stream (i.e. each direction using a different negotiated key).

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

The bottom line is that there are a ton of possibilities with this
approach. Unfortunately, there are also likely quite a few drawbacks
and a potentially high amount of additional complexity. If we decide
to trudge down this path, it's going to require a significant amount
of research and verification.

- James

>> In message
>> <[email-masked]>
>> , Roberto Peon writes:
>>

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 20 Nov 2013 06:30:05 +0200

> significantly more difficult to protect against.

You mean BREACH/CRIME (the two attacks exploiting compression), right?
BEAST was bad use of CBC mode and has seemingly nothing to do with
compression.

Also, I don't think even HTTP/2.0 style muxing would help with
adaptive compression attacks (like BREACH and CRIME) unless the
target site is being actively used.

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 20 Nov 2013 06:39:06 +0200

> integrity checking to the picture, this becomes more reliable (albeit

How would that work? CONNECT is essentially TCP stream carried within
HTTP/2 mux.

-Ilari

---

From: James M Snell <[email-masked]>
Date: Tue, 19 Nov 2013 20:47:43 -0800

> How would that work? CONNECT is essentially TCP stream carried within

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

---

From: Roberto Peon <[email-masked]>
Date: Tue, 19 Nov 2013 20:56:35 -0800

Yea, I mean BREACH.
When the framing is in the clear, one cannot hide the fact that one is
adding padding, and/or how much.
Having the bytestream be opaque allows the server/client to add padding and
thus at least linearly increase the amount of effort needed to verify a
hypothesis against a compression context.
-=R

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 20 Nov 2013 07:06:28 +0200

> see what's going on inside.

CONNECT isn't end-to-end.

-Ilari

---

From: James M Snell <[email-masked]>
Date: Tue, 19 Nov 2013 21:14:44 -0800

> 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

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 23 Nov 2013 21:50:04 +0000

So I finally had a chance to read this draft.

I think the ideas are interesting, and it'd be good if HTTP/2.0
was extensible so that future work in this direction could be
explored. Perhaps if the WG do work on supporting proxies, then
room for this as an extension to that could be found.

However, today, this is nowhere near ready to be put up as an
alternative to TLS in any respect. Its not even in the ballpark.

I figure by the time this got properly worked out, (in maybe a
year or more) it'd be very like GSS-API without the API, but
probably as complex. Now that might be interesting actually and
maybe we could do GSS-API context token handling better this
time around. Or maybe we wouldn't.

I'm also quite unsure how the server side of this would work.
With whom would the browser be negotiating? The web server or
some web application? That wasn't clear to me and might make
a big difference in terms of trust models, how the web-origin
plays into the game and in terms of the liklihood of server
side deployment happening.

The "algorithm" header field seems to have the same benefits
and pitfalls as TLS ciphersuites, but goes beyond that to also
codify the handshake protocol and the security framing. I think
I kinda like that, and would go further and let that also
determine if some header-field values are also input to the
security framing. (E.g. the web-origin could be input to any
MAC calculation for some "algorithm" header field values.)
There's fun to be had there.

The security properties of the framing are not even defined yet.
I guess it'd be something like ESP or the TLS application data
protocol, but the algorithm thing above means that those can
vary by algorithm. I'm not sure if that's a good plan since it'd
mean that you have to understand each algorithm to understand
the security properties of payloads. In other words, there could
be value in flexibility in terms of how you negotiate a session
key, but not in the security framing for payloads. One to

Anyway, I do think this might be an interesting near-term
research thing to try play with and if the WG's solution for
better proxy support looked a bit like this, then that would
be good since it'd allow future experimentation along these
lines.

But this just ain't a replacement for TLS.

IMO the WG should do what folks in Vancouver said: get more TLS
used in HTTP/2.0. I'd prefer that be done via the http:// URI
sent on top of opportunistic TLS plan with no new user i/f, but
would also be ok (while a bit skeptical) with the plan Mark
proposed last week to get more server-auth TLS. I do think
either would be better done as an integral part of the spec.

Cheers,
S.

PS: I hope I don't re-ignite the browser/proxy/tls battle
again. Maybe if I say "VP8 or H.264?" that'll distract those
who like such arguments;-)

---

From: James M Snell <[email-masked]>
Date: Mon, 25 Nov 2013 08:12:08 -0800

> So I finally had a chance to read this draft.

Appreciate you taking a look...

> alternative to TLS in any respect. Its not even in the ballpark.

To be certain, providing a replacement for TLS is certainly not the
intent this early in the game. At this point, this is an experiment
only.

> side deployment happening.

The negotiation is with the origin... whatever that means. Typically,
that would imply that it's handled by the web server.

> There's fun to be had there.

Yes, indeed. There are quite a few possibilities. The more exotic we
get, here, however, the more unanswered questions there are. Fun yes,
but could be quite complicated.

> key, but not in the security framing for payloads. One to

The more I look at it, I think I agree. Having a defined structure for
secured DATA frame payloads would be the best approach. The one
drawback is that DATA frames used for HTTP traffic are limited to a
particular size... I want to try avoiding using too much of that up on
security overhead.

- James