Subject: The TLS hammer and resource integrity

From: Martin Thomson <[email-masked]>
Date: Wed, 28 Mar 2012 05:55:18 +0200

We have already touched on this in discussions of SPDY, but I wanted
to make a statement on this prior to the meeting on Thursday.

TLS is a great tool in the protocol design toolbox.  It provides a
great many things together.  Confidentiality, integrity,
authorization, and so forth.  Therefore, it is very easy to pick up
that tool and apply it without a complete analysis of the treat model
and what aspects of that model it addresses.

Mixed content (see Monday's plenary topic) is a good example of where
TLS doesn't necessarily provide the best trade-off of all the security
options present.  The classic concern is that I have a TLS-secured
page that pulls in content over HTTP in the clear.  That unsecured
content can then potentially poison the entire page.

The property that is required in the mixed content scenario is
integrity.  The host page might not care that confidentiality is
maintained when requesting this content, but it really does care that
the content matches the content that it expects.

Today, the only option we have available to deal with this problem is
TLS.  And along with our integrity (and source authentication), we
also get confidentiality.  This is occasionally desirable, but
frequently, it is merely consequential.

One significant downside to this arrangement is that confidentiality
also rules out intermediation options that could be hugely beneficial.
 Now it is no longer possible to cache copies of JQuery all over the
web.  (TODO: deal with obvious CDN counter-argument)

Intermediation is a fundamental part of the web architecture and
building a protocol that makes this inherently difficult would be a
disservice to the web.

The separation of resource integrity from communication
integrity/confidentiality is something that I know others have been
thinking about.  I'd like to see this discussed in HTTP/2.0.

--Martin

long p.s. I should include a reference to the work from decade, that
deals with exactly this sort of problem in an environment that
consists entirely of unauthoritative "intermediaries".

One proposed solution, which should probably be at least considered,
is to provide a content-specific identifier for a resource.  That is a
resource is identified by a hash of its representation, so that a
modified representation can be easily detected.  This might actually
be more restrictive than is entirely ideal, but it is worth knowing
about:see draft-farrell-decade-ni.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 28 Mar 2012 06:14:28 +0200

> about:see draft-farrell-decade-ni.

I forgot an important point:

As we develop a more nuanced view of what security means, how we
communicate with users and signal in protocols becomes more relevant.
Showing a lock icon or green/blue address bar has a meaning that users
think that they understand.  For those that pay that much attention,
this is a sign that entering credit card details is OK.

Dealing with communication on these aspects is by no means trivial,
but I don't see it as intractable, just hard.

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 28 Mar 2012 18:15:01 +1300

On 28.03.2012 17:14, Martin Thomson wrote:
> On 28 March 2012 05:55, Martin Thomson wrote:

All of which is countered with the tiny little fact that said 
green/padlock says nothing about whether the transaction is either 
confidential or private, or going where the user thinks its going. It 
merely says *a* trusted place is connected. Full stop, end of story, 
hand your corporate admin a credit card number to continue.

The amount of trust that users are being taught to place in such 
simplistic arbitrary green/yellow/red colorations far out of sync with 
reality of what they mean.

I completely agree that this needs to be addressed, but the transport 
appears to be doing everything right so far. We have port-443 with 
mandatory TLS. We have Upgrade: to roll out TLS into the unsecured 
areas. We have ubiquitous HTTP middleware capable of receiving and 
sending TLS hop-by-hop or end-to-end as desired. It is the 
implementations which are lagging in support or opting out of using 
security far too often for comfort.

AYJ

---

From: Henry Story <[email-masked]>
Date: Wed, 28 Mar 2012 08:06:35 +0200

> content can then potentially poison the entire page.

That is the problem of the web in general. As long as most pages
are not secured you have the mixed content problem. Even 100% TLS sites
have it. But this is a reason to make the move to 100% https everywhere. 

For example if I  am reading a  blog from an author I trust and he writes 
a review of his good experience shopping in some small company, a story I heard 
perhaps through other channels and have every reason to trust, and I 
click on the link to go to that site, but a man in the middle attacker
has replace the link to the site he was writing about with a link to his 
proxy (in order to take the money sent to the payment links he controls), 
then it will be very easy to fool me. I could well end up making a purchase 
at the fake site.  Even if the site in  question was 100% behind  https 
the links linking to it  could have been attacked, because the mixed content 
came from links linking TO the web site, which is how we and search engines 
navigate the web. 

That things are not completely broken shows how powerful the network of effect
of links is. But that same network effect will make a huge difference as 
people move TO TLS. On the web as in the world, we are not an islands. We work
as a society together, so that we get a huge boost of security as we secure
our follow citizens too, and as they secure themselves and us. 

> about:see draft-farrell-decade-ni.

Social Web Architect
http://bblfish.net/

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 28 Mar 2012 08:40:15 +0200

Hi,

On Wed, Mar 28, 2012 at 08:06:35AM +0200, Henry Story wrote:
> then it will be very easy to fool me.

I'm totally amazed by the fact that :
  a) people consider that the web is only *web pages* risking of being
     mangled by man-in-the-middle attacks, but don't consider all the
     other components that represent zero value but neet to be quickly
     delivered. Eg: off-site components such as visitor counters which
     nobody cares about but which should be very fast, or ads for which the
     ads providers don't necessarily want to inflate their infrastructure
     costs.

  b) we're keeping focused on the risk of having a blog page modified by
     an MITM while the *only* real issue right now (I mean what makes people
     *lose money* in the real world) is malware running in browsers and
     taking away all of their information or even acting as themselves on
     secure web sites. What's the point of securing blogs when connecting
     to banks over TLS is already unsafe ?

