Subject: HTTP/2 and Pervasive Monitoring

From: Mark Nottingham <[email-masked]>
Date: Fri, 15 Aug 2014 12:58:22 +1000

I've had a few questions off-list about our stance regarding BCP188 <http://tools.ietf.org/html/bcp188> and HTTP/2, and want to make sure 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.  The IETF will work to mitigate the technical
>    aspects of PM, just as we do for protocol vulnerabilities in general.
>    The ways in which IETF protocols mitigate PM will change over time as
>    mitigation and attack techniques evolve and so are not described
>    here.
> 
>    Those developing IETF specifications need to be able to describe how
>    they have considered PM, and, if the attack is relevant to the work
>    to be published, be able to justify related design decisions.  This
>    does not mean a new "pervasive monitoring considerations" section is
>    needed in IETF documentation.  It means that, if asked, there needs
>    to be a good answer to the question "Is pervasive monitoring relevant
>    to this work and if so, how has it been considered?"

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

We've had an extensive discussion regarding PM, most occurring during and between the August 2013 (Berlin) and January 2014 (Zurich) meetings. 

One proposal we considered was to require the use of TLS (through https:// URIs) for HTTP/2. However, some members of the community pushed back against this, on the grounds that it would be too onerous for some uses of HTTP (not necessarily CPU; cost and administration of certificates was cited as a burden, as was the follow-on disruption to applications, since transitioning from HTTP to HTTPS often requires non-trivial content changes, due to the way that the browser security model works).

We also discussed an "Opportunistic Security" approach to using TLS for http:// URIs (but without authentication). This was a bit controversial too, as some community members felt that having another, weaker kind of security defined harms the long-term deployment of "full" TLS. 

After discussion in June 2014 (New York), however, we agreed to adopt this document as an optional extension, but only with Experimental status: <http://httpwg.github.io/http-extensions/encryption.html>. It's expected that we'll ship it shortly after HTTP/2.

I would characterise the WG a having a somewhat uneasy (but also pragmatic) consensus on this outcome. 

To date, we've had one browser implementation express an intent to requiring https:// URLs for HTTP/2, one interested in https:// as well as Opportunistic Security for http:// URLs, and one that is interested in https:// as well as cleartext http://.

Note that most of the justification for our decision not to require https:// for HTTP/2 seems to be predicated on this part of our charter <http://datatracker.ietf.org/wg/httpbis/charter/>:

"The resulting specification(s) are expected to meet these goals for common existing deployments of HTTP[.]"

... i.e., we're not able to argue that people who can't use https:// should just stay on HTTP/1.1. This charter text was written before BCP188 (and the incidents leading up to it), but has considerable support in the WG.

This is roughly what I intend to put in the Shepherd Writeup when we take it to the IESG, as of now (IETF LC may change things, of course). Does anyone have anything to add?

Regards,

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

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 15 Aug 2014 17:53:22 +1200

> I would characterise the WG a having a somewhat uneasy (but also pragmatic) consensus on this outcome. 

Nod.

> ... i.e., we're not able to argue that people who can't use https:// should just stay on HTTP/1.1. This charter text was written before BCP188 (and the incidents leading up to it), but has consider…

While the particular trigger incident(s) for BCP188 had not occured. I
recall that (at least some of) the WG voting on charter was aware of PM
issue itself and earlier incidents of the same nature as leading to BCP188.
I am also confident that a solutino exists. We just have to agree on
what it looks like.

Amos

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 15 Aug 2014 16:00:48 +1000

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

I'm not so sure about this.

The vast bulk of PM issues, at least as they are discussed in Australia are
related to the collection and retention of meta data.  Who you talked to,
when you connected, how much data, who you connected to next, etc.
While I'm sure inspection of content is also an issue, it is secondary to
the meta data issues.  Also many of the players involved in PM attacks have
access to the unencrypted end points, so transport encryption is a long way
off being a silver bullet for protection from PM

There is very little that we can do within a protocol like HTTP to address
the such meta data collection.     More over, the problems that we face are
similar to PM issues that other application protocols face.  SMTP, POP,
IMAP, Websocket, IRC, SIP etc. all need similar protection as
HTTP.            Solving PM is not something that I think that any of these
protocols can do on their own.  Essentially PM is something that needs to
be addressed at the TCP/IP level as I would suggest that any protocol using
TCP/IP is subject to significant PM attack regardless of encryption.

Note that I'm not necessarily arguing against https only.... I'm really
just saying that to pretend that this gives any significant defence against
PM is to over sell what it achieves or what can be achieved by any
application protocol stand alone.

It is indeed a problem, I just don't think we can put our hand up as being
able to solve it.

regards

-- 
Greg Wilkins <[email-masked]>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.

---

From: <[email-masked]>
Date: Fri, 15 Aug 2014 07:35:29 +0000

On Friday,15 August 2014 08:01 [email-masked] wrote:
> Note that I'm not necessarily arguing against https only.... I'm really just saying
> that to pretend that this gives any significant defence against PM is to over sell
> what it achieves or what can be achieved by any application protocol stand
> alone.

Indeed it is misguiding the public into a false sense of security to sell it as such.

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 15 Aug 2014 18:56:40 +1000

Greg - please have a read of the BCP, which says some things that are very similar to your statements.

No protocol effort can claim to “solve” it — it would be ludicrous to say we could — but by the same token, we can’t (as per the BCP) bury our heads in the sand and not consider the PM-related consequences of our protocol design.

 (I think we’re in violent agreement here)

Cheers,

On 15 Aug 2014, at 4:00 pm, Greg Wilkins <[email-masked]> wrote:

> The vast bulk of PM issues, at least as they are discussed in Australia are related to the collection and retention of meta data.  Who you talked to, when you connected, how much data, who you connected to next, etc.      While I'm sure inspection of content is also an issue, it is secondary to the meta data issues.  Also many of the players involved in PM attacks have access to the unencrypted end points, so transport encryption is a long way off being a silver bullet for protection from PM
> 
> There is very little that we can do within a protocol like HTTP to address the such meta data collection.     More over, the problems that we face are similar to PM issues that other application protocols face.  SMTP, POP, IMAP, Websocket, IRC, SIP etc. all need similar protection as HTTP.            Solving PM is not something that I think that any of these protocols can do on their own.  Essentially PM is something that needs to be addressed at the TCP/IP level as I would suggest that any protocol using TCP/IP is subject to significant PM attack regardless of encryption.
> 
> Note that I'm not necessarily arguing against https only.... I'm really just saying that to pretend that this gives any significant defence against PM is to over sell what it achieves or what can be achieved by any application protocol stand alone.
> 
> It is indeed a problem, I just don't think we can put our hand up as being able to solve it.
> 
> regards
> 
> 
> 
> 
> -- 

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

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 15 Aug 2014 09:16:08 +0000

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

>that the WG position is clear going into IETF LC.
>
>>    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
[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: Mark Nottingham <[email-masked]>
Date: Fri, 15 Aug 2014 21:25:36 +1000

Hi PHK,

> Straw-man:

It sounds like you're proposing that we allow weaker ciphersuites for the Opp-Sec draft. 

That hasn't been discussed explicitly before IIRC, but it shares an issue that we did previously discuss; if you're not authenticating the Opp-Sec traffic, you want it to look as much like "real" TLS traffic as possible, so that an attacker doesn't know which connections it can MITM without being caught. 

If Opp-Sec traffic is able to be distinguished (e.g., by using a different ciphersuite), it'll be possible for an active attacker to selectively MITM it and not be detected. 

The trade-off of the extra efficiency gained vs. the loss of protection is debatable from both sides, of course.

Cheers,

---

From: Eliot Lear <[email-masked]>
Date: Fri, 15 Aug 2014 14:27:53 +0200

Hi Mark,

Just on these two points, taken together:

> We also discussed an "Opportunistic Security" approach to using TLS for http:// URIs (but without authentication). This was a bit controversial too, as some community members felt that having anoth…

Some of us have been a little nervous about the spread of infections due
to encryption with unauthenticated endpoints, making it a bit more of a
pain for in-path virus checkers and such.  That was raised several
times.  You saw data published to this list from Cisco saying that this
wasn't really a problem when the server had a valid cert.

Eliot

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 15 Aug 2014 12:34:49 +0000

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

It's not really a proposal relative to any other document than BCP188
in the context of HTTP.

>If Opp-Sec traffic is able to be distinguished (e.g., by using a 
>different ciphersuite), it'll be possible for an active attacker to 
>selectively MITM it and not be detected. 

I'm afraid that you just proved one of my points with respect to
how hard a sell this might be, because people don't understand
herd immunity  :-)

Let me try to explain it another way:

Today the majority of PM has the form of a passive optical splitter,
tcpdump and postanalysis.  Given the "take" it brings, this is dirt
cheap to implement.

Currently, they can run a filter which is essentially:

	tcpdump -i all0 -w - | egrep -i "terrorist|bomb"

and the cost is way less than they spend on toilet-paper.

By by whitening the present HTTP plaintext traffic with TLS, even
with quite weak cipher-suites, we dramatically increase the cost
of the postanalysis step, instantly making that filter impossible.

Depending on the cryptographic cost we impose with our whitening,
a number of avenues remain open for the attackers:

1. Brute-force only a tiny fraction of traffic, most likely guided
   by metadata analysis.

   Chances are that the tiny fraction they'll be most interested
   in uses "real" https in the first place.

2. MITM a tiny fraction of traffic, most likely guided by metadata
   analysis.

   What they already have to do for "real" https.

The crucial result here, is that we eliminated the "pervasive" from
PM with respect to HTTP data, by putting north of 99.99% of all
current plaintext traffic out of their economic reach, traffic which
they currently get to see for absolutely free.

Your concern about them being able to tell "real" TLS from "phony" TLS,
for the purpose of MITM, at best comes in as a distant second or third
order effect relative to this proposal: its the step from tcpdump
to MITM were their cost explodes.

It doesn't really matter that they can instantly tell what is "phony"
TLS, and what is "real" TLS, the point is that they cannot get at
either of them without working actively and hard for it, and therefore
they will be forced to focus on and target only suspect traffic.

"working hard" will in most cases be MITM, which is a victory in
itself, because MITM has non-zero probability of detection, where
passive collection has zero probability.

So don't they just switch from pervasive monitoring to pervasive MITM ?

In theory they could, but in practice not.

Technologically, it is extremely doubtful if anybody is ever going
to be able to do anything like moderately well-hidden MITM TLS on
a full 40Gb/s fiber.  You'd have to do it blantantly, as in "The
Great Firewall of Elbonia" style brutalism.

Even though 10Gb/s might be technologically feasible, the economics
ensure that it will never happen on a scale anywhere close to the
current pervasive passive slurp, because both the cost of access
to fibres, cost of equipment and legal complications crop up.

To summ up:  It doesn't matter that they can instantly see it is
"phony" TLS, they still have to work much harder to get at it.

---

From: "Martin Nilsson" <[email-masked]>
Date: Fri, 15 Aug 2014 14:43:25 +0200

On Fri, 15 Aug 2014 13:25:36 +0200, Mark Nottingham <[email-masked]> wrote:

> That hasn't been discussed explicitly before IIRC, but it shares an  
> issue that we did previously discuss; if you're not authenticating the  
> Opp-Sec traffic, you want it to look as much like "real" TLS traffic as  
> possible, so that an attacker doesn't know which connections it can MITM  
> without being caught.

What you can do in an MITM scenario isn't really relevant to PM. It's  
still harder to MITM weak TLS than clear text.

I think it is more worrisome having the weak ciphers in there at all, as  
it opens up for bad configurations and downgrade attacks of https  
connections.

/Martin Nilsson

-- 
Using Opera's mail client: http://www.opera.com/mail/

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 15 Aug 2014 12:54:19 +0000

--------

>still harder to MITM weak TLS than clear text.

You don't need to MITM clear text, you just read it.

The big step in cost is going from tcpdump to MITM.

>it opens up for bad configurations and downgrade attacks of https  

This is a valid concern, and a good reason why one might consider
something more tailored to whitening and quite distinct from TLS.
Designing or even proposing that is way over my pay-grade.

The bar is pretty low though.

If we can increase the cost of inspecting (ie: brute-forcing) a non-privacy
HTTP connection to something above 25msec CPU time, we have made PM
uneconomical.  >250msec and we have eliminated it.

---

From: "Albert Lunde" <[email-masked]>
Date: Fri, 15 Aug 2014 08:08:08 -0500

>What you can do in an MITM scenario isn't really relevant to PM. It's still harder to MITM weak TLS than clear text.
>
>I think it is more worrisome having the weak ciphers in there at all, as it opens up for bad configurations and downgrade attacks of https connections.

Outside the realm of standards, the print edition of "Bulletproof SSL and TLS: Understanding and Deploying SSL/TLS and PKI to Secure Servers and Web Applications" by Ivan Ristic just shipped(as in I expect to get a copy from Amazon later today) The chapter on OpenSSL has been available for a while, and helped me with some recent issues.

---

From: Cory Benfield <[email-masked]>
Date: Fri, 15 Aug 2014 14:12:27 +0100

On 15 August 2014 13:34, Poul-Henning Kamp <[email-masked]> wrote:
> [long message snipped]

Before this email I had not grasped the value of Opp-Sec, and would
not have implemented it. I am now swayed. I would happily go to bat
for PHK's proposal of allowing Opp-Sec with 'whitened' cipher suite
restrictions, and would implement it for both HTTP/2 and HTTP/1.1.

---

From: Erik Nygren <[email-masked]>
Date: Fri, 15 Aug 2014 10:39:45 -0400

A number of comments on this topic based on some discussions
I've had over the past few weeks:

OppSec as deployment vehicle or for security
--------------------------------------------

Using http:// scheme URIs over TLS for HTTP/2 should be thought of as
firstly as a stop-gap deployment vehicle for HTTP/2 to get past broken
middle boxes without requiring application-side changes to immediately
move to https scheme.

The OppSec side-effects of this have a nice secondary benefit for
raising the bar to PM, but there are significant concerns that there
are enough active attacks already today that this may provide a
misleading false sense of security.

On a related note, even having the word "security" here has the risk
that people will misunderstand it to unfortunate results.  (I live in
fear of reading some marketing copy along the lines of "Opportunistic
Security adds extra bonus value because it takes full advantage of
Opportunities to give you even more security than you got previously
with that older 'Real Security'." --- or something similarly
misleading and scary.)

On transitions and fallbacks
----------------------------

While this OppSec model also makes it straight-forward for a large
hosting provider or CDN to immediately deploy HTTP/2 for
http-scheme-over-TLS without application changes or needing to manage
per-customer certificates, we don't have terribly good models here to
make a smoother transition.

Transitioning from OppSec unauthenticated http-over-TLS to HTTPS has a
reasonable story:  provision a real certificate, 301 redirect
to https, then start using HSTS or similar.

However we don't have a story in the current draft for transitioning
from OppSec unauthenticated http-over-TLS to authenticated http-over-TLS
in an operationally supportable manner.  When a server returns:

   Alt-Svc: "h2"=443

it has no idea whether or not the client is going to try and validate
the certificate and what it will do if it will fail.
One possibility would be to do something like:

   Alt-Svc: "h2"=443; validate=pkix

but this is sent over cleartext.  This could be useful,
however, such that if browsers are going to require cert
validation they could know NOT to follow the AltSvc if
that "validate=pkix" isn't present.

An unfortunate side-effect here is that active MitM
could easily strip out that text.

Another unfortunate side-effect of this Alt-Svc OppSec model in
general is that it has some of the same unfortunate incentives when
certificate validation fails as STARTTLS has within SMTP where many
clients fall back to using cleartext http/1.1 instead of unauthenticated
encryption.  Saying "let's not implement it" just ends up
in the same boat of using cleartext http/1.1 for people who
aren't motivated to make the jump to HTTPS.

The counter argument I've heard is that http/2 without OppSec will be
a forcing function to get people to move to HTTPS, but there are
enough barriers to universal HTTPS today (lack of universal SNI/IPv6
and cert provisioning challenges), that I'm still strongly of the
opinion that it is worth having this "OppSec" deployment vehicle
bridge for the next few years at least until we get universal SNI
adoption.

> HTTP/1.1 plaintext by browsers.

For better or worse, the current drafts don't easily support this in a
way that doesn't introduce risk during transitions as the server
doesn't have a good indication of whether http or https scheme will be
used.  (Earlier Alt-Svc drafts contained an "h2t" ALPN token, but this
has subsequently been dropped.)  The cost for modern servers of
AES-GCM (or ChaCha20-Poly1305 once that is supported) is typically low
enough that there's no point in using something weaker.  Similarly,
it's not clear what one would use other than ECDHE that would be
worthwhile and cheaper for key exchange.  (Wearing my
*not-a-cryptographer* hat.)

Doing anonymous key exchange without a server cert might
be useful to bring down the cost, but then there would
need to be some client handshake signalling (in the cleartext
client_hello) that OppSec http-over-TLS is going to be used,
and this is something we've wanted to avoid so far.

> For that matter this is not even specific to HTTP/2 in any way, it
> could also be deployed for HTTP/1.1.

Only if there was a way to convey Scheme (http vs https) in a way that
worked reliably for existing HTTP/1.1 servers.

       Erik

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 15 Aug 2014 14:50:38 +0000

--------
In message <CAKC-DJjFk9==Y4ayn=A-fZBaEt-G_+n=[email-masked]>
, Erik Nygren writes:

>[...]  provision a real certificate, [...]

I have it from many corners, than anything which involves "real
certificates" are not going to happen for a large swath of "unimportant"
traffic because of the extortionary business behavior of the CA-mob.

I personally have no love for the CA-mob, but a lot of people seem to
hate their guts.  Keeping them out of the picture wrt. fighting PM
would be a good idea.

Also, we don't need very big certs, they just have to hold for a
few seconds.

>worked reliably for existing HTTP/1.1 servers.

I was talking only conceptually here, the actual protocol mechanics
will be at least as tricky as HTTP/1 -> HTTP/2 upgrade.

---

From: Roland Zink <[email-masked]>
Date: Fri, 15 Aug 2014 19:25:23 +0200

> Am 15.08.2014 um 14:27 schrieb Eliot Lear <[email-masked]>:
> 
> Hi Mark,
> 
Don't think that a valid cert really helps here although it may give a hint about who is responsible.
 - the browser is executing potential dangerous code and may be infected.
 - there are just too many devices in a home to do this efficiently on all the devices.
 - the spy my already be in, for example a TV, and try to smuggle out private data under the TLS.
A central point of control may help users.

This problem should be solved separately and opportunistic encryption increases the need for a solution.

Roland

---

From: Martin Thomson <[email-masked]>
Date: Fri, 15 Aug 2014 11:13:11 -0700

> will be at least as tricky as HTTP/1 -> HTTP/2 upgrade.

I've talked with several people about HTTP/1.1 and the mechanisms
we've defined.  They are portable - in theory.

The problem is that you not only need a strong signal with the
response that the server has understood that this is an http:// URI,
but you might also want some way to prevent the server from even
processing the request.

Incidentally, the difference between good crypto and bad crypto here
is that good crypto is fast and secure and bad crypto is just bad.
It's not even necessarily faster on modern hardware (AES runs
sub-cycle-per-byte on the latest Intel hardware).  I know that we're
talking RC4 here.  Without AES-NI, RC4 is quite a bit faster than AES,
but I expect that we'll see a good alternative (ChaCha20) before too
long that is faster than both on many of those old machines.

