Subject: Some reasons why mandating use ofSSL for HTTP is a really bad idea

From: "Adrien W. de Croy" <[email-masked]>
Date: Wed, 18 Jul 2012 03:25:11 +0000

Mandating use of (c.f. support for) crypto in HTTP will prevent it from 
being deployable in a significant number of scenarios, thereby 
requiring ongoing use of HTTP/1.1.

DESIRABILITY OF PRIVACY

Proponents of mandatory crypto 
are making an assumption that privacy is ALWAYS desirable.

It is not ALWAYS desirable. 

In many cases privacy is undesirable or even illegal.

1. Many states have outlawed use of crypto.  So will this be HTTP only 
for the "free" societies?  Or is the IETF trying to achieve political 
change in "repressed" countries?  I've dealt with our equivalent of the 
NSA on this matter.  Have you?  I know the IETF has a neutral position 
on enabling wiretapping.  Mandating SSL is not a neutral / apolitical 
stance.  Steering HTTP into a collision course with governments just 
doesn't seem like much of a smart idea.

2. Most prisons do not allow inmates to have privacy when it comes to 
communications.  Would you deny [*] all prisoners access to the web?  
There are other scenarios where privacy is not expected, permitted or 
desirable.  

3. Many situations require communications to be open and visible.  
Would you rather your network infrastructure phoned home with SSL or 
HTTP that you can see.

4. Scanning for malware at a gateway.  This requirement is NOT going 
away, and the SSL will be brute-forced / spoofed etc to achieve this.  
Mandating SSL will just make it easier for malware to propagate, since 
you make it harder to scan [**].

COST

Google, Facebook and Twitter don't need to spend much on SSL certs from 
CAs.  Not in the scheme of things.

What about the other hundreds of millions of us running web servers.  
You gonna buy us our certs?  I better buy me some shares in Verisign et 
al..

SECURITY

Mandating SSL on all devices with HTTP stacks (e.g. your home network 
infrastructure, NAS, Modem etc) cannot be practically done while we 
rely on CAs to issue certs, and while those certs must be installed, 
expired, updated etc etc.

Or do you think manufacturers of such hardware should just ship with 
some default cert?  Self-signed maybe?  And while you're at it, why not 
get every machine in the world to trust that cert...  Oh dear, do we 
have a security problem?  

Frankly I think mandating SSL for all HTTP/2.0 will just break SSL for 
the world (or more likely consign HTTP/2.0 to relative obscurity).

It's been alluded to that we'd replace the CA infrastructure.  Don't 
you think it's premature to propose mandatory use of SSL when you 
haven't proposed what would replace the CA infrastructure yet?  That's 
like starting building a spaceship for Alpha Centauri based on a rocket 
engine that hasn't been invented yet.

You'd have to replace CRL and OCSP checking protocols, because they use 
HTTP, and mandating use of SSL for that would create a paradox (how do 
you check the cert on the connection used to check the cert ad 
infinitum).

OTHER

Most people here seem to focus on issues such as CPU load, extra R-Ts 
introduced by the SSL setup etc.  Those are valid concerns, but they 
are easier to overcome than the others. They aren't easy to overcome, 
just easier.

Seems to me it would be a whole lot simpler and more compatible with 
the actual world we actually live on just to make crypto optional.

Adrien

[*] We can't realistically expect server operators to indefinitely 
support both HTTP/2.0 and HTTP/1.1.  Some will inevitably drop HTTP/1.1 
support, and that part of the internet will then become unavailable to 
those forced to keep using HTTP/1.1, effectively denying those users.

[**] T
here has been some discussion about enabling intermediaries to be able 
to see plaintext payload by terminating the SSL connection at each end. 
  This hasn't progressed enough, and the current proposals still 
basically bypass intermediaries AFAICT.

---

From: Mike Belshe <[email-masked]>
Date: Tue, 17 Jul 2012 21:09:07 -0700

On Tue, Jul 17, 2012 at 8:25 PM, Adrien W. de Croy <[email-masked]> wrote:

> being deployable in a significant number of scenarios, thereby requiring
> ongoing use of HTTP/1.1.
>
>

This is true for any manifestation of HTTP/2.0 with or without security.

> 1. Many states have outlawed use of crypto.  So will this be HTTP only for
> the "free" societies?  Or is the IETF trying to achieve political change in
> "repressed" countries?  I've dealt with our equivalent of the NSA on this
> matter.  Have you?  I know the IETF has a neutral position on enabling
> wiretapping.  Mandating SSL is not a neutral / apolitical stance.  Steering
> HTTP into a collision course with governments just doesn't seem like much
> of a smart idea.
>

I don't know of states that prohibit TLS.  Do they exist?  Which ones are
they?  Can you list them?

Are you saying that HTTP/2.0 must be compliant with the laws of every
country?  And that any country passing a law making HTTP/2.0 features
illegal will block HTTP/2.0? :-)

Sites that are truly concerned can still negotiate the null cypher, I
suppose.

> communications.  Would you deny [*] all prisoners access to the web?  There
> are other scenarios where privacy is not expected, permitted or desirable.
>

I doubt this is a problem.  If it is, then the poor prisoners are already
being denied access to their banks, most all of which require TLS.

>
> 3. Many situations require communications to be open and visible.  Would
> you rather your network infrastructure phoned home with SSL or HTTP that
> you can see.
>

Can you enumerate these?  For debugging, of course it makes sense for
endpoints to have unencrypted modes.  We can also build better tools, such
as the improvements for decoding TLS traffic with Wireshark that have
landed recently.

>
> 4. Scanning for malware at a gateway.  This requirement is NOT going away,
> and the SSL will be brute-forced / spoofed etc to achieve this.  Mandating
> SSL will just make it easier for malware to propagate, since you make it
> harder to scan [**].
>

This problem exists today; IP leakage has to be checked even across TLS
based connections.  Solutions for these corporate IT groups exist,
including TLS aware proxies and TLS man in the middle.  Several vendors
provide these solutions today.

> CAs.  Not in the scheme of things.

Actually, this is not true.  These companies spend the most on "well
rooted" certificates.

>
> What about the other hundreds of millions of us running web servers.  You
> gonna buy us our certs?  I better buy me some shares in Verisign et al..
>

They are free - https://www.startssl.com/

> infrastructure, NAS, Modem etc) cannot be practically done while we rely on
> CAs to issue certs, and while those certs must be installed, expired,
> updated etc etc.
>

I think it can!

>
> Or do you think manufacturers of such hardware should just ship with some
> default cert?  Self-signed maybe?  And while you're at it, why not get
> every machine in the world to trust that cert...  Oh dear, do we have a
> security problem?
>

I think we could do self signed certs and also continue to improve the CA
infrastructure.  I'd like to see Google become a CA with a super-easy
certificate issuing process.

