Re: HTTP/2 and Pervasive Monitoring

--------
In message <38BD57DB-98A9-4282-82DD-BB89F11F7C84@mnot.net>, Mark Nottingham wri
tes:

>that the WG position is clear going into IETF LC.
>
>The most relevant text in 188 is:
>
>>    It is therefore timely to revisit the security and privacy properties
>>    of our standards.

>It's safe to say that pervasive monitoring is very relevant to HTTP.

Mark, I think your summary is good and balanced with respect to the
discussions we have had, yet I think we can and should do better.

To be honest I don't think that we have ever discussed the question
*exactly* as precented in 188 -- as a question of herd immunity to
*pervasive* monitoring.

Our discussions have almost entirely focused on what protection the
individual user would gain and how to communicate any "lesser"
level of protection from opportunistic TLS etc.

For herd-immunity, the protection of the individual member is not
relevant and doesn't even have to be particularly good, the value
lies in making things sufficiently more difficult, on average,
across the entire population.

If I look at '188 purely as herd immunity, my first instinctive
design would be something like:


Straw-man:
----------

	http:/ can use TLS with *arbitrarily weak* crypto algorithms,
	and no authentication, and it is treated *exactly* like
	HTTP/1.1 plaintext by browsers.

	https:/ uses authenticated TLS with strong crypto, as today,
	and indicates this with the well-known changes in browser
	behaviour.

The crucial two points here, which I don't recall us discussing
previously, are that we maintain the safe/unsafe distinction towards
the user and we allow weak crypto-suites -- not to protect the user,
but to "whiten" the traffic for attackers.

In other words, the TLS on the http:// connections will do nothing
to protect the individual user, will cause nothing to give her any
perception of any increased protection and presents no credible
barrier to a targeted MITM, but it closes the door on PM by passive
traffic scooping.


Is that even our job ?
----------------------

Strictly speaking, none of those balls are in our court.

One half part is about browsers uncritically and silenty accepting
self-signed certs, the other is about selecting/designing intentionally
weak(er) cipher-suites.

Our drafts as they currently stand, are 100% capable of playing
it's part between those two components.  For that matter
this is not even specific to HTTP/2 in any way, it could also
be deployed for HTTP/1.1.)

The entire value in this idea lies in the synergy of the two
responsible parties doing things which in isolation looks
counter-productive to them, but which has huge beneficial effects
when taken together.

Such "prioners dilemma" situations don't optimize themselves.

Our reply to BCP188 may be the best, or even the only chance, of
igniting a smart solution.


But would it even work ?
------------------------

Obviously, there has to be cipher-suites good enough to frustrate
passive PM + brute force, but cheap enough for high-traffic emergency
services, news and porn.  It is conceiveable that we have to allow
even a NULL encryption as a fall-back/emergency option  for otherwise
unmanageable traffic-spikes.

The idea will probably be hard to sell since most people have no
clue what "herd immunity" is or how it works, so we will run into
a lot of automatic and uninformed rejections of 'uselessly weak
crypto' and 'privacy without authentication is useless' etc. etc.
Basically the entire "self-signed cert" fiasco over again.  Choice
of vocabulary, for instance "whitening" rather than "privacy" may
be crucial here.

I'm not a card-carrying cryptographer, but it is my clear understanding
that such a proposal would require adversaries to do actual MITM
to gain access to content, rather than the current passive wire-tapping.
Actual card-carrying cryptographers need to consulted on this.

Yet, I don't think legally mandated MITM deployments (corporate
recording/filtering, jails, schools etc.) will become prohibitively
expensive to implement, which is a good thing.

As to its efficiacy against the elephant in the room, Dan Geer made
an important point in his Black Hat keynote some days ago (read
it!):  Ideas such like this are no use unless they raise the cost
of PM to a point where the expense becomes politically relevant
and preferably objectionable.

If we only make PM 1% more expensive, all we have done is raise our
own taxes for no good reason.  We need to raise the cost several
hundreds of percent, preferably several orders of magnitude.

Yet, there is a balance to strive for.  Making it too expensive
would increase the risk that governments will regulate citizens use
of encryption.  Making it entirely impossible will almost guarantee
such regulation also in self-styled "civilized societies which
respect human rights."

A crucial technical question seems to be if we have, or can come
up with, cipher-suites which are cheap and fast enough for the white
hats, but sufficiently expensive to be uneconomical to break for
PM purposes, force surveillance to do actual, much more expensive
MITM.

The next big question will be agreeing on which of these intentionally
weaker cipher-suites to mandate for interop purposes.  This runs
directly into "we cannot trust anything NSA (and their secret agents)
tells us" and the best strategy is probably to appoint Bruce King
of that question.

The fact that this scheme doesn't play into the hands of the CA-racket
will play both ways: a lot of people will like that, the CA-mob
will hate to miss a growth opportunity.

Summary:
--------

Yes, I think it could work.

And yes, I think this WG should go to forcefully to bat for it in
our reply to BCP188 by pointing out that there's low-hanging fruit
to be picked, one apple to the left, one pear to the right, but
that this WGs arms are too short.

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

Received on Friday, 15 August 2014 09:16:33 UTC