We'll just lower the overall security by applying the same security
enforcement to all sites. Connecting to your bank or to you WiFi
router's admin page will look equally safe. I don't think this is the
intent of this move, really.

Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 28 Mar 2012 07:00:43 +0000

In message <CABkgnnXW1Eke01W_xCBuyJrbx8uNT1K=[email-masked]>

>also rules out intermediation options that could be hugely beneficial.

You very well and clearly expressed my concerns about mandatory TLS.

One very simple way to gain integrity would be to add strong
signatures to web objects.

For the majority of web objects, this can be done once (every N
years).

Apart from a few extra bytes, there will be no HTTP-related overhead
and no negative impact on non-munging intermediates

The client side can verify the signature if it feels like it, and
warn/err/ refuse if it doesn't receive the assurance it expects.

The only question I don't see an obvious answer to, is how to mark
in HTML that a given link should have integrity checks, but I'm sure
W3C can solve that.

-- 
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, 28 Mar 2012 07:21:21 +0000

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

>appears to be doing everything right so far.

Everything, that is, except performance and choice.

There is no way to get around that mandatory TLS is overkill in
many high-volume applications, most notably p0rn.

If you want to kill HTTP/1.1, you have to make HTTP/2.0 a good idea
for the 50% of web traffic consisting of pink bits.

Second, there are places where TLS is simply not a good idea, either
because other security measures are in place, or because transparency
is specifically called for (Think: Flight Recorder).

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Wed, 28 Mar 2012 07:44:45 +0000

one thing I haven't seen discussed is the latency introduced in setup 
of TLS.
  
if you think TCP 3-way handshake is bad, TLS handshake adds at least 
another 2 full RTTs.
  
This means my 300ms connection to a (non geolocated) US site becomes a 
1s one.
  
I would have thought that ALONE would have been a show-stopper.

---

From: Henry Story <[email-masked]>
Date: Wed, 28 Mar 2012 09:53:35 +0200

>     to banks over TLS is already unsafe ?

That is the equivalent of the famous skeptical argument against the possibility 
of any knowledge in philosophy. The skeptic argues: given that you cannot 
distinguish your current situation from the way the world would seem to be had
you been kidnapped at night by aliens from Alpha Centauri, who had connected
your brain to highly evolved computer designed to feed you the sense impressions
you are having as you walk to a shop, which you would be falsely thinking you were
walking to, where you would in fact just be dreaming you were - given that you 
can never distinguish your situation from that one, it follows that you cannot know
at all. So argues the skeptic.

The parallel with your argument is clear. Substitute computer for brain, and malware
for alpha centaurians, and the argument becomes since the bank can never distinguish
between someone who is malware infested from someone who is not, why should they 
bother with security at all?

The answer in knowledge that Robert Nozick put forward is that knowledge is a modal 
concept, and that it does not follow from the statement that you don't know you 
are not a brain in the vat, that you don't know everyday statements. Knowledg is tracking
the truth in the closest possible worlds, not in the most far fetched ones. Of course if
alpha centaurions became a reality, then things would start getting hairy.

So your argument is stronger, since you argue that a lot of computers are malware
infested. Of course there the thing to do is for banks to add other methods of 
verification or notification, not to reduce security in connection and other places.
Ie, the solution is not to give up on knowledge in the traditional skeptical case,
or in your case on TLS, but to work on methods for reducing malware infested 
computers. And it could be that having TLS connections that mean that when I read
my friends blog his links don't get changed to point me to a malware infested site
will help me avoid the malware too. 

Security is a enterprise where one has to push back on many fronts simultaneously:
better connection security, better operating systems, better education of users, 
reduction of the need for password usage (since people mostly use the same), use 
of platforms like Java correctly so that they limit  access to resources on the 
OS, and limit connections, more attention in browser technologies to security, 
better warning systems, neighbourhood watch, avoidance of porn sites, ...

> router's admin page will look equally safe.

Ah it is the "look" of security that is worrying you? Going to a bank should
"look" more secure that your router's admin page? But your router admin page
should be just as secure as the bank if possible, since that is another vector
of attack. 

> I don't think this is the

Social Web Architect
http://bblfish.net/

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 28 Mar 2012 08:15:29 +0000

>intent of this move, really.

A very good observation:  If you don't make people able to distinguish
between high-value targets to protect and junk which they don't
care about, you've just made the banks and users security problems
much bigger.

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Wed, 28 Mar 2012 08:29:46 +0000

------ Original Message ------
From: "Henry Story" <[email-masked]>
>verification or notification,
>
you're right on this count.  One of my banks used to rely just on 
SSL/TLS.
  
Now I have to carry a watch-word around... in fact 3 of them for my 3 
banks.
  
Are you suggesting websites should all start issuing physical security 
devices so that people can enjoy their site with REAL security
  
or are you happy with the illusion.
  
Maybe a better metaphor would have been the Matrix.
  
We're not looking for blue pills here.
  