>
> Frankly I think mandating SSL for all HTTP/2.0 will just break SSL for the
> world (or more likely consign HTTP/2.0 to relative obscurity).
>

> It's been alluded to that we'd replace the CA infrastructure.  Don't you
> think it's premature to propose mandatory use of SSL when you haven't
> proposed what would replace the CA infrastructure yet?  That's like
> starting building a spaceship for Alpha Centauri based on a rocket engine
> that hasn't been invented yet.
>

Many researchers and security experts agree we need a CA overhaul.  But
this doesn't mean that the existing CA infrastructure is not usable.
 Despite its flaws, it is better than no CA system.  And we can fix it!
 Look at this as an opportunity, not a hurdle.

> HTTP, and mandating use of SSL for that would create a paradox (how do you
> check the cert on the connection used to check the cert ad infinitum).
>

Naw, the browsers wouldn't need to validate the cert from the OCSP server
because the contents that they fetch are self-signed and verifiable
independently.

> introduced by the SSL setup etc.  Those are valid concerns, but they are
> easier to overcome than the others. They aren't easy to overcome, just
> easier.
>

Agree.

>
>
> Seems to me it would be a whole lot simpler and more compatible with the
> actual world we actually live on just to make crypto optional.
>

True.  It would also be a whole lot less secure, leave users exposed on the
net to trust that every single website remembered to secure the
communicates of private data and that none of them use sniffable
cookies....

>
> Adrien
>
>
> [*] We can't realistically expect server operators to indefinitely support
> both HTTP/2.0 and HTTP/1.1.  Some will inevitably drop HTTP/1.1 support,
> and that part of the internet will then become unavailable to those forced
> to keep using HTTP/1.1, effectively denying those users.
>

Actually, HTTP/1.1 will become like IE6.  It will be this legacy thing
holding back the world.  Eventually there will be big pushes to rid the
world of this insecure protocol that we wish we no longer had lying around
:-)

>
>  [**] T
> here has been some discussion about enabling intermediaries to be able to
> see plaintext payload by terminating the SSL connection at each end.  This
> hasn't progressed enough, and the current proposals still basically bypass
> intermediaries AFAICT.
>
>

Agree it needs more work.  But I don't think this should be a condition of
making HTTP/2.0 a more secure protocol.

Mike

---

From: Grahame Grieve <[email-masked]>
Date: Wed, 18 Jul 2012 14:20:46 +1000

> endpoints to have unencrypted modes.

oh? but it was going to be mandatory. Except when it's not? which is it?
If it's mandatory by policy, but not technically actually required,
then... well..
I think I know how that will turn out.

Grahame

---

From: Mike Belshe <[email-masked]>
Date: Tue, 17 Jul 2012 21:24:09 -0700

> I think I know how that will turn out.

Naw - this is not a big deal.  For instance, a server can send a NULL
cipher to the client.  In normal modes, browsers will reject the NULL
cipher and not negotiate it.  however, you can use command line flags to
allow it.

We do this all the time.  Another example is for turning on
same-origin-policy.  Browsers often have debugging modes for turning it
off.  You have to run the browser in a special, techie, opt-in way to do
it, but it is there.

I used these all the time when developing in Chrome.

Mike

---

From: Mike Belshe <[email-masked]>
Date: Tue, 17 Jul 2012 21:43:57 -0700

On Tue, Jul 17, 2012 at 9:32 PM, Grahame Grieve <
[email-masked]> wrote:

> so, the client and the server SHALL use encryption, except when they
> choose not to?
>

No, they shall use TLS.  TLS may negotiate a null cipher if both endpoints
agree to it.

Mike

>
> Grahame
>
>
> On Wed, Jul 18, 2012 at 2:24 PM, Mike Belshe <[email-masked]> wrote:
> >
> >
> cipher
> > to the client.  In normal modes, browsers will reject the NULL cipher and
> > not negotiate it.  however, you can use command line flags to allow it.
> >
> off.
> > You have to run the browser in a special, techie, opt-in way to do it,
> but
> > it is there.
> >
> --
> -----
> http://www.healthintersections.com.au /
> [email-masked] / +61 411 867 065
>

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Wed, 18 Jul 2012 04:51:34 +0000

------ Original Message ------
From: "Mike Belshe" [email-masked]

> Mandating use of (c.f. support for) crypto in HTTP will prevent it 
> from being deployable in a significant number of scenarios, thereby 

 This is true for any manifestation of HTTP/2.0 with or without 
 security.

I don't know if it should be a goal though.  IMO the goal should be to 
replace the old with something better, not replace it with something 
that can only be used by a subset of current users, and therefore 
requires continued perpetual use of the old.

> 1. Many states have outlawed use of crypto.  So will this be HTTP 
> only for the "free" societies?  Or is the IETF trying to achieve 
> political change in "repressed" countries?  I've dealt with our 
> equivalent of the NSA on this matter.  Have you?  I know the IETF has 
> a neutral position on enabling wiretapping.  Mandating SSL is not a 
> neutral / apolitical stance.  Steering HTTP into a collision course 
> with governments just doesn't seem like much of a smart idea.
 
 I don't know of states that prohibit TLS.  Do they exist?  Which ones 
 are they?  Can you list them?

It's hard to get recent information, but my understanding is that a lot 
of of people live in jurisdictions where crypto is tightly controlled.

E.g. China, India, several mid-eastern and former soviet countries.
>illegal will block HTTP/2.0? :-)

In practice, we would have different levels of difficulty ignoring laws 
of a country depending on which country that was.

If the US passed a law that banned it, and threatened to put you in 
jail, you may give that more weight.

Governments already have wiretapping laws.  Do you think they will 
abandon that as a desire?
Many laws on crypto were only relatively recently relaxed.  There's an 
ongoing tussle between security agencies of government and privacy 
advocates over it.  We can't guarantee that within the next 5 years 
that any country wouldn't make it illegal.

It's not like we can claim there's no reasonable expectation to 
consider laws when it comes to crypto.  That's the one area of software 
development where caveats and warnings are stamped over so much code 
and documentation that we can't claim to be unaware it's an issue.

>Sites that are truly concerned can still negotiate the null cypher, I 

try finding some real client app that will swallow that.

> There are other scenarios where privacy is not expected, permitted or 
 
 I doubt this is a problem.  If it is, then the poor prisoners are 
 already being denied access to their banks, most all of which require 
 TLS.
Maybe there's not much sympathy for prisoners.  That's just one example.

Schools, homes and businesses are also places where there may be deemed 
(by those in charge) a need to monitor activity.

 Can you enumerate these?  For debugging, of course it makes sense for 
 endpoints to have unencrypted modes.  We can also build better tools, 
 such as the improvements for decoding TLS traffic with Wireshark that 
 have landed recently.

Can only decode NULL cipher.