---

From: Brian Smith <[email-masked]>
Date: Fri, 15 Aug 2014 11:31:41 -0700

> ... i.e., we're not able to argue that people who can't use https:// should just stay on HTTP/1.1. This charter text was written before BCP188 (and the incidents leading up to it), but has consider…

In the end, it seems like the working group accepted that there will
be times when implementations must fall back to HTTP/1.1, so isn't the
justification you mention above void now? In particular, see this very
recent thread "Feedback on Fallback" started by Mike Bishop and the
"Over-Version" draft it references:

    http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/1724.html
    http://tools.ietf.org/html/draft-nottingham-http-over-version-00

Consequently, I don't think the shepherd's writeup should say that
requiring authenticated TLS for HTTP/2 was rejected on the grounds
that fallback to HTTP/1.1 is unacceptable, since the group came around
to agreeing that fallback to HTTP/1.1 is indeed a reasonable
compromise sometimes.

Cheers,
Brian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 15 Aug 2014 18:54:01 +0000

--------
In message <[email-masked]>

>we've defined.  They are portable - in theory.

...and in theory that means that they will work in practice :-)

>is that good crypto is fast and secure and bad crypto is just bad.

What is good and what is bad crypto, depends a LOT on what your
ephemeral lifetime requirement is,.

And incidentally, cryptographers have a very strong tendency to
forget that all crypto is ephemeral in the first place, because the
usually unstated requirement is that the ephemeral lifetime be
longer than the probable duration of the universe.

