Subject: PRISM and HTTP/2.0

From: Poul-Henning Kamp <[email-masked]>
Date: Sat, 13 Jul 2013 10:08:05 +0000

I would like to advocate that everybody spends a little bit of time
reconsidering how we design protocols after the PRISM disclosures.

We don't need to have a long discussion about the actual legality
of the US spy operation, the sheer scale and the kind of efforts
that went in to it is the relevant message to us.

The take-home message is that encryption will be broken, disabled,
circumvented og watered down, if it gets in the way of political
objectives.

We can do three things in light of this:

1) We can try to add more encryption to fight back.

2) We can recognize that there needs to be hooks for duly authorized access.

3) We can change or at least influence the political objectives

I think PRISM is ample evidence that #1 will have the 100% certain
result is that all encryption will be circumvented, with bogus CA
certs all the way up to PRISM and designed-in backdoors, and the
net result is less or even no privacy for anybody everywhere.

In my view, that would be very counterproductive.

#2 is not without challenges, but at least there are plausible paths
from there to a state of affairs where innocent people might still
have access to private communications, and it might seem to be a
necessary precondition for any hope on #3

#3 is clearly not inside HTTPbis scope, but it may be time for
all good nerds to come to the aid of their country and humanity.

A "market based" argument can be made under #3, that if we design
protocols with the necessary access (#2), programs like PRISM will
not be cost effective, but that will take some serious effort
of education and politics.

Anyway:  Edward Snowden has moved the rug under the HTTP/2.0
standardization process, and we should not ignore that.

Think about it.

-- 
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: Stephen Farrell <[email-masked]>
Date: Sat, 13 Jul 2013 11:47:25 +0100

> 1) We can try to add more encryption to fight back.

Sounds good. We probably need better implementation and more deployment as well.

> 2) We can recognize that there needs to be hooks for duly authorized access.

That's not for this WG IMO. RFC 2804 is a BCP that says that.

> 3) We can change or at least influence the political objectives

Not for the IETF IMO.

S

---

From: Mike Belshe <[email-masked]>
Date: Sat, 13 Jul 2013 11:43:26 -0700

Or we can put up an anonymous auction to all governments, and let the
highest bidder win the keys to HTTP/2.0.

Mike

---

From: J Ross Nicoll <[email-masked]>
Date: Sat, 13 Jul 2013 23:41:51 +0100

With regards to #1, I'm not sure the concept of "more encryption" is 
really what's meant here. Minimum key lengths could be increased, 
perhaps different encryption methods merged such that if one approach is 
broken then the message is still secure... however I think we can fairly 
realistically assume no-one's going to try tackling the encryption 
itself head-on.

Bogus certificates and server-side backdoors seem inevitable, at least 
in the current political climate. I don't think any realistic changes at 
the transport layer will affect that (unrealistic changes would include 
"move to a web of trust"). Equally I don't think there's any need for 
changes to enable access; they're doing that just fine without us, and 
inevitably any such hooks are weaknesses that can potentially be 
exploited by an attacker.

About the only changes I could suggest from a technical point of view 
would be user-interface related. Indicate when a server certificate 
changes, for example, especially if the previous certificate's expiry 
wasn't due for a while. The same sort of defences that are relevant 
against phishing attacks, are useful for evading other forms of site 
impersonation.

I think this is a discussion worth having, because even "There is 
nothing to be changed" is a concrete conclusion to come to, but that may 
be the answer here.

Ross

---

From: Roberto Peon <[email-masked]>
Date: Sat, 13 Jul 2013 17:16:50 -0700

I have a difficult time believing that any solution, short of new
physics-based technologies, will overcome the tradition of users'
ambivalence when faced with any obstacle to convenience.
-=R

On Sat, Jul 13, 2013 at 3:41 PM, J Ross Nicoll <[email-masked]> wrote:

> really what's meant here. Minimum key lengths could be increased, perhaps
> different encryption methods merged such that if one approach is broken
> then the message is still secure... however I think we can fairly
> realistically assume no-one's going to try tackling the encryption itself
> head-on.
>
> Bogus certificates and server-side backdoors seem inevitable, at least in
> the current political climate. I don't think any realistic changes at the
> transport layer will affect that (unrealistic changes would include "move
> to a web of trust"). Equally I don't think there's any need for changes to
> enable access; they're doing that just fine without us, and inevitably any
> such hooks are weaknesses that can potentially be exploited by an attacker.
>
> wasn't due for a while. The same sort of defences that are relevant against
> phishing attacks, are useful for evading other forms of site impersonation.
>
> I think this is a discussion worth having, because even "There is nothing
> to be changed" is a concrete conclusion to come to, but that may be the
> answer here.
>
> Ross
>
>

---

From: Nicolas Mailhot <[email-masked]>
Date: Sun, 14 Jul 2013 12:19:44 +0000 (UTC)

> 3) We can change or at least influence the political objectives

4. We can fix intermediary set up in the protocol so it's not a PITA to add
 a protection middleman to the mix (privacy proxy, TOR proxy, audit proxy).

Right now a lot of services are moving to cloud farms controlled by a
handful of PRISM-happy US firms. The same handful also controls pretty much
all the major browsers (Firefox excepted, maybe). Someone wrote on this list
a few months ago the protocol should help server-point vet intermediaries.
This is totally insane. You can't have the whole HTTP value chain under NSA
control. And while expecting everyone that does not trust the NSA to come up
with its own browser is pretty irrealistic nowadays, writing a proxy
babysitter that checks the browser is not completely compromised is way more
accessible.

This does not change hostile intermediary situation one bit, since they're
already doing interception now. The only people harmed are the white hats.

-- 
Nicolas Mailhot

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 15 Jul 2013 08:14:34 +1000

Absolutely. However, I do think that the user should be in a place where they have enough information to make an informed decision about the security of their communication should they want to.

That means that we need to raise the game regarding TLS MITM (which several groups have been working on for some time) as well as making TLS easier to deploy well (which is also being worked upon AIUI). That's all out-of-scope here, unless we want to mandate use of some particular approach with HTTP/2.

TLS itself is out of our hands; if we want to recommend increased key lengths, etc., we should ask the TLS WG to produce a profile of the protocol that we can point to.

The UI stuff is hard. Yes, 99.x% of users will click through, but that doesn't mean that we shouldn't tell them. It'd be a good start if we could reduce the number of false positives in those dialogues (e.g. self-signed certs; they're easy to deploy and train users to ignore security dialogues; a bad mix). However, we don't do UI here (he says gratefully); the best venues for that are probably the WHAT WG and the W3C Web Application Security WG. 

What *is* in scope here -- barring doing something big like encrypting HTTP/2 per frame -- is sorting out the mess of intermediary configuration. As I said when we started, if people expect HTTP/2 to be used over TLS more (or HTTP/1, for that matter), we'd better have a more reasonable, interoperable way for networks to tell clients to use a proxy.

I have no problem using HTTP/2 as a way to drive these discussions and consolidate the efforts by requiring particular things to be done when you use the protocol. However, we can't fix the whole world here; we need to stay focused.

Cheers,

On 14/07/2013, at 10:16 AM, Roberto Peon <[email-masked]> wrote:

> I have a difficult time believing that any solution, short of new physics-based technologies, will overcome the tradition of users' ambivalence when faced with any obstacle to convenience.
> -=R
> 
> 
> With regards to #1, I'm not sure the concept of "more encryption" is really what's meant here. Minimum key lengths could be increased, perhaps different encryption methods merged such that if one approach is broken then the message is still secure... however I think we can fairly realistically assume no-one's going to try tackling the encryption itself head-on.
> 
> Bogus certificates and server-side backdoors seem inevitable, at least in the current political climate. I don't think any realistic changes at the transport layer will affect that (unrealistic changes would include "move to a web of trust"). Equally I don't think there's any need for changes to enable access; they're doing that just fine without us, and inevitably any such hooks are weaknesses that can potentially be exploited by an attacker.
> 
> About the only changes I could suggest from a technical point of view would be user-interface related. Indicate when a server certificate changes, for example, especially if the previous certificate's expiry wasn't due for a while. The same sort of defences that are relevant against phishing attacks, are useful for evading other forms of site impersonation.
> 
> I think this is a discussion worth having, because even "There is nothing to be changed" is a concrete conclusion to come to, but that may be the answer here.
> 
> Ross
> 
> 

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

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 14 Jul 2013 23:00:38 +0000

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

>I have no problem using HTTP/2 as a way to drive these discussions and 
>consolidate the efforts by requiring particular things to be done when 
>you use the protocol. However, we can't fix the whole world here; we 
>need to stay focused.

Indeed we can not, but I think the shift in security perceptions
PRISM have caused needs to inform us nontheless.

For instance, it is now naive to assume that the only encryption
which will ever be used around HTTP/2.0 is going to be SSL/TLS.

We have thankfully settled that HTTP/2.0 can be moved on any
transparent byte-pipe.

But maybe it would be a good idea to also expressly tag the frames
which needs cryptographic protection (object bodies) and which does
not (house keeping, routing envelopes, headers), in order to enable
future encryption schemes which are not stream, but message based ?

It would be sad to spend this much effort to build the last tea-clipper.

---

From: Reto Bachmann-Gmür <[email-masked]>
Date: Mon, 15 Jul 2013 18:19:23 +0200

On Sun, Jul 14, 2013 at 12:41 AM, J Ross Nicoll <[email-masked]> wrote:
> transport layer will affect that (unrealistic changes would include "move to
> a web of trust").

Not sure if it would be within the possibilities of this WG to define
an optional public key hash in HTTP URIs. If a link contains such a
hash of the public key of the target this would protect against
attacks from a root-certificate holding man in the middle. It wouldn't
be a full move to a web of trust nor a replacement of the uri-scheme
as with the httpsy proposal just an optional additional security that
works alongside as well as without the PKI provided trust.

Cheers,
Reto

---

From: Nico Williams <[email-masked]>
Date: Mon, 15 Jul 2013 12:56:17 -0500

> 2) We can recognize that there needs to be hooks for duly authorized access.

We can't assume that this is either desired by any authorities
(they'll demand we do this if they want it, and they'll delay asking
for as long as possible as it'd be a big deal to ask for it) nor
necessarily useful for #3.

The fact is that for now we're at the mercy of a) those authorities
who have deployed PRISMs, b) anybody who compromises them.  (b) is the
reason that PRISMs should not be built [0], but the same logic that
led all major WWII powers to have nuclear weapons programs during the
war must lead to all sufficiently rich governments to seek to build
PRISMs.  As with nuclear weapons, we may well end up with stalemate
(see commentary on #3 below).

The only escape would be strong end-points, which then would
facilitate end-to-end security.  But that's a pipe dream, for several
reasons: i) some end-points with useful plaintext data will be
physically vulnerable to PRISMs, so the end-points in question have to
all be personal, rather than servers in data centers, ii) to get to
where we have strong personal end-points would require powerful market
forces (and time), but we see the market bent and made to serve its
masters (albeit never perfectly, as politics cannot change natural
law) the world over, which leads to the only, inescapable conclusion:
this is a political problem.

"#2 to get #3" is a political proposal.  It is to build something
expressly susceptible to attack by organizations who are themselves
targets and victims, so that they (and their victimizers) can
victimize those within their reach.  Take it to your
congresscritters/whatever.  Lobby.  Form a party.  Fund speech.  Do
what you have to.  But this is really the wrong forum.

> 3) We can change or at least influence the political objectives

Influence, *maybe*.  There are lots of nations' politics to influence.
 It seems very unlikely to me that "#2 to get #3" will go far at all.