Huawei recently got excluded from bidding for an Australian govt 
contract (a large one) due to concerns over possibility of 
eavesdropping.

Mandating privacy on HTTP will make it easier in some cases (e.g. 
infrastructure) to eavesdrop on non-private communication.

>  Mandating SSL will just make it easier for malware to propagate, 
> since you make it harder to scan [**].
 
 This problem exists today; IP leakage has to be checked even across 
 TLS based connections.  Solutions for these corporate IT groups exist, 
 including TLS aware proxies and TLS man in the middle.  Several 
 vendors provide these solutions today.

Sure.  But as previously discussed, the way it is done results in an 
overall reduction in security.  A "sanctioned" way would be much 
preferable, but necessarily reduces privacy potentially to 0.

And, do we want shared caches to continue to exist?

> Google, Facebook and Twitter don't need to spend much on SSL certs 
> from CAs.  Not in the scheme of things.

not compared to their revenues is what I meant.

> You gonna buy us our certs?  I better buy me some shares in Verisign 
> et al..

the thin edge of the wedge.  How can one have any faith in some entity 
vouching for some other entity when no payment is made (therefore no 
rigorous check can be made).

> expired, updated etc etc.
 
 I think it can!
I'm sure it can be made a lot easier.

I think maybe even it could be made easy enough for my mom to do it on 
her DSL modem web interface... er... maybe not....

> some default cert?  Self-signed maybe?  And while you're at it, why 
> not get every machine in the world to trust that cert...  Oh dear, do 
> we have a security problem? 
 
 I think we could do self signed certs and also continue to improve the 
 CA infrastructure.  I'd like to see Google become a CA with a 
 super-easy certificate issuing process.

I foresee a problem where OSes have too many trusted root certs to 
manage.  The more CAs and trusted root certs we end up with, the larger 
the attack surface for anyone trying to inject badness into the system.

No-one surely needs reminding about the recent CA breaches and bad 
certs issued.

Security is only as strong as the weakest link, which is invariably us. 
  I don't know what we're aiming for, security or a false sense of it.

> Frankly I think mandating SSL for all HTTP/2.0 will just break SSL 
> for the world (or more likely consign HTTP/2.0 to relative 
> obscurity). 

  It's been alluded to that we'd replace the CA infrastructure.  Don't 
  you think it's premature to propose mandatory use of SSL when you 
  haven't proposed what would replace the CA infrastructure yet?  
  That's like starting building a spaceship for Alpha Centauri based on 
  a rocket engine that hasn't been invented yet.
 
 Many researchers and security experts agree we need a CA overhaul.  
 But this doesn't mean that the existing CA infrastructure is not 
 usable.  Despite its flaws, it is better than no CA system.  And we 
 can fix it!  Look at this as an opportunity, not a hurdle.
I'd love to fix it.  Not sure how though.

> You'd have to replace CRL and OCSP checking protocols, because they 
> use HTTP, and mandating use of SSL for that would create a paradox 
> (how do you check the cert on the connection used to check the cert 
> ad infinitum).
 
 Naw, the browsers wouldn't need to validate the cert from the OCSP 
 server because the contents that they fetch are self-signed and 
 verifiable independently.
verifiable independently?  With certs?  How do you check those?

Or do we rely on DNS for that?

 
 Agree.

 True.  It would also be a whole lot less secure, leave users exposed 
 on the net to trust that every single website remembered to secure the 
 communicates of private data and that none of them use sniffable 
 cookies....  

The current situation is really that bad?

> support both HTTP/2.0 and HTTP/1.1.  Some will inevitably drop 
> HTTP/1.1 support, and that part of the internet will then become 
> unavailable to those forced to keep using HTTP/1.1, effectively 
> denying those users.
 
 Actually, HTTP/1.1 will become like IE6.  It will be this legacy thing 
 holding back the world.  Eventually there will be big pushes to rid 
 the world of this insecure protocol that we wish we no longer had 
 lying around :-)

  [**] T
  here has been some discussion about enabling intermediaries to be 
  able to see plaintext payload by terminating the SSL connection at 
  each end.  This hasn't progressed enough, and the current proposals 
  still basically bypass intermediaries AFAICT.

 Agree it needs more work.  But I don't think this should be a 
 condition of making HTTP/2.0 a more secure protocol.

My main issue is not with security or privacy, but only relating to 
mandating the USE of it.

Adrien

---

From: Mike Belshe <[email-masked]>
Date: Tue, 17 Jul 2012 22:09:29 -0700

On Tue, Jul 17, 2012 at 9:51 PM, Adrien W. de Croy <[email-masked]> wrote:

> On Tue, Jul 17, 2012 at 8:25 PM, Adrien W. de Croy < <[email-masked]>
> [email-masked]> wrote:
>
>>
> replace the old with something better, not replace it with something that
> can only be used by a subset of current users, and therefore requires
> continued perpetual use of the old.
>

Agree; goal should be to be better.  That doesn't mean that I think
everyone will jump to it in short order, though.

>> change in "repressed" countries?  I've dealt with our equivalent of the NSA
>> on this matter.  Have you?  I know the IETF has a neutral position on
>> enabling wiretapping.  Mandating SSL is not a neutral / apolitical stance.
>> Steering HTTP into a collision course with governments just doesn't seem
>> like much of a smart idea.
>>
>
> It's hard to get recent information, but my understanding is that a lot of
> of people live in jurisdictions where crypto is tightly controlled.
>
> If the US passed a law that banned it, and threatened to put you in jail,
> you may give that more weight.
>
> Governments already have wiretapping laws.  Do you think they will abandon
> that as a desire?
> advocates over it.  We can't guarantee that within the next 5 years that
> any country wouldn't make it illegal.
>
> It's not like we can claim there's no reasonable expectation to consider
> laws when it comes to crypto.  That's the one area of software development
> where caveats and warnings are stamped over so much code and documentation
> that we can't claim to be unaware it's an issue.
>

Well, when you've got a specific country to talk about, please raise the
issue.

> try finding some real client app that will swallow that.

you are right :-)

> (by those in charge) a need to monitor activity.

They already have this problem.  Twitter, Google, and Facebook have all
publicly declared that they are working their way to 100% TLS all the time.
 These issues exist today.  If you want to filter TLS, you can; several
vendors provide solutions.

But schools have bigger problems - like those cell phones with more
bandwidth than the school has to its classrooms.

I don't think the protocol has an obligation to reduce security so that
prisons, schools, or other institutions can institute content control.
And by the time this standard is done, the policy rules will have changed
again.

A simple thing we do know is that users expect and deserve to be protected
by the protocols and sites they visit.  We're passing more laws every day
to ensure this - and HTTP can help.

> Can only decode NULL cipher.

With wireshark you can decide SSL session if you let your browser dump the
private keys.  Chrome supports this.
http://www.imperialviolet.org/2012/06/25/wireshark.html