For the isolated problem of defeating PM, the ephemeral lifetime
requirement is a few seconds, reducing the customary 128+ bits
to something on the order of 32.

Good crypto which only lasts a couple of seconds would be terribly
bad crypto in almost any other context.

But conversely, a lot of crypto deemed bad or even "horrible" in
normal contexts will be perfectly good crypto for the purpose of
defeating PM.

I'm not taking a position on what specific algorithms would or
wouldn't be suitable here, but I will point out that it is much
more important that it does 10Gbit/s on commodity hardware, so
loadbalancers and such can keep up, than it be able to survive
systematic attack for more than few seconds.

If it wasn't because of the almost-always-known-plaintest property
of HTTP headers, a simple XOR with a 32bit random number would
be enough.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 15 Aug 2014 21:41:23 +0200

> hint about who is responsible.

We don't have causality, but we do have data.  And so one man's
conjecture is as good as the next's.  Here's mine: the majority of
illicit servers are actually running on hacked systems and the data is
being served off a simple HTTP server, where no warning is produced.  It
costs money to get a cert for that system, which doesn't actually buy
the miscreant anything.

Eliot

---

From: Greg Wilkins <[email-masked]>
Date: Sat, 16 Aug 2014 09:12:08 +1000

>  (I think we’re in violent agreement here)