> net result is less or even no privacy for anybody everywhere.

It's way too soon too tell.  Consider the situation in China re: HTTPS
and MITM certs.  China has a CA they *could* use to MITM but don't, at
least not the big sites.  This was a big deal recently when they tried
to blackhole github, and they had to back down.  There are reports
that American companies are scared of losing business as a result of
PRISM.

Combine the fear of market share loss due to PRISM bad PR with the
situation in China and we get stalemate: in the end then every nation
would have to decide what traffic outside its borders (such as they
might be online) to MITM (that can be MITMed), what to blackhole, ...,
or whether to be an open society, but either end result is stalemate.
Of course, if large enough groups of allied countries agree to provide
each other with access to end-points in their jurisdictions, then
we're roughly back to today's situation.

To defeat PRISMs technologically requires: strong personal (mobile)
end-points as the only end-points (i.e., to store or move data in the
cloud it must be encrypted with keys not available to the cloud),
strong crypto, and protocols that cannot be MITMed, not even with the
user's acquiescence.  The last roughly implies something like ZKPPs,
which don't scale except when used as pre-authentication to protocols
like Kerberos or BrowserID, which bring with them long trust paths (as
that's their point: to act as introducers), making the whole thing
vulnerable once more.  In the absolute best case scenarios people end
up being vulnerable only to traffic analysis, social engineering, and
to rubber hose cryptanalysis, but you still have to trust so much
stuff (hardware, firmware, software) that it's almost certainly
infeasible for the forseeable future...

...and that's probably why we're not being asked for #2, along with
the fact that #2 would be a *big* deal to ask for.  We'll be asked for
#2 if anti-PRISM tech begins to thrive, or realistically threatens to,
and probably no sooner.

[0] https://www.cs.columbia.edu/~smb/papers/CALEAVOIPreport.pdf

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 17 Jul 2013 00:20:13 +1200

On 16/07/2013 4:19 a.m., Reto Bachmann-Gmür wrote:
> On Sun, Jul 14, 2013 at 12:41 AM, J Ross Nicoll wrote:
> attacks from a root-certificate holding man in the middle.

I can't think how. The MITM can as easily change that public key to its 
own one and use the original itself as the client could use it in the 
first place. Security 101 - never send the vital key data over a suspect 
channel which relys on that key for protection.

The whole of this thread is beyond WG charter IMHO. Let us stop circling 
the drain on it.

Amos

---

From: Reto Bachmann-Gmür <[email-masked]>
Date: Tue, 16 Jul 2013 18:28:43 +0200

On Tue, Jul 16, 2013 at 2:20 PM, Amos Jeffries <[email-masked]> wrote:
>>> to
> I can't think how.

Abusing the userinfo subcomponent a  URI could look like this

https://[email-masked]/foo

If the public key presented by the server does not match the digest
WanYixZKajPyjw2llf the client would present a warning.

> The MITM can as easily change that public key to its own
> one and use the original itself as the client could use it in the first
> place.

No. The MITM might be able to provide a duly signed certificate for
example.org but it would much harder to create one which matches the
digest present in the referring URIs.

Reto

---

From: Nico Williams <[email-masked]>
Date: Tue, 16 Jul 2013 12:29:14 -0500

> digest present in the referring URIs.

This doesn't allow for key/cert rollover.

---

From: Reto Bachmann-Gmür <[email-masked]>
Date: Wed, 17 Jul 2013 18:10:00 +0200

> This doesn't allow for key/cert rollover.
True for the simplest version. But such a crypto identity token yould
also be a hash of some longer lived cert used to sign the cert that
are being changed more frequently. And there could be mechanism to
have multiple valid tokens so that old ones can be gradually phased
out. Like for an invalid ca-cert it's ultimately up do the user to
decide what to do when the cert of a site doesn't match the token in
the link. It just would give users who care about security better
means to do so.

Cheers,
Reto