>
> Huawei recently got excluded from bidding for an Australian govt contract
> (a large one) due to concerns over possibility of eavesdropping.
>

Excellent point for why we should make the protocol more secure :-)  If
everything were encrypted, it wouldn't have been a problem.

> infrastructure) to eavesdrop on non-private communication.

What?  Mandating privacy makes it easier to eavesdrop?  I don't think so :-)

>> Mandating SSL will just make it easier for malware to propagate, since you
>> make it harder to scan [**].
>>
>

I disagree that it takes privacy to zero.  The end user will be aware of
such changes; these are only possible by changing the trust points in the
browser.  If your company gives you a browser, it can change your trust
points.  But if it is your own browser, you pick the trust points.

I agree this is obscure, but it is something we can improve upon.  I agree
that we should.

Until we turn on SSL for everyone, it won't likely get improved.

> And, do we want shared caches to continue to exist?

Of course we do.  We switch to opt-in proxies (like what Roberto Peon has
proposed) rather than the transparent proxies that we have today.  These
are much better because the user has the opportunity to know the proxy is
there, unlike today.  Personally, the security risks of using such a proxy
probably outweigh the performance advantages for most people.  This is
similar in concept to what Douglas Beaver articulated so well in a separate
thread.

Mike

> gonna buy us our certs?  I better buy me some shares in Verisign et al..

They are free - <https://www.startssl.com/>https://www.startssl.com/

I think it can!

I think maybe even it could be made easy enough for my mom to do it on her
DSL modem web interface... er... maybe not....

I foresee a problem where OSes have too many trusted root certs to manage.
The more CAs and trusted root certs we end up with, the larger the attack
surface for anyone trying to inject badness into the system.

No-one surely needs reminding about the recent CA breaches and bad certs
issued.

Security is only as strong as the weakest link, which is invariably us.  I
don't know what we're aiming for, security or a false sense of it.

Agree.

Adrien

Mike

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Wed, 18 Jul 2012 05:43:32 +0000

------ Original Message ------

> I don't know if it should be a goal though.  IMO the goal should be 
> to replace the old with something better, not replace it with 
> something that can only be used by a subset of current users, and 
> therefore requires continued perpetual use of the old.
 
 Agree; goal should be to be better.  That doesn't mean that I think 
 everyone will jump to it in short order, though. 
I don't expect anything to be jumped to in short order.

> > equivalent of the NSA on this matter.  Have you?  I know the IETF 
> > has a neutral position on enabling wiretapping.  Mandating SSL is 
> > not a neutral / apolitical stance.  Steering HTTP into a collision 
> > course with governments just doesn't seem like much of a smart idea.
 > 
 > I don't know of states that prohibit TLS.  Do they exist?  Which 
 > ones are they?  Can you list them?

> It's hard to get recent information, but my understanding is that a 
> lot of of people live in jurisdictions where crypto is tightly 
> controlled.

> >Are you saying that HTTP/2.0 must be compliant with the laws of 
> >every country?  And that any country passing a law making HTTP/2.0 
> >features illegal will block HTTP/2.0? :-)

 >In practice, we would have different levels of difficulty ignoring 
 >laws of a country depending on which country that was.

 >Many laws on crypto were only relatively recently relaxed.  There's 
 >an ongoing tussle between security agencies of government and privacy 

 >consider laws when it comes to crypto.  That's the one area of 
 >software development where caveats and warnings are stamped over so 
 >much code and documentation that we can't claim to be unaware it's an 
 >issue.
>
>
>Well, when you've got a specific country to talk about, please raise 
>the issue.
Maybe someone from one of the countries I listed above would be in a 
better position to comment than I am.

> > 2. Most prisons do not allow inmates to have privacy when it comes 
> > to communications.  Would you deny [*] all prisoners access to the 
> > web?  There are other scenarios where privacy is not expected, 
> > permitted or desirable. 
 > 
 > already being denied access to their banks, most all of which 
 > require TLS.

> Schools, homes and businesses are also places where there may be 
> deemed (by those in charge) a need to monitor activity.
 
 They already have this problem.  Twitter, Google, and Facebook have 
 all publicly declared that they are working their way to 100% TLS all 
 the time.  These issues exist today.  If you want to filter TLS, you 
 can; several vendors provide solutions.
Sure, and as said before, this is not without security implications.

>bandwidth than the school has to its classrooms.  
Many schools ban cellphones.  My son's school does.

>
>I don't think the protocol has an obligation to reduce security so 
>that prisons, schools, or other institutions can institute content 
>control.   And by the time this standard is done, the policy rules 
>will have changed again.

I'm not proposing we take the current level of security of HTTP/1.1 and 
reduce it.

you're proposing we add TLS.  Whilst that will provide a level of 
privacy in many cases, I don't think it will overall result in an 
improved security situation overall, especially if it breaks SSL/TLS.  
I kinda like SSL/TLS, I'd like it to continue to be usable.
>
>A simple thing we do know is that users expect and deserve to be 
>protected by the protocols and sites they visit.  We're passing more 
>laws every day to ensure this - and HTTP can help.

rubbish, we know no such thing.

all users are not equal.  All users are not equally deserving of 
privacy in all situations.

> > Would you rather your network infrastructure phoned home with SSL 
> > or HTTP that you can see.
 > 
 > Can you enumerate these?  For debugging, of course it makes sense 
 > for endpoints to have unencrypted modes.  We can also build better 
 > tools, such as the improvements for decoding TLS traffic with 
 > Wireshark that have landed recently.

> Can only decode NULL cipher.
 
 With wireshark you can decide SSL session if you let your browser dump 
 the private keys.  Chrome supports this.  http://www.imperialviolet.org/2012/06/25/wireshark.html

OK, well let's hope we never have to debug any protocol - level stuff 
with any other client software.

> contract (a large one) due to concerns over possibility of 
 
 Excellent point for why we should make the protocol more secure :-)  
 If everything were encrypted, it wouldn't have been a problem. 
Sure, anything sensitive should be encrypted before it goes over that 
infrastructure.  But I'm sure some large equipment vendor was lobbying 
somewhere.

> infrastructure) to eavesdrop on non-private communication.
 
 What?  Mandating privacy makes it easier to eavesdrop?  I don't think 
 so :-)

sure it does.  How can you tell if something is spyware or 
eavesdropping on you if you can't see if the phone home data is a 
version check or a report of your activity because it's encrypted?

If my phone-home data is plaintext HTTP, I can demonstrate it's not 
eavesdropping.

> > 4. Scanning for malware at a gateway.  This requirement is NOT 
> > going away, and the SSL will be brute-forced / spoofed etc to 
> > achieve this.  Mandating SSL will just make it easier for malware 
> > to propagate, since you make it harder to scan [**].
 > 
 > TLS based connections.  Solutions for these corporate IT groups 
 > exist, including TLS aware proxies and TLS man in the middle.  
 > Several vendors provide these solutions today.