The difference is emphasis.

I think you are saying: "We are using TLS to mitigate PM, but it is not
perfect".

I think this WG should say:  "An application protocol cannot significantly
mitigate PM. A network level solutions is required.  But we are
facilitating increased TLS usage which may mitigate some PM attacks or at
least prevent even more invasive PM"

ie the overwhelming response to BCP188 should be that this is not a problem
we can fix on our own, but we are prepared to be part of the solution.

cheers

---

From: Greg Wilkins <[email-masked]>
Date: Sat, 16 Aug 2014 09:23:16 +1000

>         tcpdump -i all0 -w - | egrep -i "terrorist|bomb"

That kind of monitoring does take place,  but any *pervasive" monitoring of
that kind requires a warrant - or is illegal (and if illegal they can tap
into places that TLS will not help).

The type of *pervasive* monitoring that is legal and does take place widely
is

    tcpdump -i all0 -n | egrep "IP [0-9\.]* > IP.OF.KNOWN.NASTY"

This is not something that the protocol or TLS can fix.

cheers

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 16 Aug 2014 00:03:14 +0000

--------
In message <[email-masked]>

>we can fix on our own, but we are prepared to be part of the solution.

Agreed, but I think we should also point out that defending against
the 'pervasive' aspect is much cheaper than "real" privacy.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 16 Aug 2014 01:27:15 +0100