>should be just as secure as the bank if possible, since that is another vector
  
he meant the opposite.  We're not interested in something masquerading 
as security.  If we're going to place the cost on the world, it needs 
to provide actual security.

---

From: J Ross Nicoll <[email-masked]>
Date: Wed, 28 Mar 2012 09:48:25 +0100

I'd like to add low-power use cases (e.g. sensor networks) to that, as 
well, where the overhead of TLS is a non-trivial issue both in CPU time 
and battery power.

I maintain that if we try forcing TLS in HTTP 2.0, many people will 
complain, and then fork their own versions of HTTP 2.0 without TLS. Best 
case scenario is a single sensible standard that models HTTP without 
TLS, more likely we'll end up with 2-3 subtly incompatible versions and 
a huge stack of workarounds to hold the mess together.

Ross

On 28/03/2012 08:21, Poul-Henning Kamp wrote:
> Everything, that is, except performance and choice. There is no way to 
> get around that mandatory TLS is overkill in many high-volume 
> applications, most notably p0rn. If you want to kill HTTP/1.1, you 
> have to make HTTP/2.0 a good idea for the 50% of web traffic 
> consisting of pink bits. Second, there are places where TLS is simply 
> not a good idea, either because other security measures are in place, 
> or because transparency is specifically called for (Think: Flight 
> Recorder).

---

From: Henry Story <[email-masked]>
Date: Wed, 28 Mar 2012 12:16:38 +0200

On 28 Mar 2012, at 10:48, J Ross Nicoll wrote:

> I'd like to add low-power use cases (e.g. sensor networks) to that, as well, where the overhead of TLS is a non-trivial issue both in CPU time and battery power.

yes, that's why I was arguing for allowing TLS to be opt out.

> 
> I maintain that if we try forcing TLS in HTTP 2.0, many people will complain, and then fork their own versions of HTTP 2.0 without TLS. Best case scenario is a single sensible standard that models HTTP without TLS, more likely we'll end up with 2-3 subtly incompatible versions and a huge stack of workarounds to hold the mess together.
> 
> Ross
> 
>> Everything, that is, except performance and choice. There is no way to get around that mandatory TLS is overkill in many high-volume applications, most notably p0rn. If you want to kill HTTP/1.1, you have to make HTTP/2.0 a good idea for the 50% of web traffic consisting of pink bits. Second, there are places where TLS is simply not a good idea, either because other security measures are in place, or because transparency is specifically called for (Think: Flight Recorder). 
> 
> 

Social Web Architect
http://bblfish.net/

---

From: Henry Story <[email-masked]>
Date: Wed, 28 Mar 2012 12:15:31 +0200

> Now I have to carry a watch-word around... in fact 3 of them for my 3

They could also just use systems such as those they use for credit cards: to
look at usage patterns. Sending an SMS is also a good method, using a different
system.

Note that cell phones have a lot better security models that PCs I am just
learning at this identity conference in Swizerland, as they had things like 
Java build in, which can separate what downloaded apps can do.

If cell phones can also be identified with hardware cryptography then you can 
remove the need for extra passwords and just use TLS. 

> or are you happy with the illusion.

security is not an all or nothing question as your question assumes it is.
You are opposing "real security" with "illusory security", but in fact as
with knowledge you have more or less. You have deeper knowledge that someone
else, but never full knowledge. And we can only have the knowledge we
have in our society because we each of us know small pieces of the whole, and
we coordinate our work.

> Maybe a better metaphor would have been the Matrix.

The Matrix is indeed a very good film, that asks the
question of reality and illusion in a very entertaining way.

> We're not looking for blue pills here.

?
> to provide actual security.

I want actual security too to my router's admin page too. I don't think
I need all the extra verifications my bank may want to do too, by
looking at usage patterns and other things, but I don't think that
reduces security either. 

Though perhaps one could create a neighbourhood watch program for routers.
Or a friend-of-a-friend neighbourhood watch system...

Social Web Architect
http://bblfish.net/

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 28 Mar 2012 13:04:31 +0200

> look at usage patterns. Sending an SMS is also a good method, using a different

Believe me this is already been done. It looks like you have no idea
what the malware market is right now. did you hear about Zitmo for
instance. In short, malware in the mobile is already able to catch
your SMS and to correlate them with your PC session. Malware in the
browser is already able to record your soft cards after a few uses,
or to take snapshots of the areas you click on the screen and decode
virtual keyboards.

It's not science-fiction, it's for real. Right now it's not a big issue
only because banks resolve the issue pretty much in favor of the user.
For how long will this last ? I have no idea.

Sure we must secure the lower layer, but this is already been done
everywhere the bad is done.

Willy

---

From: Roberto Peon <[email-masked]>
Date: Wed, 28 Mar 2012 13:43:04 +0200

Ensuring security of the endpoints is probably outside the purvue of the
WG, however interesting it is.

That being said,  we should probably assume that the hosts aren't
compromised because otherwise it really doesn't matter what we do.

Our task is thus to somehow secure the communications channel. If you make
SSL implementation optional on the server side, you suffer from a downgrade
attack whereby an intermediary (potentially malicious), denies you all
security on the communications channel.
If this decision is made, it must be made by the client for the
client<->intermediary connection.

-=R

---

From: patrick mcmanus <[email-masked]>
Date: Wed, 28 Mar 2012 13:59:30 +0200