> preferable, but necessarily reduces privacy potentially to 0.
 
 I disagree that it takes privacy to zero. 
I said potentially.  If you let your company see your data because they 
operate the proxy that terminates the SSL connection from the browser, 
then your expectation of privacy (from your company) is potentially 0.

Companies will continue to insist on scanning or blocking. 
> The end user will be aware of such changes; these are only possible 
>by changing the trust points in the browser.  If your company gives 
>you a browser, it can change your trust points.  But if it is your own 
>browser, you pick the trust points.
>
>I agree this is obscure, but it is something we can improve upon.  I 
>agree that we should.
>

Yeah I dunno, I think we could improve it independently of that.

> And, do we want shared caches to continue to exist?
 
 Of course we do.  We switch to opt-in proxies (like what Roberto Peon 
 has proposed) rather than the transparent proxies that we have today.  
 These are much better because the user has the opportunity to know the 
 proxy is there, unlike today.  
We've been recommending against using transparent proxying for years.  
Unfortunately that doesn't reduce demand for it.

proxy discovery needs to be greatly improved.

But even with explicit proxy use by the client, for SSL/TLS that just 
boils down to HTTP CONNECT, which bypasses the proxy anyway.

>Personally, the security risks of using such a proxy probably outweigh 
>the performance advantages for most people.

Using a home or corporate proxy has security risks that outweigh 
benefits of shared cache and scanning????

Problem is, the people who operate these proxies think differently to 
you.  They want to see and scan everything.  They don't care so much 
about privacy on their LAN. 

They also may pay for data, so they want to cache.

Wireless hotspots is a different issue of course, something needs to be 
done about that.

>  This is similar in concept to what Douglas Beaver articulated so 
>well in a separate thread.
>

 >  You gonna buy us our certs?  I better buy me some shares in 
 > Verisign et al..
> 

 > Mandating SSL on all devices with HTTP stacks (e.g. your home 
 > network infrastructure, NAS, Modem etc) cannot be practically done 
 > while we rely on CAs to issue certs, and while those certs must be 
 > installed, expired, updated etc etc.
> 
> I think it can!

 > not get every machine in the world to trust that cert...  Oh dear, 
 > do we have a security problem? 
> 
> I think we could do self signed certs and also continue to improve 
> the CA infrastructure.  I'd like to see Google become a CA with a 

 I foresee a problem where OSes have too many trusted root certs to 
 manage.  The more CAs and trusted root certs we end up with, the 
 larger the attack surface for anyone trying to inject badness into the 
 system.

 Security is only as strong as the weakest link, which is invariably 
 us.  I don't know what we're aiming for, security or a false sense of 
 it.

>  That's like starting building a spaceship for Alpha Centauri based 
>  on a rocket engine that hasn't been invented yet.

 > Most people here seem to focus on issues such as CPU load, extra 
 > R-Ts introduced by the SSL setup etc.  Those are valid concerns, but 
 > they are easier to overcome than the others. They aren't easy to 
 > overcome, just easier.
> 
> Agree.

  True.  It would also be a whole lot less secure, leave users exposed 
  on the net to trust that every single website remembered to secure 
  the communicates of private data and that none of them use sniffable 
  cookies....  

> Actually, HTTP/1.1 will become like IE6.  It will be this legacy 
> thing holding back the world.  Eventually there will be big pushes to 
> rid the world of this insecure protocol that we wish we no longer had 
> lying around :-)

 Adrien

---

From: James M Snell <[email-masked]>
Date: Tue, 17 Jul 2012 23:10:40 -0700

On Tue, Jul 17, 2012 at 9:09 PM, Mike Belshe <[email-masked]> wrote:

> [snip]

FWIW, the California Department of Corrections restricts prisoners from
using the network connected computers at any time, let alone access the
Internet. I believe similar policies are in effect in most states across
the country. Of course... I can only speak for regulations within the U.S.

Still no where near convinced that mandatory TLS is even remotely
worthwhile. There are simply too many perfectly valid cases where it's
completely unnecessary and downright silly to assume it's needed.

There is no evidence, that I have seen, that demonstrates that Mandatory
TLS would make HTTP/2.0 any more secure than optional TLS.

- James

> True.  It would also be a whole lot less secure, leave users exposed on
> the net to trust that every single website remembered to secure the

---

From: James M Snell <[email-masked]>
Date: Tue, 17 Jul 2012 23:35:58 -0700

> Well, when you've got a specific country to talk about, please raise the
Well.. there's China for one.. A quick google search reveals that current
Chinese IT Law apparently forbids Chinese citizens from utilizing
self-developed encryption products and in fact must seek the governments
permission to purchase and use any product that provides encryption
services. Requiring TLS for SPDY would, apparently, make it effectively
illegal for anyone in China to roll their own HTTP/2.0 implementation
without getting the governments approval. Now I'm far from being an expert
on Chinese IT Law but that seems rather counter productive to me.

- James

---

From: Mike Belshe <[email-masked]>
Date: Tue, 17 Jul 2012 23:39:01 -0700

I won't comment on most of this - I think we've each made our points and
will need to respectfully disagree.  One last point below.

On Tue, Jul 17, 2012 at 10:43 PM, Adrien W. de Croy <[email-masked]> wrote:

> On Tue, Jul 17, 2012 at 9:51 PM, Adrien W. de Croy < <[email-masked]>
> [email-masked]> wrote:
>
>>
>> From: "Mike Belshe" <[email-masked]>[email-masked]
>>
>>
>>
>> On Tue, Jul 17, 2012 at 8:25 PM, Adrien W. de Croy < <[email-masked]><[email-masked]>
>> [email-masked]> wrote:
>>
>>>
> you're proposing we add TLS.  Whilst that will provide a level of privacy
> in many cases, I don't think it will overall result in an improved security
> situation overall, especially if it breaks SSL/TLS.  I kinda like SSL/TLS,
> I'd like it to continue to be usable.
>
>
> all users are not equal.  All users are not equally deserving of privacy
> in all situations.
>
>
>
>
>
>
>>
>>
>>
>>
>>>
> private keys.  Chrome supports this.  <http://www.imperialviolet.org/2012/06/25/wireshark.html>
> OK, well let's hope we never have to debug any protocol - level stuff with
> any other client software.
>
>
>
>
>
>>
> sure it does.  How can you tell if something is spyware or eavesdropping
> on you if you can't see if the phone home data is a version check or a
> report of your activity because it's encrypted?
>
> operate the proxy that terminates the SSL connection from the browser, then
> your expectation of privacy (from your company) is potentially 0.
>
>   The end user will be aware of such changes; these are only possible by
> changing the trust points in the browser.  If your company gives you a
> browser, it can change your trust points.  But if it is your own browser,
> you pick the trust points.
>
> there, unlike today.
> Using a home or corporate proxy has security risks that outweigh benefits
> of shared cache and scanning????
>
> you.  They want to see and scan everything.  They don't care so much about
> privacy on their LAN.
>