> the 'pervasive' aspect is much cheaper than "real" privacy.

I've disagreed with one aspect of this offlist in some exchanges
with PHK.

I do not think that weak ciphers form any part of the mitigation to
PM. Using such would I think inevitably leave open vulnerabilities
that would allow the bad actor to continue to do PM at no significantly
greater expense.

For example, if a "faster weaker" cipher were to be used, that is
always distinguishable (e.g. via timing), allowing the bad actor
to simply record ciphertext for those packets and decrypt later
on demand.

PHK and I disagree a bit about the definition of PM in that respect.
I conclude that BCP188 would include storing breakable ciphertext in
the definition of PM. He doesn't.

So I don't agree with his distinction,  if "real" privacy is meant
to mean strong encryption and cheaper is meant to mean something
trivially breakable.

And I think that leads us back to the opp-sec draft as this WG's
specific response to PM.

S.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 16 Aug 2014 06:20:13 +0000

--------

>the definition of PM. He doesn't.

Stephen, you're free to express your own opinion, but I think it
would be best if you let me express mine.

My argument is that if the attacker captures and stores N>1 connections
in the same time he manages to break the crypt on 1 connection,
then it is by definition not PM, since he will not ever be able to
decrypt all the traffic.

The footnote to this is that that the attacker still gets to chose
which fraction of the traffic to spend his limited resources breaking
the crypto on, so N has to be very large before it affects human
rights in a relevant fashion.  PM probably already only captures
metadata for most of the porn traffic, major news sites etc and
certainly would give such a resource constraint.