Martin, Great post. Thanks for the time it took to do it.

On 3/28/2012 6:14 AM, Martin Thomson wrote:
> On 28 March 2012 05:55, Martin Thomson<[email-masked]>  wrote:

I disagree pretty strongly that confidentiality is not a core desirable 
property for the web. I also lament that TLS only improves the situation 
partially.

Later in this thread Willy cites ad content as something that does not 
need confidentiality, but that would be a perfect exemplar imo of 
something that certainly does. The targetted ads a user receives 
disclose a great deal of information about you. The cookie that 
generates that ad lets a purely passive sniffer generate N more ads when 
captured, and the aggregate set of targetted ads paints an extensive 
invasion of privacy picture.

The notion that consumers of adult content don't care that their 
activities are broadcasts in detail to their friends and family is 
bizarre to me.  The great demand for various "private browsing" features 
in browsers are testament to this history.

I don't have a real objection to another closely related protocol that 
isn't for the web (and therefore not implemented by phones, browsers, 
etc..) but runs over IP that excludes some of this. But optionality 
isn't going to work as I think the current state of things illustrates well.
>> thinking about.  I'd like to see this discussed in HTTP/2.0.

I think this is a fine work item (and good idea!) for supporting the 
transition of mixed http/1 http/2 environments (and likely interesting 
in http/2 environments that aren't e2e secured) which clearly has to be 
part of the plan - mixed content is terrible, under-appreciated as a 
risk,  and should be a first tier concern. But resource integrity isn't 
the _only_ thing to worry about.

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 29 Mar 2012 01:41:23 +1300

On 29/03/2012 12:43 a.m., Roberto Peon wrote:
> Ensuring security of the endpoints is probably outside the purvue of 
> the WG, however interesting it is.
>
> Our task is thus to somehow secure the communications channel. If you 
> make SSL implementation optional on the server side, you suffer from a 
> downgrade attack whereby an intermediary (potentially malicious), 
> denies you all security on the communications channel.

This argument holds no water with intermediaries involved (legit or 
otherwise). Remember that intermediary plays the role of both client AND 
server simultaneously.  Sure the client can determine the strength of 
client<->intermediary security level. But then the intermediary has 
equal power to determine the weakness of intermediary<->server hop. 
Oops, malicious intermediary just downgraded the end-to-end security 
using the very control you gave the client. When the control is all 
one-sided (client OR server determining things) downgrade is easy.

It would be better for both security and integrity to allow both ends to 
prescribe their requirements. If either client or server is unable to 
comply with the others requirements TLS can't be used on that hop. 
Client must find another route in order to meet their policy needs. Very 
Expensive, but adds better assurity of real end-to-end security in 
comparison with trying to use TLS to bridge a weak intermediary node.
  Even with that strictest of strict security measures a malicious 
intermediary able to negotiate strong TLS with both ends can create a 
weak hop between the apparently secure ends.

The final solution boils down to a web of trust at a hop-by-hop level 
down the whole chain. How-to is up for grabs.

AYJ

---

From: Martin Thomson <[email-masked]>
Date: Wed, 28 Mar 2012 15:11:05 +0200

On 28 March 2012 13:43, Roberto Peon <[email-masked]> wrote:
> If you make

You can't downgrade https:// URIs now because it is non-negotiable, so
what's the threat model here?

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 28 Mar 2012 13:14:48 +0000

In message <[email-masked]>, patrick mcmanus writes:

>property for the web.

As is kittens, pink ponies and world peace.

However, in real life all things come at a price, and the price
of confidentiality is too high for certain classes of websites.

>bizarre to me.

I'm sure pornsites are willing to offer enhanced service for a
price, if there is a market, in fact I will absolutely guarantee
you that they will be the first to make money out of "nobody can
see you surf porn" if there is a market.

And just to be sure we're not talking past each other here:

There are two costs of TLS:  CPU cycles and latency.

Many sites will object to both of these, but most seem to focus
on the CPU cycles.

Latency is much more damaging, not so much for big sites like
Google, Yahoo and FaceBook which have data centers through out
the world, but for sites with just one webserver somewhere on
the world, the difference between 1*RTT and 4*RTT is a lot of
latency to throw at the user.

---

From: Mike Belshe <[email-masked]>
Date: Wed, 28 Mar 2012 15:30:29 +0200

> There are two costs of TLS:  CPU cycles and latency.

Thats the whole point of SPDY - we just handed you a protocol which embeds
SSL but is still has lower latency than HTTP.

> Many sites will object to both of these, but most seem to focus
These are cheap and getting cheaper every day.

> latency to throw at the user.

The higher the RTT, the bigger the win for SPDY.  So this claim is just
false.

Mike

---

From: Roberto Peon <[email-masked]>
Date: Wed, 28 Mar 2012 16:33:49 +0200

I'm very familiar with intermediaries, seeing as I develop one.
I'll be considering reverse proxies to be the equivalent of the server
endpoint for this conversation... because that is what they are!

It should be the user's choice about what level of security is *available*
between themselves and the first endpoint that they trust to be the entity
they're contacting. It could also be the servers, but, imho, only if you're
negotiating *up* to more secure.

In the case that I'm talking about, the malicious intermediary first must
be trusted as the endpoint to which the client is connecting.  Assuming you
can verify a cert, in the case where the client has chosen to use TLS, at
the least the communications channel between the client and the entity that
has proven themselves to be the entity in question via the cert is
trustable with whatever level of trust we have in the cert itself. The cert
trust stuff, as least far as I know, is also outside the purview of this
wg, despite being very interesting as well.

If you're using an explicit proxy (that being the only kind you can use
with TLS unless someone has installed new root certs and compromised your
endpoint), you are delegating trust to that proxy. The alternative is
simply to not use a proxy, or to not trust that proxy with any encryption
material that renders the data stream in the clear.
-=R