Aha - this is the crux indeed.  This is the advocated position of the
"people that operate these proxies".

I'm taking the position of the user.  I want the user to be able to know if
someone is spying on them in all cases.   I think censorship and alteration
of content is such a huge risk to us as a free people that we simply cannot
tolerate not knowing who is scanning our lines.  We must must must know it.

I have yet to find a single user that wants their communications to be
sniffed and potentially altered by third parties without their knowledge.
 Do you want that for your own data?

Now, I'm not trying to block the proxy operators you mention.  I just want
the users to be made aware of their presence, so that users can decide for
themselves whether it is ok (because its their boss on their company
computer) or not (because its someone at my telco).

We do have a choice here - safety for the users vs. enabling of transparent
snooping for anyone.

I choose the users 100% of the time.
Mike

>    This is similar in concept to what Douglas Beaver articulated so well
> in a separate thread.
>
>
>
>
>>
>> COST
>>
> They are free - <https://www.startssl.com/> <https://www.startssl.com/>
> https://www.startssl.com/
>
>
> manage.  The more CAs and trusted root certs we end up with, the larger the
> attack surface for anyone trying to inject badness into the system.
>

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 18 Jul 2012 08:02:21 +0000

In message <CABaLYCuyjE8TRHHk2O0sY4ocB=LmK7S6LrDYc1=[email-masked]>
, Mike Belshe writes:

>someone is spying on them in all cases.

This has been a long thread already, so I will try to make this short
and to the point.

1. I think Mike has a very valid point here, but it's not our job,
   and we could not solve the problem if it were.

   I would express it slightly differently than Mike: "If it looks
   like privacy, the user should be able to know definitively if
   it is end-to-end privacy or not."

   I'm not a card-carrying cryptographer, but it's my clear perception
   that the currently perverted and corrupt CA system deliberately
   makes that ideal very hard if not impossible.

2. There are legitimate (or legitimized) reasons for intercept.

   In the cases where the intercept is not covert, it is in the
   interest also of the interceptor, that no unnecessary weaknesses
   are introduced.

   This indicates an operating mode where the user is told "You
   have privacy only as far as SNOOP_PROXY, what happens after that
   depends on what SNOOP_PROXY does."

   Or the probably more likely case: "You have no privacy from here
   to CORP_PROXY, but CORP_PROXY claims that you have privacy from
   there to the destination."

   If I'm an employee, or inmate, that's just the rules of the game,
   but the important thing is that as a user I'm precisely and
   correctly communicated the reality of the game.

   I belive this is more or less just a matter of allowing 
	GET https://blablabla HTTP/1.1
   to proxies, but I defer fully to Adrian on this.

3. There are objective indications that TLS is not always an advantage.

   Some have been mentioned already, I'll just add another:  High
   reliability safety-of-life critical systems, such as power distribution,
   air traffic control and emergency services.

   Putting a 2 meter airgap around such a system is currently
   considered the best practice way to implement both high reliability
   and high security.

   The added failure modes of certificates, which are opaque and
   hard/impossible to debug & correct on the kind of timescales
   relevant (< 3 minutes) are not welcome.  SSH is tolerated, but
   with very strict password registration and disclosure policies,
   and often with NULL block-ciphers, to make network flight recorders
   usable.

   Mandating TLS in HTTP/2.0 will effectively force these installations
   to stick with HTTP/1.1, in order to be able to do accident
   investigations.

4. It is not our job, and it is counter productive.

   Cryptography is a layer 8-10 problem more than anything on the
   internet.

   If we tangle HTTP/2.0 into layers 8-10, it will become subject
   for discussion at diplomatic levels, will raise issues about
   ITAR rules and will meet a lot of push-back from all sorts of
   shady agendas, not to mention a damn good headline in a clueless
   press.

   Trying to mandate TLS with HTTP/2.0 would therefore be a major
   drag on HTTP/2.0's adoption and deployment and  counterproductively
   delay the benefits and improvements HTTP/2.0 (will) bring.

Conclusion:

   Make it easy to do, but don't mandate it.

   You always get better results by delivering good tools, than
   rigid policies.

-- 
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: Amos Jeffries <[email-masked]>
Date: Wed, 18 Jul 2012 23:32:39 +1200

On 18/07/2012 6:39 p.m., Mike Belshe wrote:
> I won't comment on most of this - I think we've each made our points 
> and will need to respectfully disagree.  One last point below.
>