Also note, that getting the 99% out from under PM by sacrificing
the 1%, is not a final solution to the human rights problem, and
skirts dangerously Martin Niemöllers warning.

In the present situation my straw-man it at best just stopgap measure
until the political process implements the correct solution to the
PM problem.  On the long scale it could also vaccinate the net
against recurrences or regimes where political solutions are not
forthcoming.

The important thing in my straw-man is not if we should or shouldn't
do it, but the fact that PM can be made impossible with ciphersuites
you can break in a matter of seconds.

That observation should be made part of our BCP188 response, because
clearly a lot of people don't realize this.

---

From: Roland Zink <[email-masked]>
Date: Sat, 16 Aug 2014 09:01:58 +0200

> Am 15.08.2014 um 21:41 schrieb Eliot Lear <[email-masked]>:
> 
> 
If the hacked system is a web server then the assumption it will have a valid cert in the future and there will be no need to add one. If the system is at home then my proposal was to stop this in the home users network through inspection of the traffic regardless if a valid cert is installed or not.

Roland

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 16 Aug 2014 11:36:09 +0100

> would be best if you let me express mine.

Apologies. I should have said "I think he doesn't".

...

> you can break in a matter of seconds.

That last is the part with which I disagree. I just don't think its
true, for what I understand as PM, as defined in BCP188.

But I agree with you about the rest, that is, if you said chacha20
and not breakable-cipher then we'd be saying the same thing.

Cheers,
S

---

From: Amos Jeffries <[email-masked]>
Date: Sun, 17 Aug 2014 17:45:13 +1200

> and not breakable-cipher then we'd be saying the same thing.

I'd like to know what your particular reasons for disagreement are.

For my part, I do not believe that timing assertions in the argument are
sufficiently long.

- 250ms is only the normal network lag of a connection from my home to a
Canadian server (150-250 is normal for NZL). E.g. anyone over here in NZ
using the free Google DNS services routinely see that much delay.
Several such delays for displaying modern pages is not seen as any, or
much, impedence.

- The Human-Computer Interface rule of thumb still has 5 seconds of
delay being the *lower* limit on user patience. And that is for users
who sit and wait for the loading**. In my experience they are tending to
use tabs now and observe one while others load.

 ** I am assuming here that the XHR/AJAX type background traffic on
interactive pages is re-using existing connection(s) to the server (ie
over h2, or long-polling). Such connections only the initial MITM delay
on decrypting the first bytes to identify keys matters.

Amos

---

From: Eliot Lear <[email-masked]>
Date: Sun, 17 Aug 2014 08:19:22 +0200

On 8/15/14, 2:34 PM, Poul-Henning Kamp wrote:
> By by whitening the present HTTP plaintext traffic with TLS, even with
> quite weak cipher-suites, we dramatically increase the cost of the
> postanalysis step, instantly making that filter impossible.

This presumes that the use of weak cipher suites is actually cheaper to
the end points than strong ones.  Is that really the case?

Eliot

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 17 Aug 2014 07:31:54 +0000

--------

>the end points than strong ones.  Is that really the case?

I think it is an implict requirement that a COTS server can do 10Gbit/s.