On Wed, Mar 28, 2012 at 2:41 PM, Amos Jeffries <[email-masked]> wrote:

>> downgrade attack whereby an intermediary (potentially malicious), denies
>> you all security on the communications channel.
> client<->intermediary security level. But then the intermediary has equal
> power to determine the weakness of intermediary<->server hop. Oops,
> malicious intermediary just downgraded the end-to-end security using the
> very control you gave the client. When the control is all one-sided (client
> OR server determining things) downgrade is easy.
>
> comply with the others requirements TLS can't be used on that hop. Client
> must find another route in order to meet their policy needs. Very
> intermediary able to negotiate strong TLS with both ends can create a weak
> hop between the apparently secure ends.
>
> The final solution boils down to a web of trust at a hop-by-hop level down
> the whole chain. How-to is up for grabs.
>
> AYJ
>
>

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 28 Mar 2012 17:53:16 +0000

In message <CABaLYCvguj3oycrv7uGKnMK_3fUYBU02JA=eH_W_F-w=[email-masked]>

>SSL but is still has lower latency than HTTP.

And I want a protocol with even lower latency, by taking some of the
good things about SPDY, and leaving behind the bad.

>These are cheap and getting cheaper every day.

"cheap is not the same as free".

It's not cheap if you have to sustain a slashdotting or redditing on SSL.

>The higher the RTT, the bigger the win for SPDY.  So this claim is just

Really ?

You found a way to negotiate TLS without any RTT cost ?

---

From: Roberto Peon <[email-masked]>
Date: Wed, 28 Mar 2012 20:05:52 +0200

> good things about SPDY, and leaving behind the bad.

Without SSL we'd not have a workable deployment today at all.

> It's not cheap if you have to sustain a slashdotting or redditing on SSL.

I'm not sure that SPDY with its one SSL today is more expensive than
today's HTTP with its 6 to 40-something connections per page.

> You found a way to negotiate TLS without any RTT cost ?

Actually, yes, however, snap-start was decided to be too complex to do for
the larger internet and so we dropped it.
I have every hope that we'll come up with something equivalent but better
in the future, though.

In any case, you're overlooking some data. Google's search deployment, for
instance, had users getting faster when we switched from HTTP to SPDY.

Poul-- what are you intending to optimize here? Are we optimizing for the
sum of the next ~15 years or for just tomorrow?

-=R

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 28 Mar 2012 18:22:10 +0000

In message <CAP+FsNeB8d0i=[email-masked]>

>today's HTTP with its 6 to 40-something connections per page.

You seem to miss the point:

There are at least four relevant protocols to discuss:

1. HTTP/1.1 as we know and hate it.

2. SPDY

3. A newly design HTTP/2.0 fast-bulk-transport.

4. The idea much better than 1, 2, & 3 nobody has thought about yet.

You talk as if there is only 1 & 2, ignoring #4 is particularly
shortsighted.

But lets stop beating about the bush:

SPDY is designed for Googles needs, and it probably serves Google well,
in particular by imposing end-to-end-TLS to keep telcos out of googls
data and giving end-to-end user identification.

But not everybody are Google, and just because Google hacked together
SPDY does not mean that it should be rammed through IETF the way
Microsoft managed to ram OOXML through ISO.

Right now we have two complementary HTTP protocols, and I think that
works because they are exactly that:  Complementary.  One offers
cryptographic services, the other offers speed.

I have *REPEATEDLY* tried to inject into the HTTP/2.0 discussion that
what we need are pluggable transport protocols, because the same
complementary needs exist and exactly to be future compatible.

HTTP/2.0 should be standardized as the semantics of the transported
messages, and the protocols which transport the messages.

Amongst these protocols should be one supporting crypto-services
and high-feature-levels, for the money-bearing transactions on
the web.  SPDY would fill that niche well I think.

But there also needs another to showel pink bits across the net
as fast as possible, with as little latency and overhead as possible,
so the big spikes are possible to serve. (Think CNN on 9/11!)

All I am really asking is that SPDY becomes *a* HTTP/2.0 transport,
rather than become *the* HTTP/2.0 transport.

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Wed, 28 Mar 2012 18:30:35 +0000

------ Original Message ------
From: "Mike Belshe" <[email-masked]>
To: "Poul-Henning Kamp" <[email-masked]>
Cc: "patrick mcmanus" <[email-masked]>;"[email-masked]" 
<[email-masked]>
Sent: 29/03/2012 2:30:29 a.m.
Subject: Re: The TLS hammer and resource integrity
>
>
>On Wed, Mar 28, 2012 at 3:14 PM, Poul-Henning Kamp <[email-masked]> wrote:
 
 Thats the whole point of SPDY - we just handed you a protocol which 
 embeds SSL but is still has lower latency than HTTP. 
  