> On Tue, Jul 17, 2012 at 10:43 PM, Adrien W. de Croy <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     From: "Mike Belshe" [email-masked] <mailto:[email-masked]>
>>
>>
>>     On Tue, Jul 17, 2012 at 9:51 PM, Adrien W. de Croy
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>
>>         From: "Mike Belshe" [email-masked] <mailto:[email-masked]>
>>>
>>>
>>>         On Tue, Jul 17, 2012 at 8:25 PM, Adrien W. de Croy
>>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>             Mandating use of (c.f. support for) crypto in HTTP will
>>>             prevent it from being deployable in a significant number
>>>             of scenarios, thereby requiring ongoing use of HTTP/1.1.
>>>
>>>
>>         I don't know if it should be a goal though.  IMO the goal
>>         should be to replace the old with something better, not
>>         replace it with something that can only be used by a subset
>>         of current users, and therefore requires continued perpetual
>>         use of the old.
>>
>>
>>     Agree; goal should be to be better.  That doesn't mean that I
>>     think everyone will jump to it in short order, though.
>>>             1. Many states have outlawed use of crypto.  So will
>>>             this be HTTP only for the "free" societies?  Or is the
>>>             IETF trying to achieve political change in "repressed"
>>>             countries?  I've dealt with our equivalent of the NSA on
>>>             this matter.  Have you?  I know the IETF has a neutral
>>>             position on enabling wiretapping.  Mandating SSL is not
>>>             a neutral / apolitical stance. Steering HTTP into a
>>>             collision course with governments just doesn't seem like
>>>             much of a smart idea.
>>>
>>>
>>>         I don't know of states that prohibit TLS.  Do they exist?
>>>          Which ones are they?  Can you list them?
>>         It's hard to get recent information, but my understanding is
>>         that a lot of of people live in jurisdictions where crypto is
>>         tightly controlled.
>>>         Are you saying that HTTP/2.0 must be compliant with the laws
>>>         of every country?  And that any country passing a law making
>>>         HTTP/2.0 features illegal will block HTTP/2.0? :-)
>>         In practice, we would have different levels of difficulty
>>         ignoring laws of a country depending on which country that was.
>>         If the US passed a law that banned it, and threatened to put
>>         you in jail, you may give that more weight.
>>         Governments already have wiretapping laws. Do you think they
>>         will abandon that as a desire?
>>         Many laws on crypto were only relatively recently relaxed. 
>>         There's an ongoing tussle between security agencies of
>>         government and privacy advocates over it.  We can't guarantee
>>         that within the next 5 years that any country wouldn't make
>>         it illegal.
>>         It's not like we can claim there's no reasonable expectation
>>         to consider laws when it comes to crypto.  That's the one
>>         area of software development where caveats and warnings are
>>         stamped over so much code and documentation that we can't
>>         claim to be unaware it's an issue.
>>
>>
>>
>>     Well, when you've got a specific country to talk about, please
>>     raise the issue.
>     Maybe someone from one of the countries I listed above would be in
>     a better position to comment than I am.
>>
>>>             2. Most prisons do not allow inmates to have privacy
>>>             when it comes to communications.  Would you deny [*] all
>>>             prisoners access to the web?  There are other scenarios
>>>             where privacy is not expected, permitted or desirable.
>>>
>>>
>>>         I doubt this is a problem.  If it is, then the poor
>>>         prisoners are already being denied access to their banks,
>>>         most all of which require TLS.
>>         Schools, homes and businesses are also places where there may
>>         be deemed (by those in charge) a need to monitor activity.
>>
>>
>>     They already have this problem.  Twitter, Google, and Facebook
>>     have all publicly declared that they are working their way to
>>     100% TLS all the time.  These issues exist today.  If you want to
>>     filter TLS, you can; several vendors provide solutions.
>>     But schools have bigger problems - like those cell phones with
>>     more bandwidth than the school has to its classrooms.
>>     I don't think the protocol has an obligation to reduce security
>>     so that prisons, schools, or other institutions can institute
>>     content control.   And by the time this standard is done, the
>>     policy rules will have changed again.
>     I'm not proposing we take the current level of security of
>     HTTP/1.1 and reduce it.
>     improved security situation overall, especially if it breaks
>     SSL/TLS.  I kinda like SSL/TLS, I'd like it to continue to be usable.
>>
>>     protected by the protocols and sites they visit.  We're passing
>>     more laws every day to ensure this - and HTTP can help.
>>>             3. Many situations require communications to be open and
>>>             visible.  Would you rather your network infrastructure
>>>             phoned home with SSL or HTTP that you can see.
>>>
>>>
>>>         Can you enumerate these?  For debugging, of course it makes
>>>         sense for endpoints to have unencrypted modes.  We can also
>>>         build better tools, such as the improvements for decoding
>>>         TLS traffic with Wireshark that have landed recently.
>>     With wireshark you can decide SSL session if you let your browser
>>     dump the private keys.  Chrome supports this.
>     OK, well let's hope we never have to debug any protocol - level
>     stuff with any other client software.
>>
>>         Huawei recently got excluded from bidding for an Australian
>>         govt contract (a large one) due to concerns over possibility
>>         of eavesdropping.
>>
>>
>>     Excellent point for why we should make the protocol more secure
>>     :-)  If everything were encrypted, it wouldn't have been a problem.
>     Sure, anything sensitive should be encrypted before it goes over
>     that infrastructure.  But I'm sure some large equipment vendor was
>     lobbying somewhere.
>>
>>         Mandating privacy on HTTP will make it easier in some cases
>>         (e.g. infrastructure) to eavesdrop on non-private communication.
>>
>>
>     If my phone-home data is plaintext HTTP, I can demonstrate it's
>     not eavesdropping.
>>
>>>             4. Scanning for malware at a gateway.  This requirement
>>>             is NOT going away, and the SSL will be brute-forced /
>>>             spoofed etc to achieve this.  Mandating SSL will just
>>>             make it easier for malware to propagate, since you make
>>>             it harder to scan [**].
>>>
>>>
>>>         This problem exists today; IP leakage has to be checked even
>>>         across TLS based connections.  Solutions for these corporate
>>>         IT groups exist, including TLS aware proxies and TLS man in
>>>         the middle.  Several vendors provide these solutions today.
>>         Sure.  But as previously discussed, the way it is done
>>         results in an overall reduction in security.  A "sanctioned"
>>         way would be much preferable, but necessarily reduces privacy
>>         potentially to 0.
>>
>>
>     I said potentially.  If you let your company see your data because
>     they operate the proxy that terminates the SSL connection from the
>     browser, then your expectation of privacy (from your company) is
>     potentially 0.
>>      The end user will be aware of such changes; these are only
>>     possible by changing the trust points in the browser.  If your
>>     company gives you a browser, it can change your trust points.
>>      But if it is your own browser, you pick the trust points.
>>
>>     I agree this is obscure, but it is something we can improve upon.
>>      I agree that we should.
>>
>>     Of course we do.  We switch to opt-in proxies (like what Roberto
>>     Peon has proposed) rather than the transparent proxies that we
>>     have today.  These are much better because the user has the
>>     opportunity to know the proxy is there, unlike today.
>     We've been recommending against using transparent proxying for
>     years.  Unfortunately that doesn't reduce demand for it.
>     But even with explicit proxy use by the client, for SSL/TLS that
>     just boils down to HTTP CONNECT, which bypasses the proxy anyway.
>>     Personally, the security risks of using such a proxy probably
>>     outweigh the performance advantages for most people.
>     Problem is, the people who operate these proxies think differently
>     to you.  They want to see and scan everything.  They don't care so
>     much about privacy on their LAN.
>
>
>
> I'm taking the position of the user.  I want the user to be able to 
> know if someone is spying on them in all cases.   I think censorship 
> and alteration of content is such a huge risk to us as a free people 
> that we simply cannot tolerate not knowing who is scanning our lines. 
>  We must must must know it.
>
> sniffed and potentially altered by third parties without their 
> knowledge.  Do you want that for your own data?
>

I had to collate data for a survey on cancer about 11 years ago. Asking 
essentially a) who *wants* to catch cancer? yes/no/dont-care and b) who 
regularly sunbathes? yes/no and c) are you aware sunbathing regularly 
leads to melanoma ? yes/no

Here in NZ where (b) leads to (a) at a horrifyingly high % rate. ... 
nobody said yes to (a).  A large group said yes to (b). The same large 
group mostly said yes to (c)!!
   These are our typical users .... actively and knowingly going out and 
reaching toward goals they say they dont want.

> Now, I'm not trying to block the proxy operators you mention.  I just 
> want the users to be made aware of their presence, so that users can 
> decide for themselves whether it is ok (because its their boss on 
> their company computer) or not (because its someone at my telco).
>
> We do have a choice here - safety for the users vs. enabling of 
> transparent snooping for anyone.
>

Would you care to guess how many *years* the proxy community have been 
trying to send alerts to the user only to be blocked by the Browser agent?