Any algorithm which meets that in software is fine by me from a
performance point of view.

Notice that the breaking is most likely going to happen against a
short-ish key (32-40 bits) rather than against the algorithm.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 17 Aug 2014 08:24:17 +0000

--------
In message <[email-masked]>, Amos Jeffries writes:

>- 250ms is only the normal network lag of a connection 

That's not a relevant metric.

Imagine NSA buys 10 million CPUs dedicated CPUs for breaking HTTP
whitening.  These would be above and beyond what they currently use
for the plain-text HTTP PM, it's not a trivial cost.

At a cpu cost of 250 msec/connection, they can break:

	10e6 / .25 = 40 million HTTP connections a second.

According to Netcraft, there are north of 100 million active sites
on the web.

If, on average, they each get connection every other second, NSA
will no longer be able to see all the traffic, and therefore, in
strict mathematical terms it is no longer PM.

In practice it would still be, because NSA doesn't need to see all
traffic to pornsites, netflix, major news sites etc, and that amounts
to about 80% of all HTTP today.  This introduces a scaling factor
of about 5-10 in NSAs favour.

But all we need to know is how many HTTP connections there are
globally per second and how many CPUs NSA would be able to dedicate
to un-whitening, and do a division.

Unfortunately, neither number is readily available.

My back-of-the-envelope calculation came out to around a quarter
of a second which I estimate is about 32 bits of key.

Your BOTE numbers will vary, and I'd love to hear them.

But the conclusion is evident:  It doesn't take much work to make
PM uneconomical.

Poul-Henning

PS: A interesting point here is that NSA is not limited in space but
in money and energy.  We should really be talking about how many 
cents and Joule it takes to break a TCP connection.

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 17 Aug 2014 15:08:44 +0300

> I think it is an implict requirement that a COTS server can do 10Gbit/s.

Well, here are some rough estimates (may be quite a bit off) based on
some benchmark data I found.
- Haswell CPU (Ivy Bridge CPU)
- 10^10 bits per second unidirectional
- Large packets
- CPU use in core-GHz (cGHz):

AES128-GCM: 		~1.3 (~3.2) cGHz
AES256-GCM:		~1.7 (~3.6) cGHz
Chacha20-Poly1305[1]:	~2.3 (~4.4) cGHz

This does not include extra processing from handshaking, but with long-
lived connections (and session resumption), it should be relatively
small load.

I think typical total capacity of single-CPU servers is about 10-14
cGHz.

[1] 256-bit, Not in TLS (might be soonish), friendly to systems with
no AES and/or GCM support in HW.

-Ilari

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 20 Aug 2014 10:32:31 +1000

Coming back to this thread...

> of the postanalysis step, instantly making that filter impossible.

Right. What I'm saying is that if they can distinguish Opp-Sec traffic from HTTPS traffic, they can take *all* Opp-Sec traffic and MITM it without being detected (presuming we don't layer on other checks, which raise the cost of deploying Opp-Sec). 

It's true that they can't just tcpdump any more; they have to terminate TLS, so this *does* raise the cost of PM somewhat; my concern is that it's not enough, given the amount of cash being thrown at PM and the continuously reducing cost of terminating TLS.

I'm curious; do Ilari's numbers <http://www.w3.org/mid/20140817120844.GA1346@LK-Perkele-VII> change your mind at all?

Cheers,

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 20 Aug 2014 10:53:21 +1000

On 20 August 2014 10:32, Mark Nottingham <[email-masked]> wrote:

> I'm curious; do Ilari's numbers <
> http://www.w3.org/mid/20140817120844.GA1346@LK-Perkele-VII> change your
> mind at all?
>

For many servers, the cost of applying the actual cipher is not the main
impost of doing TLS.   The main impost for java servers is just bringing
the data into user memory in the first place so that it can be sliced,
passed to a TLS encoder and then at the very least copied if not encoded.

If we don't have to apply a cipher at all then we can do direct writes with
memory mapped files that move data from file system to network without
transiting user memory.  To apply the null cipher, there will be a data
copy into user space, a data copy from input to output buffers and a data
copy out of user memory.   These 3 copies are almost certainly a lot more
expensive than the cipher (which is done during one of the copies).

I'll try to find the time to see if I can get some hard numbers for what is
the impact of applying even a null cipher in java.    But I'm dubious if
the cost of terminating TLS will be insignificant any time soon.

regards

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 20 Aug 2014 07:29:38 +0000

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

>Right. What I'm saying is that if they can distinguish Opp-Sec traffic 
>from HTTPS traffic, they can take *all* Opp-Sec traffic and MITM it 
>without being detected (presuming we don't layer on other checks, which 
>raise the cost of deploying Opp-Sec). 
>
>It's true that they can't just tcpdump any more; they have to terminate 
>TLS, so this *does* raise the cost of PM somewhat; my concern is that 
>it's not enough, given the amount of cash being thrown at PM and the 
>continuously reducing cost of terminating TLS.