how do you introduce more RTTs and reduce latency?  The 2 are 
incompatible.
  
Unless you're claiming that compression reduces transmission time due 
to smaller packets?
  
To which I would argue that the extra round trips in existing latent 
situations would far outweigh difference in packet transit time.  At 
least half the time added is due to extra acks.
  
If you can do "TLS" without sending and receiving TLS frames, 
negotiating ciphers, sending certs.  Then it's not TLS.
  
Another ENORMOUS cost is the burden of acquiring and managing 
certificates.
  
There are a lot of problems to be solved there before it's ready for ma 
and pa to install on their toaster.

Adrien

 
 The higher the RTT, the bigger the win for SPDY.  So this claim is 
 just false. 
 
 Mike

  --
  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: Roberto Peon <[email-masked]>
Date: Wed, 28 Mar 2012 23:30:03 +0200

On Wed, Mar 28, 2012 at 8:22 PM, Poul-Henning Kamp <[email-masked]>
 wrote:

> In message <CAP+FsNeB8d0i=
> [email-masked]>
> , Roberto Peon writes:
>

huh? I'm presenting data about what we know to be good or bad. I'm
perfectly receptive to things that are or will be better.... and my
impression is that we're arguing (and expressing different opinions) about
what we believe s better.

> Microsoft managed to ram OOXML through ISO.

I think we agree that *nothing* should be rammed through a standards body
(gosh, that sounds painful!), and that is why we're here!

The intent of SPDY was and is to make the web (all of it) better and faster
for all. The SPDY effort has been open basically from the get-go, and
inclusive of anyone who would contribute code, effort, and data.
One of the cute things about SPDY is that it was bound to enhance other
sites' performance more than Google's... so, all in all, I think that what
you said is a grossly unfair characterization.

> cryptographic services, the other offers speed.

The site's interests often conflict with the user's interests. Many sites
don't turn on HTTPS when it would clearly benefit the user. Many sites leak
auth cookies, etc. because they just don't know any better and their users
are increasingly eschewing landlines.

The interests don't always align... what behavior do we want to incent?

> so the big spikes are possible to serve. (Think CNN on 9/11!)

I think there are other and/or better solutions than getting rid of
security and privacy for the user. When I do the game theory:  a site which
can deploy a lower cost solution at the detriment of a user's privacy will
likely do so. Most businesses find local, not global maxima... Is that what
we want to incent?

> rather than become *the* HTTP/2.0 transport.

I'm only hoping that we take the lessons learned from the SPDY deployments
and not throw them away :)

We know SSL has a cost. It also has significant benefits for deployment and
user security /privacy.  I'm asking that we look at the motivations of the
various actors and ensure that the net result is in the user's interest.
This definitely includes second-order effects of the decisions. If we make
serving pages too expensive to bear, pages won't be served and the user's
interests won't be served. If we make pages reasonable expensive, and so
they're still served, and offer features that benefit the users and offer
something that shades more towards the global (instead of local) maximum..
that is a good final state.

-=R

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 28 Mar 2012 23:42:46 +0200

Hi Roberto,

> likely do so. Most businesses find local, not global maxima... Is that what

Not necessarily but similarly we don't necessarily want to decide for
the users that they need privacy where that really does not make sense
for them. If you have a widget on your TV displaying a beautiful clock
which looks nice in your living room, you don't care a dime that the
time of day is retrieved over HTTP and that someone else can see the
time you're seeing. I know that we can constantly invent a lot of made
up examples, my point is that we need to address the situations where
privacy is not a requirement. And I'm fairly certain that if we look
at many HTTP requests at a number of different places, we'd find a
significant percentage where there was no need for privacy protection
at all or where privacy was already addressed differently.

See you tomorrow,
Willy

---

From: patrick mcmanus <[email-masked]>
Date: Wed, 28 Mar 2012 23:59:06 +0200

On 3/28/2012 11:42 PM, Willy Tarreau wrote:
> time you're seeing.

You might care that someone else knows that you are seeing it (and are 
therefore present and watching your tv). Domestic violence prevention 
advocates care about this stuff a lot - TLS makes it better without 
completely fixing it. (i.e. you can see that there is some activity but 
you might not be able to distinguish from other less identifying 
automatic activity, or cannot associate it with a cookie that would tell 
you who was using what appliance, etc..)

the content provider is in no position to make this decision about the 
user's privacy and is certainly not incented to care. I want to build a 
web that at least mitigates passive sniffing attacks - we can do that 
now.  The state of things when we make security optional is just 
embarrassing.

---

From: Anthony Bryan <[email-masked]>
Date: Wed, 28 Mar 2012 18:35:54 -0400

> the content matches the content that it expects.

I may be misunderstanding, but with Metalink (RFC 6249) we use
Instance Digests (RFC 3230) for integrity, which is a HTTP header
field that includes hashes.

      Digest: md5=HUXZLQLMuI/KZ5KDcJPcOA==
      Digest: SHA=thvDyvhfIqlvFe+A9MYgxAfm1q5=,unixsum=30637