I respectfully refer you to: 
http://www.squid-cache.org/mail-archive/squid-dev/201207/0114.html

Note the past paragraph ... we have to MITM the TLS connection then send 
an error page *inside* the encrypted tunnel. Just to get the *user* to 
be aware that they are connecting via a proxy that needs login. Even 
using Marks new status code wasn't enough!

Cromium is not alone in this. IE "friendly errors" have also been a 
long-standing barrier to informing users of anything in under one MTU of 
data, at least in that battle we had most of the web developer community 
and even the server communities on our side in that one.

   Now who was it fighting for user-awareness again?

AYJ

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 18 Jul 2012 08:08:51 -0400

>    makes that ideal very hard if not impossible.

You state that you have no expertise in the area and then opine that a
group of people are corrupt.

That is me you are talking about, I have been in Web security longer
than anyone else.

The IETF has proposed many security solutions over the years. HTTPS is
the only one that has achieved ubiquity. Every one of the alternatives
to CAs has been tried multiple times with nothing like the success.

The problem of SSL interception proxies is a lot more complex than
people here seem to imagine. There are industries that are required to
keep a log of ALL communications, brokerage firms for example.

Until recently nobody in the CA or browser world had much sympathy for
the problem and it was largely ignored. The companies involved found
their own solution to the problem, adding an extra root into the trust
store.

When Syria recently attempted a MITM interception on FB, Google and
others they just used a self signed root and hoped people would add it
to the trust store. It probably worked to the extent they had hoped
even if it was discovered in a couple of days.

There is a long discussion on the Mozilla list about whether we should
address this problem with prohibition or to legalize the brothel so we
can ensure that there are appropriate safeguards. That is primarily a
policy argument and neither choice is perfect.

>    to proxies, but I defer fully to Adrian on this.

I would prefer to keep TLS and HTTP the same and move the PKIX
processing out of the client platform completely. This is how it is
done in government systems, the client uses SCVP.

>    to stick with HTTP/1.1, in order to be able to do accident

+1

>    You always get better results by delivering good tools, than

+1

-- 
Website: http://hallambaker.com/

---

From: Zhong Yu <[email-masked]>
Date: Wed, 18 Jul 2012 11:03:32 -0500

If TLS is mandated, yet NULL cipher is acceptable, what was the point
of mandating TLS in the first place?

On Tue, Jul 17, 2012 at 11:24 PM, Mike Belshe <[email-masked]> wrote:
> Naw - this is not a big deal.  For instance, a server can send a NULL cipher
> same-origin-policy.  Browsers often have debugging modes for turning it off.
> You have to run the browser in a special, techie, opt-in way to do it, but
> it is there.
>

---

From: Henry Story <[email-masked]>
Date: Wed, 18 Jul 2012 18:09:13 +0200

> of mandating TLS in the first place?

You get the security that the information was not corrupted along the way.
The User experience really needs to make that visible, but that's not a problem
with TLS.

>> I used these all the time when developing in Chrome.

Social Web Architect
http://bblfish.net/

---

From: Zhong Yu <[email-masked]>
Date: Wed, 18 Jul 2012 11:21:13 -0500

That's nice, but I don't think content tempering is a major concern in
this discussion.

---

From: Henry Story <[email-masked]>
Date: Wed, 18 Jul 2012 18:26:24 +0200

> That's nice, but I don't think content tempering is a major concern in

It is extremely important to the security of the whole web. Currently
most sites serving web pages over plain HTTP can be man in the middle
attacked. So you read a blog post of a good friend of yours who is talking
about some web site, and a man in the middle changes a key link to go
to a site that resembles very much the site of the shop he spoke about but
is in fact a pirate shop.

Even if all web sites were to move to null cypher suites, the value in 
security to the whole web would be gigantic I believe.

Henry

Social Web Architect
http://bblfish.net/

---

From: Zhong Yu <[email-masked]>
Date: Wed, 18 Jul 2012 12:01:23 -0500

On Tue, Jul 17, 2012 at 10:25 PM, Adrien W. de Croy <[email-masked]> wrote:
> gonna buy us our certs?

Agreed. It's absolutely impractical to mandate officially signed certs
on every website. That's a huge hurdle for small sites; and all big
sites started from small sites.

---

Here's a related story that's very interesting. Self signed certs are
used by the official ticket booking site of Ministry of Railways of
China. Apparently they want to save a few bucks.

Customers are asked to download and install an untrusted root cert
from its website. From average user's point of view, that makes sense
- if you do more work, that got to increase security, right? Almost
everybody in China take trains, this root cert must have been
installed widely.

http://www.12306.cn
"To ensure a smooth booking experience, please download and install
the root certificate"

http://www.12306.cn/mormhweb/kyfw/question/201204/t20120427_2115.html
FAQ > Security Alert
When a user tries to log in, often he/she will see IE security
warnings ... That's because the user has not imported the root
certificate shown on the home page ... To navigate the site smoothly,
simply follow the instructions and import the root certificate.

the root cert and instructions:
http://www.12306.cn/mormhweb/ggxxfw/wbyyzj/201106/srca12306.zip

a cert signed by the root cert
https://dynamic.12306.cn

---

From: Henry Story <[email-masked]>
Date: Wed, 18 Jul 2012 19:12:04 +0200

> sites started from small sites.

Unless of course you start Deploying IETF DANE, which could make the procurement of
such certs a lot easier, since it just requires placing a public key in DNSsec.

   http://tools.ietf.org/wg/dane/

making it easy to install such certs could be the task of a WG. Then one could add
other services to verify that these certificate are not tampered with.
 
Henry

Social Web Architect
http://bblfish.net/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 18 Jul 2012 13:45:48 -0400

> other services to verify that these certificate are not tampered with.

But now you have stepped away from mandating support for the TLS in
use today and instead mandating support for a new design based on a
science project.

To implement HTTP/1.1, all I need is a TCP stack and a HTTP stack.
Plenty of people have done both in a week.

To implement HTTP/2.0 with your proposed mandate would require

* TCP
* HTTP 1.1
* HTTP 2.0
* TLS
* PKIX
* DNS
* DNSSEC
* DANE

Oh and by the way:

* PKIX is layered on HTTP creating a potential infinite regression.
How does an OCSP server work over HTTP/2.0? Does the OCSP server cert
need to be validated via OCSP as well? Are CRLs going to be supported?

* Practical deployment of TLS REQUIRES an IPv4 address per connection
since there is a large population of browsers that do not support SNI.
If you mandate support for TLS in HTTP you will find everyone wants
their server to have legacy support as well.

If this is really an attempt to mandate DANE then people should say so.

---

From: Zhong Yu <[email-masked]>
Date: Wed, 18 Jul 2012 13:37:12 -0500

A short term solution is that browsers stop acting so hostile against
self signed certs. Can't there be some other ways for a browser to
establish  cert-domain trust?