We're in control of how hard we make it for them and therefore we
can always outprice them.  The tradeoff is that we hurt our own
costs as well, but at a much less steep scale.

>I'm curious; do Ilari's numbers 
><http://www.w3.org/mid/20140817120844.GA1346@LK-Perkele-VII> change your 
>mind at all?

No.

I don't think the algorithm matters, as long as it's not buggy, the
bruteforcing will be done against the keys used.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 20 Aug 2014 09:59:59 -0700

> bruteforcing will be done against the keys used.

Let's go with this and run with it a little.  Assume that you are
using AES-GCM or something like it.  That's 2^64 decryptions to get a
50/50 chance of success.  The constant factor is the speed of the
algorithm and it's key schedule.  If you can do 10Gb/s on a single
machine with Ilari's estimated ~1.7 cGHz and 14cGHz per core, that
means something in the order of 900 machine years to brute force a
single key.  Based on some rough guesses on AWS (ECU to cGHz
conversion) and current prices, that's going to set you back about
USD170K.  It's highly parallel, so don't expect to wait particularly
long.  Big caveat on the numbers, I've fudged a fair bit (on the
pessimistic side).

On the other hand, if you reduced the key size to 32-bit and increased
the enciphering rate by a linear factor (4), that reduces the number
of calculations significantly.  That works out a cost for a brute
force of USD0.0000000001

USD170K might be OK, depending on what you concern yourself with.
Though it makes me think that a move to 256-bit ciphers might need to
come sooner than I expected.  On the other hand, any significant
reduction in key size basically seems to amount to nothing short of an
ineffectual cipher.  Even a 64-bit cipher that increased throughput by
a factor of 16 would be a trivial cost to brute force.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 20 Aug 2014 18:36:37 +0000

--------
In message <CABkgnnVvm6vz=[email-masked]>

>50/50 chance of success.

Last I looked AES had 128 bit and larger keys, so that would be 2^127 ?

If you are proposing running it with reduced key size of 64 bits,
I pressume the number would be 2^63 ?

But lets take your $170K @ 65 bit key length estimate.

If I scale that down to 32bit key length, I get 2e-5 USD, which is
pretty close to my way of estimating it:

One processing unit a 4GHz can do two 32 bit keys a second and costs
$200 a year, everything included giving 3e-6 USD per key.

Your 1e-10 number I cannot find any basis for.

>USD170K might be OK, depending on what you concern yourself with.

And you seem to concern yourself with one particular users privacy ?

That is not the topic: the topic is Pervassive Monitoring, ie: the
ability to look at (essentially) *all* traffic at little or no cost.

The Snowden leaks have the cost of the current collection at only
USD 20M.  (A number which many people don't belive is comprehensive.)

If you add 1 microdollar per HTTP connection to that, their cost
will at least double at a monitoring rate of just 650.000 connections
a second.

Is that enough ?  Maybe, maybe not.

The architecture we have been able to divine from the Snowden docs
tells us it would hit them at a very inconvenient point:  First
level triage sorting.

As I've said from the beginning:  We can argue about these numbers,
and other people than me will have better basis for deciding them.

But what is clear is that *long* before the cost of breaking the
encryption on a single HTTP connection increases to a full dollar,
Pervassive Monitoring will have ceased, and only a tiny targeted
fraction of all the traffic will be monitored.

Summary:

To stop PM, we don't need unbreakable crypto, we just need crypto
which is sufficiently expensive to break.

Too expensive to break for PM can be cheap enough to deploy for
emergency services, news and porn.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 20 Aug 2014 12:10:36 -0700

> Last I looked AES had 128 bit and larger keys, so that would be 2^127 ?

No, 2^64.

https://en.wikipedia.org/wiki/Birthday_attack

And to be fair, I did some more scratching and came up with USD 2.8M,
and I'll probably get a different number next time as well.

> Your 1e-10 number I cannot find any basis for.

Take the 170K number and reduce the search space by 2^48; then reduce
again by the performance gain (4).  It gets small fast.

> which is sufficiently expensive to break.

That's all we ever have.  We just draw the line in different places.
My point is that the line is close enough to what is state of the art
to not bother with anything less.  There are other factors at play
other than simply the cost of a brute-force attack.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 20 Aug 2014 20:29:39 +0000

--------
In message <[email-masked]>
>https://en.wikipedia.org/wiki/Birthday_attack

You are not looking for a birthday attack.  You are looking at pile
of billions of HTTP connections and you have to decrypt *all* of them.

>to not bother with anything less.

And my point is that plenty of people have told us that state of the
art is uneconomical to them, so you'll never get emergency services,
news and porn on that bandwagon.