we also use the Link header field to provide duplicate locations of
files (on CDNs or mirror networks), digital signatures, and
peer-to-peer info (along with partial file hashes to aid in the repair
of large files).

   Etag: "thvDyvhfIqlvFe+A9MYgxAfm1q5="
   Link: <http://www2.example.com/example.ext>; rel=duplicate
   Link: <ftp://ftp.example.com/example.ext>; rel=duplicate
   Link: <http://example.com/example.ext.torrent>; rel=describedby;
   type="application/x-bittorrent"
   Link: <http://example.com/example.ext.meta4>; rel=describedby;
   type="application/metalink4+xml"
   Link: <http://example.com/example.ext.asc>; rel=describedby;
   type="application/pgp-signature"

> about:see draft-farrell-decade-ni.

sounds like a magnet link?

 magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C

http://en.wikipedia.org/wiki/Magnet_link

-- 
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
  )) Easier, More Reliable, Self Healing Downloads

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Wed, 28 Mar 2012 23:37:24 +0000

I think wherever a user-initiated activity is involved, the issue of 
privacy will be subjective.  So for whatever example is given, be it 
p0rn, ads whatever there is no universal right or wrong answer.
  
But there are several areas where it's just technical.
  
For instance, OCSP and CRL is delivered over HTTP.  This can't use 
SSL/TLS, else it creates a paradox - how do you validate the cert used 
to validate the cert (ad infinitum)?
  
Another topical issue relates to infrastructure providers and security 
concerns about eavesdropping.  Your network infrastructure starts 
phoning home using TLS and you'll have some nervous admins.  Some 
communication needs to be demonstrably open and transparent.
  
On the topic of OCSP, there's an existing issue relating to 
concentration of risk.  If you can break cert validation on millions of 
sites just by DDoSing a couple OCSP servers, then that will become a 
bigger problem as TLS gets rolled out.
  
The requirements to be able to issue certificates will need to be 
strengthened to enforce bullet-proof validation infrastructure.  We 
already have issues with access to OCSP servers for validation.
  
Adrien

------ Original Message ------
From: "patrick mcmanus" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: 29/03/2012 10:59:06 a.m.
Subject: Re: The TLS hammer and resource integrity
>completely fixing it. (i.e. you can see that there is some activity 
>but you might not be able to distinguish from other less identifying 
>automatic activity, or cannot associate it with a cookie that would 
>tell you who was using what appliance, etc..) 
>
>user's privacy and is certainly not incented to care. I want to build 
>a web that at least mitigates passive sniffing attacks - we can do 
>that now. The state of things when we make security optional is just 
>embarrassing. 
>
>
>
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 29 Mar 2012 05:48:28 +0200

>      Digest: SHA=thvDyvhfIqlvFe+A9MYgxAfm1q5=,unixsum=30637

That doesn't help someone who can't rely on the authenticity of the
communications medium.  That is, if you get the information over TLS,
you can trust it, but if you pass the information to me, then I have
to trust you quite a bit.

> sounds like a magnet link?

Exactly like in many respects.  I can't believe that decade is
ignorant of this, though I haven't been following the work closely.

---

From: Henry Story <[email-masked]>
Date: Thu, 29 Mar 2012 08:12:36 +0200

> communication needs to be demonstrably open and transparent.

It is also possible to have TLS with no encryption, guaranteeing 
message integrity but not confidentiality.

> concentration of risk.  If you can break cert validation on millions of sites just by DDoSing a couple OCSP servers, then that will become a

Social Web Architect
http://bblfish.net/

---

From: patrick mcmanus <[email-masked]>
Date: Thu, 29 Mar 2012 08:47:24 +0200

> to validate the cert (ad infinitum)?

There are a number of possibilities to bootstrap. Stapling is one of 
them. We're seeing even on the current internet that plain http is 
unreliable for this.

> communication needs to be demonstrably open and transparent.

It is an important point that when I (and others in this thread) 
advocate for SSL-everywhere we do not necessarily mean e2e. The working 
group needs to build mechanisms for opting into local intermediaries 
where the client knows that that is happening in a trusted way, has 
control over what goes e2e and what does not, and still maintains some 
kind of insight into the e2e trust chain. That is tricky work that in no 
way am I suggesting has been done - but it is doable. There will always 
be places where inspection is the law - we just need to build a system 
where that happens based on consent (where the other  choice may 
certainly be "no-access"), instead of silently and passively and that it 
constrains passive attacks to the minimum set. (i.e. My university 
requires traffic inspection that I consent to, that doesn't mean I 
should use plain text so that the whole student body can also do their 
own traffic inspection).

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 29 Mar 2012 06:46:38 +0000

>therefore present and watching your tv).

You seem to forget that it takes two to tango:  There is a client and
a server.  The server might not be wanting, able or even legally allowed
to use crypto.

---

From: Henry Story <[email-masked]>
Date: Thu, 29 Mar 2012 09:13:45 +0200

> a server.  The server might not be wanting, able or even legally allowed

You mean the server may not be allowed to use crypto for encryption. I seriously
doubt a server may not be allowed to use crypto for integrity and identity. TLS
allows crypto to be used for integrity and identity without confidentiality. 
User interfaces do need to be improved to make this visible, but it is available.

Social Web Architect
http://bblfish.net/

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 29 Mar 2012 07:20:10 +0000

In message <[email-masked]>, Henry Story writ
es:

>You mean the server may not be allowed to use crypto for encryption. I 
>seriously doubt a server may not be allowed to use crypto for integrity and 
>identity. TLS allows crypto to be used for integrity and identity without 
>confidentiality. 

You seem to forget that certain services are based on plausible deniability.
Adding integrity proving metadata would not work for them.

But at the bottom of this argument is a much more fundamental question
which you still have not answered:

You and which army is going to make people switch from HTTP/1.1 to
HTTP/2.0 if they don't think it is an improvement ?

Remember that HTTP/2.0 is an offer we can make, not a law we can enforce.

See also:  OSI protocols, IPv6 etc.

---

From: Robert Collins <[email-masked]>
Date: Thu, 29 Mar 2012 20:49:40 +1300

> Remember that HTTP/2.0 is an offer we can make, not a law we can enforce.

Its entirely possible as the risks of unencrypted traffic grow, that
jurisdictions will bring in legislation that makes it illegal *not* to
take reasonable steps to protect the personal information of users of
a service. I'd be surprised in fact, if some interpretations of
existing privacy and data protection law wouldn't in fact find
negligence on any service not using TLS.

So, while it is true that *one* factor we have to consider when
assessing *concrete proposals* is whether the proposal as a whole will
be seen as an improvement by *most* HTTP implementors, there is scant
evidence today that either:
 a) requiring TLS would make it 'not an improvement' for most implementors
or
 b) not requiring TLS would make it 'not an improvement' for most implementors.

With the exception of the netflix statement, the only evidence I've
seen put forward here is, frankly hearsay and hyperbole.

We should focus on creating the key criteria we're going to judge the
concrete proposals on. There have been some very good things mentioned
in passing as far as TLS goes:
 - the ability to run an implementation on resource constrained
hardware - sheevaplugs, for instance
 - the ability to have mass market consumer goods, like ADSL gateways,
which roll off a factory line with identical images.
 - the ability for any device on the internet to be a HTTP/2.0 end
point without requiring a central registry (either explicit or
defacto) for such devices.
 - keeping performance in mind: .nz to .uk traffic already pays a high
setup premium for small HTTP objects, making the *overall* user
experience suffer would be a sure way to make HTTP/2.0 unpopular for
many folk.

So, even if we can't agree on TLS/noTLS *today*, can we at least agree
that the criteria above are important - and I'm sure there are many
more such criteria that can be extracted from the conversation so far.

-Rob

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 29 Mar 2012 07:58:04 +0000

In message <CAJ3HoZ1bnmAs=[email-masked]>
, Robert Collins writes:

>a service.

Uhm, that is _already_ the case in EU.

HTTPS works fine for that.

>be seen as an improvement by *most* HTTP implementors, 

I don't think making TLS mandatory should be resolved on some kind of
pissing contest about what "most" means.

There are legitimate use cases for having TLS and for not having TLS
and we need to cater to both use cases if we want HTTP/2.0 to be
relevant.

IPv6 catered to only one end of the wire, and that's why it has taken
it 20 years to get nowhere.

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Thu, 29 Mar 2012 09:15:56 +0000

------ Original Message ------
From: "Robert Collins" <[email-masked]>
>negligence on any service not using TLS.
  
meanwhile other jurisdictions come to mind that force companies that 
provide secure systems to leave the country or shut down services until 
they can be made insecure.
  
Just talk to RIM about India or Saudi Arabia.
  
Many jurisdictions have laws requiring telcos to enable wire-tapping.  
Even NZ.
  
In other jurisdictions public use of crypto is outright illegal.
  
Wassenaar arrangement anyone?
  
Has anyone even discussed any of this with any government? You might be 
surprised. 
We can't make a shoe that will fit every foot.  Therefore we must allow 
choice.
>a) requiring TLS would make it 'not an improvement' for most implementors
  
have you ever worked on a support desk?
  
There's more to life than even just latency, reliability or CPU / 
memory load.
  
There's administrative burden and human and support cost.
  
People who can't even configure their email client are going to have to 
manage TLS servers.  IMO this can only be simplified for the masses at 
the expense of security.
  
>seen put forward here is, frankly hearsay and hyperbole.
There are plenty of improvements to be had without requiring TLS.  It's 
ironic you accuse all of us of hyperbole.
>experience suffer would be a sure way to make HTTP/2.0 unpopular for
  
Actually this isn't a bad start. I'd add a few more.
  
- keeping cost in mind (financial, human/time/support)
- debugging.  Currently I can debug HTTP issues with a packet sniffer.  
Good-bye to that with TLS.
- keeping supporting infrastructure requirements in mind.  
  
There's a heap of associated infrastructure for PKI.  We don't want to 
make the whole system more fragile.  What happens when a CA root 
private key is breached?  What happens if this coincides with a DoS 
attack on their OCSP servers?  We'll need a replacement protocol for 
OCSP, that's the relatively easy bit.
  
Compared to providers of things like DNS, or HTTP services, there are 
extremely few root CAs.  Moving everyone to TLS will make these few 
organisations linchpins for the whole internet.  Unlike the root DNS 
servers, cert validation is signed, and so can't be delegated (or can 
it?).
  
And proposals to use shared secrets instead of certs won't fly for the 
web where there are billions of peers.
  
In the end, we need to rely on trust.  That's all you're doing with TLS 
anyway.  Trusting the CA.
  
Once we accept that trust is required somewhere along the line, things 
should get a bit simpler.
  
Adrien