Subject: Mandatory encryption

From: Paul Hoffman <[email-masked]>
Date: Tue, 17 Jul 2012 17:51:56 -0700

+1 to what seems to be a lot of developers: make TLS mandatory.

>  so, even when used in an internal application protocol, it's going to
>  be end to end
>  encrypted to make it super hard to debug?

In an internal application protocol, why would it be "super hard to
debug"? The client can do an HTTP dump before TLS, the server can do
an HTTP dump after TLS; either of the sides could debug the TLS.

>  http is about more than users using
>  web browsers.

Completely true, and not relevant. Insecure HTTP for non-browser
applications still has the same bad properties, no?

---

From: Grahame Grieve <[email-masked]>
Date: Wed, 18 Jul 2012 11:00:15 +1000

> an HTTP dump after TLS; either of the sides could debug the TLS.

yep. they can. But they have to. 3rd parties are shut out. I get that in
some circumstances this is good. But not all. As an example, I spend
quite a bit of my time looking at browser traffic now, to debug why
my servers or clients aren't working they way that a 3rd party
client/server set up is. Unless it's https, in which case.... I have to find
some other way.

> applications still has the same bad properties, no?

but a much wider deployment context, and much harder to work with

Grahame

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 17 Jul 2012 21:22:24 -0400

-1

I don't want to have a mandatory requirement unless it is going to
change behavior.

We already have ubiquitous deployment of TLS in browsers. The code is
freely available, everyone knows the benefit.

The only HTTP servers or clients I am aware of that don't have TLS
support are either toolsets that the provider expects to be used with
OpenSSL or the like and embedded systems.

Incidentally, suport for IPSEC is mandatory in IPv6 but that does not
seem to do any good either. It just means that IPv6 is harder to
deploy as implementations are required to support a security layer
almost nobody uses as TLS has proved better.

Making TLS a mandatory requirement seems like a feelgood approach to
security to me. Instead of doing something useful, we pass a
resolution telling people to do what they plan to do anyway.

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

---

From: Mike Belshe <[email-masked]>
Date: Tue, 17 Jul 2012 19:30:15 -0700

Mandatory SSL is +1 and very forward thinking.

> I don't want to have a mandatory requirement unless it is going to

I don't think we can change behavior with protocols.  All we can do is
offer new features.  If the features are compelling, people will upgrade.
 If the features are not compelling, they won't.

People used to tell me SPDY would never get people to "upgrade".  Even
after touching a half a billion users, people still tell me that.  I think
the evidence of adoption speaks for itself.

> OpenSSL or the like and embedded systems.

I'll ask the google crawler guys to weigh in on this.  They have pretty
good stats.  I believe your assertion is provably false.

> resolution telling people to do what they plan to do anyway.

You imply there is something else that would be useful - what would it be?
 (don't feel obliged to answer :-)

To me mandating security is a great first step.  Nobody should think this
'fixes' security. But if we believe the net ever needs to be secure, we
need to start taking steps toward that.

Mandating SSL is a simple step we can take which solves most of the
eavesdropping problem right now.  But more importantly, it poises us to
address the next set of security issues, including CA/verification
problems,  distribution of video over ssl, handshake latency, etc.  Until
we start trying to be secure, of course we'll never be secure.

Mike

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 17 Jul 2012 23:32:25 -0400

Umm pretty much every Web Server has SSL support, the issue is that
only about 2% of deployments turn it on. Or is the idea that we are
going to mandate turning it on? If so, who is going to define the
trust criteria for accepting certs?

I am a big supporter of TLS. I just don't see anything good coming
from a mandate that is superfluous.

As an example, we have had a mandate in PKIX to check CRLs and/or OCSP
for over a decade and to reject a certificate if the client cannot
perform validation. Most browsers try to check but accept the
certificate if there is no response to the OCSP request. So virtually
every deployed browser has been out of compliance with a fundamental
PKIX control for over a decade despite repeated attempts by the CAs to
persuade the providers to change this.

I can't see how DANE is going to solve anything either since DANE
poses an even more disruptive hard-fail criteria.

I don't want to tie an application layer protocol version to a
transport layer protocol version or vice versa. If you tie HTTP 2.0 to
TLS 1.2 then you are going to have to revise HTTP when you revise TLS.

I don't see any value in a Canute/sea act here.

What would be valuable is to have a suite of standards for a specific
application that could be identified as a set. Something like 'best
practices for Web server hosting, IPv6 +HTTP 2.0 + TLS 1.2 with
AES+SHA2 + DNSSEC'. It would also be nice to see a similar draft for
best practices for email clients and servers, and yes, support for
STARTTLS would be high on my list of requirements. A draft like that
would be very useful as a contract term for outsourcing Web hosting or
mail service.

But that is a totally different prospect to trying to tie HTTP to a
particular security solution.

Implementing TLS in a product is far from trivial. Getting the code is
easy, selecting trust anchors is not. Is the specification going to
mandate a particular choice of trust anchor? that is not going to
happen. Nor is defining a minimum Certification Policy or locking the
whole HTTP trust infrastructure to the ICANN PKI root by trying to
mandate DNSSEC and DANE as well as TLS.

TLS requires a PKI to work and every PKI comes with a set of policy
and legal questions that have to be understood if the scheme is going
to provide any security.

On Tue, Jul 17, 2012 at 10:30 PM, Mike Belshe <[email-masked]> wrote:
> I don't think we can change behavior with protocols.  All we can do is offer
> new features.  If the features are compelling, people will upgrade.  If the
> features are not compelling, they won't.
>
> People used to tell me SPDY would never get people to "upgrade".  Even after
> touching a half a billion users, people still tell me that.  I think the
> evidence of adoption speaks for itself.
>
>>
>>
> I'll ask the google crawler guys to weigh in on this.  They have pretty good
> stats.  I believe your assertion is provably false.
>
>>
>>
> 'fixes' security. But if we believe the net ever needs to be secure, we need
> to start taking steps toward that.
>
> address the next set of security issues, including CA/verification problems,
> distribution of video over ssl, handshake latency, etc.  Until we start
> trying to be secure, of course we'll never be secure.
>
> Mike
>
>>
>>
>>

---

From: Mike Belshe <[email-masked]>
Date: Tue, 17 Jul 2012 20:51:49 -0700

> trust criteria for accepting certs?

Browsers already have well documented policies for this.  Major OSes also
have their own policies (MacOS, Windows).

> TLS 1.2 then you are going to have to revise HTTP when you revise TLS.

This is not true.  HTTP did not change when we went from earlier versions
of TLS to the current versions.  Browsers do support older versions of TLS,
usually for older servers that haven't upgraded.  Even SSL3 - shudder.

> and legal questions that have to be understood if the scheme is going

Users expect privacy and security.  We've all seen the legislation around
the globe for stronger security and privacy options.  SSL won't fix
everything, I know, but it is a solid step, and its the responsible step
for the protocol.  I don't understand how we can argue that HTTP/2.0 could
be a protocol for the next 20 years if it is sniffable over the wire.

Go talk to non-techie users about whether HTTP is secure.  They assume it
is.  Ask them if they would prefer a secure protocol or an insecure one.
 Ask them if they think protocols should be eavesdroppable so that other
people in the cafe can see what they're doing, steal their passwords, and
more?  I have yet to find any of these users that want this flimsy level of
security.

So- the problem we're solving here is to make users safer and raise the bar
on web security globally.

Mike

> offer
> after
> good
> problems,

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 18 Jul 2012 00:50:03 -0400

Perhaps you are not aware that I work for a CA and I have spent 20
years working on Web security, most of it developing the CA industry
and PKI infrastructure.

Maintaining the policies for accepting trust roots is essentially a
full time job for each of the parties doing it. It is not just a
matter of checking that a CA has a valid audit. The root manager has
to determine that the audit actually relates to the root of trust to
be included and that the practices adhered to meet the necessary
inclusion criteria.

Unlike a coding task, maintaining a root store is an ongoing
commitment. It is not something that you can do once and forget.

On Tue, Jul 17, 2012 at 11:51 PM, Mike Belshe <[email-masked]> wrote:
> This is not true.  HTTP did not change when we went from earlier versions of
> TLS to the current versions.  Browsers do support older versions of TLS,
> everything, I know, but it is a solid step, and its the responsible step for
> the protocol.  I don't understand how we can argue that HTTP/2.0 could be a
> protocol for the next 20 years if it is sniffable over the wire.
>

---

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

> commitment. It is not something that you can do once and forget.

I didn't comment on the difficulty of the policy.  I am aware of the
incredible detail that goes into such policies.  But the policy has always
remained outside the protocol specification, so I don't see why it is
relevant.

For most uses, the OS already takes care of this for you, so there is no
work to be done at all.  Just use the OS certificate store and you're fine.

Mike

> for
> >> > On Tue, Jul 17, 2012 at 6:22 PM, Phillip Hallam-Baker <
> [email-masked]>
> >> > wrote:
> >> >>
> >> >> -1
> >> >>
> >> > new features.  If the features are compelling, people will upgrade.
>  If
> >> > the
> >> >> On Tue, Jul 17, 2012 at 8:51 PM, Paul Hoffman <
> [email-masked]>
> >> >> wrote:
> >> >> >>  so, even when used in an internal application protocol, it's
> going
> >> >> >> to
> >> >> >>  be end to end

---

From: Mark Watson <[email-masked]>
Date: Wed, 18 Jul 2012 05:27:39 +0000

The problems with HTTP that HTTP/2.0 is intended to address seem to have nothing to do with security. Adding a requirement for use of TLS is unrelated to the purpose of the new protocol and will restrict its usage. See http://groups.csail.mit.edu/ana/Publications/PubPDFs/Tussle%20in%20Cyberspace%20Defining%20Tomorrows%20Internet%202005's%20Internet.pdf for why we should design protocols which flex along lines of controversy. This question of mandating TLS seems to go directly against that advice.

There are many services which make use of HTTP without TLS today that may find it more difficult to migrate to HTTP/2.0 if they also have to change their security approach as well. The benefits of HTTP/2,0, whilst they may be substantial, are likely not sufficient to be "worth the price" of such a change. As a specific example, Netflix ships quite a lot of traffic over HTTP without TLS, yet our service remains highly secure. Where we do use TLS we find significant problems with it - switching to TLS for all traffic would be an order-of-magnitude bigger deal (on the minus side) than the benefits of HTTP/2.0.

…Mark

On Jul 17, 2012, at 9:50 PM, Phillip Hallam-Baker wrote:

On Tue, Jul 17, 2012 at 11:51 PM, Mike Belshe <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Jul 17, 2012 at 8:32 PM, Phillip Hallam-Baker <[email-masked]<mailto:[email-masked]>>
wrote:

Mike

On Tue, Jul 17, 2012 at 10:30 PM, Mike Belshe <[email-masked]<mailto:[email-masked]>> wrote:
Mandatory SSL is +1 and very forward thinking.

On Tue, Jul 17, 2012 at 6:22 PM, Phillip Hallam-Baker <[email-masked]<mailto:[email-masked]>>
wrote:

-1

I don't think we can change behavior with protocols.  All we can do is
offer
new features.  If the features are compelling, people will upgrade.  If
the
features are not compelling, they won't.

You imply there is something else that would be useful - what would it
be?
(don't feel obliged to answer :-)

To me mandating security is a great first step.  Nobody should think
this
'fixes' security. But if we believe the net ever needs to be secure, we
need
to start taking steps toward that.

Mike

On Tue, Jul 17, 2012 at 8:51 PM, Paul Hoffman <[email-masked]<mailto:[email-masked]>>
wrote:
+1 to what seems to be a lot of developers: make TLS mandatory.

so, even when used in an internal application protocol, it's going
to
be end to end
encrypted to make it super hard to debug?

---

From: Eliot Lear <[email-masked]>
Date: Wed, 18 Jul 2012 07:52:59 +0200

Paul,

I understand Mike's logic for using TLS.  I'm even sympathetic.  But
care must be taken, nevertheless not to make things worse.  That is in
fact possible if it means that everyone will get inured to browser
indications about validity of certificates.  Therefore, a prerequisite
is a means to do so that doesn't reduce the value of browser indications
of a secure or insecure connection.  DANE could play a role as could
non-CA based encryption, but we ought to have clear answers for that FIRST.

Eliot

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 18 Jul 2012 08:09:36 +0200

> almost nobody uses as TLS has proved better.

The issue with HTTP/2 will indeed be the same as with IPv6 : HTTP/2 will
be deployed between the browser and the load balancer, and everything
behind will remain HTTP/1 due to the added nuisances of deploying 2.0
everywhere. Almost nobody does IPv6 between LB and server nowadays, it's
added cost for no benefit.

This will force us to continue to support the crappy parsers of 1.1
forever and not to have MUX between the LB and the server, and that's
precisely the situation I'd like to avoid, by having a protocol which
*supports* more privacy but does not impose it where it's not expected.

> resolution telling people to do what they plan to do anyway.

Agreed. As I already said multiple times, sensible services requiring
privacy are already secured by TLS and it does not save them from being
tampered. But with TLS everywhere, we'll make the situation worse by
accustoming users to click all the day on "I accept the risks..." when
connecting to most of the poorly managed sites including the self-signed
equipments they run at home.

I'm really against making such a thing mandatory because it will only
improve privacy on a few services which actually do not need it and will
globally deteriorate the overall security by lowering the level of control
of users.

Willy

---

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

> *supports* more privacy but does not impose it where it's not expected.

This is not true; you can use whatever you want in your backoffice.  I've
talked about this many times before, with or without TLS; whatever you
want.   It's the browser channel which will be TLS only.

> globally deteriorate the overall security by lowering the level of control

We just disagree.  And I keep going back to the same argument over and over:

Show me the user that will stand up and say, "Yes, I would like my
communications to be snoopable and changeable by 3rd parties without my
knowledge."

When we find those users, we can design a protocol for them.  Until then,
let's design for the existing users of the Internet that want privacy, they
want security, they want to be free of tampering, and they want to know if
someone else can snoop their traffic.

Sorry - that will be the last time I say that for a while...

Mike

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 18 Jul 2012 09:14:37 +0200

> want.   It's the browser channel which will be TLS only.

That's why I want the protocol not to rely on TLS but to be self-sufficient.
If we can use HTTP/2 over TCP then I can disable TLS in the backoffice.
Otherwise I cannot and am forced to use HTTP/1 instead.

> communications to be snoopable and changeable by 3rd parties without my

I am one of these users. When I'm browsing in clear text, I know my
communications are snoopable and changeable and I don't care. When I
care I use https. Using cleartext has many benefits for me as a user.
It's faster and I don't have to constantly click "I accept" on every
pop-up that is raised due to too difficult certificate management for
the server, or the mess of keeping a CA list up to date.

So I am one such user who doesn't want to be forced to face all the
discomfort of TLS when it does not make sense. TLS for no reason is
already badly used, there is no reason it will suddenly become better
when made mandatory. It's the opposite, sites having it good will not
improve and remain the same, but the number of sites which will have
to deal with it when not expected will increase the number of false
alarms on the user side. We don't want to accustom users to blindly
click on this warning anymore.

Willy

---

From: Yoav Nir <[email-masked]>
Date: Wed, 18 Jul 2012 10:35:57 +0300

On Jul 18, 2012, at 9:54 AM, Mike Belshe wrote:

Show me the user that will stand up and say, "Yes, I would like my communications to be snoopable and changeable by 3rd parties without my knowledge."

Me! Me! I want my communications snooped and altered!

More seriously, I would like to use the Internet while I'm at work to do cool stuff like participating on this list. This involves traffic getting snooped and filtered by the firewall. This is no different from choosing to walk the streets of London, knowing full well you'll be photographed by multiple video cameras.  In both cases the user has control: she can choose to not use the Internet at work, or never to leave home, but those are really bad choices.

When we find those users, we can design a protocol for them.  Until then, let's design for the existing users of the Internet that want privacy, they want security, they want to be free of tampering, and they want to know if someone else can snoop their traffic.

The proliferation of PII on Facebook and the wide acceptance of traffic and crime prevention cameras in the western world leads me to think that these users who want privacy are not everyone.

Those firewalls I mentioned earlier do TLS proxy these days. So SSL won't protect you from tampering and snooping. Yes, TLS sometimes makes this kind of firewall visible, but it's there anyway. And you can't get through it without submitting to this tampering and snooping.

So you can't get a security benefit without establishing trust between clients and servers. Mandating TLS for all HTTP connections forces all clients to establish trust with all servers. So if Phil wants to control his lightbulb with a browsers, there's three ways to go about it:

 *   He'll need to install a server certificate on the lightbulb (maybe Phil gets a company discount, the rest of us would need to pay)
 *   The lightbulb would have a self-issued certificate, and Phil will have to live with browser warnings
 *   The browser will have TLS_NULL_WITH_NULL_NULL and TLS_DH_anon_WITH_AES_128_GCM_SHA256. And if they accept that from the lightbulb, why not from where it matters?

Yoav

---

From: J Ross Nicoll <[email-masked]>
Date: Wed, 18 Jul 2012 08:47:10 +0100

> globally deteriorate the overall security by lowering the level of control
Agreed from here too; we run the risk of turning HTTP 2.0 into a 
debacle. People running small blogs/sites/whatever will not understand 
why security is important, and will not want to bother with 
certificates. Their hosting providers will go where their customers 
want, not where we want, and will remain on HTTP 1.1 indefinitely. Even 
if they did move, I'd expect to see rampant use of self-signed, or worse 
snake-oil certificates ("Need files for that weird thing you don't 
understand that your hosting provider keeps asking about? Here, you can 
download ones I made for you..."), followed by a culture of ignoring 
warnings on those certificates (and I would be extremely surprised if we 
didn't see browser extensions to click-through the warnings automatically).

I see the queries that come to the helpdesk, and how much we struggle 
just to stop users from e-mailing their passwords to everyone who fakes 
a vaguely credible looking message from IT, the thought of trying to 
teach everyone about proper encrypted communication is somewhere between 
nightmarish and hopeless IMHO.

In terms of countries banning technologies that don't allow them to 
monitor their citizen's communication, I give you India and Blackberry: 
http://www.bbc.co.uk/news/business-11131330

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 18 Jul 2012 07:29:46 -0400

Content delivery is an example of a case where TLS is decidedly
sub-optimal as a security solution.

If I am streaming a HD movie of 2Gb or so, I am going to want to
encrypt it once and deliver it without TLS. That is more secure as it
avoids giving the attacker multiple ciphertexts of the same plaintext
under different keys.

Mandating TLS in HTTP means shutting the door on other security
solutions that may be more appropriate. That isn't acceptable.

Nor is pushing the hard stuff onto 'the operating system'. Many HTTP
implementations run on machines that don't have an O/S at all. In fact
HTTP is the most complicated part of the system. That is not
coincidence. It was a design requirement at CERN before HTTP was even
proposed in IETF.

On Wed, Jul 18, 2012 at 1:27 AM, Mark Watson <[email-masked]> wrote:
> The problems with HTTP that HTTP/2.0 is intended to address seem to have
> nothing to do with security. Adding a requirement for use of TLS is
> unrelated to the purpose of the new protocol and will restrict its usage.
> See
> http://groups.csail.mit.edu/ana/Publications/PubPDFs/Tussle%20in%20Cyberspace%20Defining%20Tomorrows%20Internet%202005's%20Internet.pdf
> for why we should design protocols which flex along lines of controversy.
> This question of mandating TLS seems to go directly against that advice.
>
> There are many services which make use of HTTP without TLS today that may
> find it more difficult to migrate to HTTP/2.0 if they also have to change
> their security approach as well. The benefits of HTTP/2,0, whilst they may
> be substantial, are likely not sufficient to be "worth the price" of such a
> change. As a specific example, Netflix ships quite a lot of traffic over
> HTTP without TLS, yet our service remains highly secure. Where we do use TLS
> we find significant problems with it - switching to TLS for all traffic
> would be an order-of-magnitude bigger deal (on the minus side) than the
> benefits of HTTP/2.0.
>
> …Mark
>
>
>
> On Tue, Jul 17, 2012 at 8:32 PM, Phillip Hallam-Baker <[email-masked]>
>
> wrote:
>
>
> On Tue, Jul 17, 2012 at 6:22 PM, Phillip Hallam-Baker <[email-masked]>
>
> wrote:
>
>
> -1
>
>
> On Tue, Jul 17, 2012 at 8:51 PM, Paul Hoffman <[email-masked]>
>
> wrote:
>

---

From: Patrick McManus <[email-masked]>
Date: Wed, 18 Jul 2012 09:06:48 -0400

On Tue, 2012-07-17 at 23:54 -0700, Mike Belshe wrote:

> communications to be snoopable and changeable by 3rd parties without
> my knowledge."
[..]
> Sorry - that will be the last time I say that for a while...

please keep saying it. That is the important point.

-P

---

From: Patrick McManus <[email-masked]>
Date: Wed, 18 Jul 2012 09:05:58 -0400

> client/server set up is. Unless it's https, in which case.... I have to find

this is just tooling.. and there are lots of good emerging answers to
this. For firefox and chrome you can use the directions in
https://developer.mozilla.org/en/NSS_Key_Log_Format to get a "keylog"
file you can give to wireshark so it can simply decode a TLS packet
capture. Its pretty sweet.

Other tools will come along.

---

From: Patrick McManus <[email-masked]>
Date: Wed, 18 Jul 2012 09:06:38 -0400

On Tue, 2012-07-17 at 19:30 -0700, Mike Belshe wrote:

> eavesdropping problem right now.  But more importantly, it poises us
> to address the next set of security issues, including CA/verification
> problems,  distribution of video over ssl, handshake latency, etc.
>  Until we start trying to be secure, of course we'll never be secure.

+1.. especially on improving the PKI.

also - When TLS is optional, as in HTTP/1, that means the decision is
made by the server and concerns about the users privacy are controlled
by that side of the transaction. Because it is sometimes more convenient
for the machines to go with plaintext, the user effectively loses choice
and walks smack into the eavesdropping problem. There is no data
transfer that is really public information. [*]

Web transport needs to favor the confidentiality of humans over
convenience of the machines. Even if humans are a cost center.

To the extent that there are non-human use cases for HTTP (definitely!)
that are unable to support this (I'm skeptical they are significant)
they can run a different protocol (e.g. COAP). The human web
requirements have to be met as the most important constituency and that
means increasing transport security.

It hasn't been stated in a while, and its a constant source of confusion
when discussing this topic, but the TLS requirement does not mandate end
to end TLS by tunneling through proxies in the way we currently do. A
mechanism for knowingly interacting with MITM intermediaries is a
necessary work item (discovery, opt-in, etc..) . If you're going to
argue about legally necessary MITMs this is answer to that.

-Patrick

[*] Imagine a giant LCD board over your front door announcing that days
browsing habits.. all of this stuff happens in plain text today:
 + shopped for burner cell phone
 + bing search "domestic violence help"
 + weather in springfield this weekend (you told everyone you were going
to westville)
 + how to organize a union
 + obsessively read huffpo.com - you work for the GOP county
commisioner. (or reverse it with drudge and the Dems.. doesn't matter).
 + watched 3 hours of porn
 + left an anonymous comment on the local newspaper that said "blah
blah"

People shouldn't have to expect that everything they click on will be
public information. Time to raise the bar. HTTP/2 has an opportunity to
improve the overall speed of the web while at the same time enhancing
privacy - that's the right mix.

---

From: Patrick McManus <[email-masked]>
Date: Wed, 18 Jul 2012 09:07:19 -0400

> everywhere.

Except we know that in the very near future SPDY adoption will have
reached far more people than IPv6 ever has. So, unlike IPv6, there is a
big demand to solve the problems it addresses.

>  Almost nobody does IPv6 between LB and server nowadays, it's

of course spdy has lots of benefits. key difference :)

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 18 Jul 2012 09:41:57 -0400

>> communications to be snoopable and changeable by 3rd parties without

As has been mentioned before, embedded systems, real time control.

The operators of a nuclear power plant want to have strong
authentication on every connection but they do not want the
communications to be encrypted. That is a very common requirement in
that field.

They don't want any code that is not absolutely necessary.
Confidentiality is a low concern, integrity is a high concern.

I sell crypto for a living. I am also one of the developers of
HTTP/1.0. The people pushing this particular mandate do not understand
either in my view.

Crypto isn't a magic wand that you can wave and get 'security'.
Security is risk management and to do that you have to have an
understanding of the application area.

HTTP was always intended to be used in more than just browsers. It was
intended as a replacement for FTP as well. It was intended as a
transport layer for Web Services (the name is recent, the idea dates
back to my work in 1993, or earlier).

---

From: Eliot Lear <[email-masked]>
Date: Wed, 18 Jul 2012 15:56:26 +0200

Mike,

> communications to be snoopable and changeable by 3rd parties without

This is a red herring.  The real argument is around the ability of all
web servers to get certificates that the browser will  / should trust,
or using a means of trust that doesn't require certificate chains. The
server administrator must not be put in a position of having to pay an
annual fee to avoid the client warning, because that introduces at least
a potential externality in that the server administrator may not value
avoiding the warning in the way that you would expect.  Certainly the
end user doesn't act appropriately against the warning, which is why
we're having this discussion[1,2][*]. 

Eliot

[1] Herley, C., “So Long, And No Thanks for the Externalities: The
Rational Rejection of Security Advice by Users”, /NSPW’09/, September
8–11, 2009.
[2] Edelman, S., et al, “You've been warned: an empirical study of the
effectiveness of web browser phishing warnings”,/Proceedings of the
twenty-sixth annual SIGCHI conference on Human factors in computing
systems/ , 2008.
[*] There are probably dozens of citations in this space.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 18 Jul 2012 11:06:52 -0400

It isn't just the cost that is an issue.

The ongoing maintenance cost is a real hinderance. Much of the cost in
the CA business turns out to be getting the customer to renew at the
one year expiry point. In many cases the Web site was set up by a
consultant who bought the cert and didn't tell the customer that they
needed to renew it.

The real security requirement here is to avoid a downgrade attack.
Mandating use of TLS in HTTP 2.0 does nothing for that unless there is
also a means of avoiding the downgrade attack to HTTP/1.1

We need to make preventing a downgrade attack practical and if we do
that we do not need the mandate.

Here is an example of the type of mechanism that could make use of
security policy practical:

http://tools.ietf.org/html/draft-hallambaker-omnibroker-01

Now Comodo and Kaspersky are already deploying schemes that have some
of this functionality already. I expect Symantec and McAfee will
eventually follow suit with their own plug ins. So the question is not
whether people will do something like this but whether it will be a
standard or not.

On Wed, Jul 18, 2012 at 9:56 AM, Eliot Lear <[email-masked]> wrote:
> This is a red herring.  The real argument is around the ability of all web
> servers to get certificates that the browser will  / should trust, or using
> a means of trust that doesn't require certificate chains. The server
> administrator must not be put in a position of having to pay an annual fee
> to avoid the client warning, because that introduces at least a potential
> externality in that the server administrator may not value avoiding the
> warning in the way that you would expect.  Certainly the end user doesn't
> act appropriately against the warning, which is why we're having this
> discussion[1,2][*].
>
> Eliot
>
> [1] Herley, C., “So Long, And No Thanks for the Externalities: The Rational
> Rejection of Security Advice by Users”, NSPW’09, September 8–11, 2009.
> effectiveness of web browser phishing warnings”, Proceedings of the
> twenty-sixth annual SIGCHI conference on Human factors in computing systems
> , 2008.

---

From: Tim Bray <[email-masked]>
Date: Wed, 18 Jul 2012 08:09:23 -0700

On Wed, Jul 18, 2012 at 6:56 AM, Eliot Lear <[email-masked]> wrote:
> servers to get certificates

This pattern keeps coming up.
A: “Privacy is good”
B: “No, because the technology is currently too expensive/unreliable”

Uh... privacy is good.  -T

---

From: Patrick McManus <[email-masked]>
Date: Wed, 18 Jul 2012 11:15:13 -0400

On Wed, 2012-07-18 at 15:56 +0200, Eliot Lear wrote:
> or using a means of trust that doesn't require certificate chains.
> [..]

Your point is incredibly important, is absolutely intertwined, and
deserves lots of attention. I feel like focus in that area is building
but there is nothing to show for it yet. However, its not an inherently
unsolvable problem and thus I really disagree with the "red herring"
claim. Transport security needs to be used more widely and we also need
to make the transport security work better.

I don't think that means throwing away TLS (or even the way PKI is
managed) in favor of something else, but I'm open to a different
strategy that achieves the same goals. I think everyone is.

---

From: Ross Nicoll <[email-masked]>
Date: Wed, 18 Jul 2012 16:22:50 +0100

Okay, how about this; if TLS is enforced in HTTP 2.0, I seriously 
believe it will damage privacy. Users do not care, and will not put the 
effort required in to do this correctly, meaning self-signed 
certificates at best or HTTP 1.1 remaining the majority protocol. If 
self-signed certificates become commonplace, users will instinctively 
click through the warnings (and move away from browsers that fight them 
on that), making the current situation actually much worse.

Alternatively, users will roll their own TLS-free HTTP 2.0 alternatives 
and patch Apache, Firefox and Chrome to support it, leading to 
years/decades of complex supporting of multiple subtly incompatible 
protocols running over the same ports.

I still remember a lot of researchers wondering about how to do 
multicast file sharing effectively, before BitTorrent came along and 
worked-around the whole issue using swarmcasting. Sure, it was a 
horrific protocol that involved publicly announcing that you were 
downloading a file, but no-one cared, they just cared that it worked.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 18 Jul 2012 17:34:15 +0200

On Jul 18, 2012, at 17:09, Tim Bray wrote:

> Privacy is good

Ah, nice, another textbook example for Protocol Design 101 is in the
process of being made.

To the people who want "mandatory encryption" because "privacy is good":

You are designing a mechanism (here: HTTP 2.0).  If you happen to like
a certain policy (here: good privacy) today, you may be tempted to
cripple the mechanism so it only "allows" that policy.

Unless the policy comes with zero cost and is universally accepted,
this sets you up for failure:

1) People who don't like your favorite policy will not use your
   mechanism.  Worse, rational people who know that their potential
   peers might not like the policy will not use your mechanism.  And
   rational people who know that there are the second kind of people
   will not use it either, and so on.
   The transitive closure is empty, but for a few zealots.
2) You may (read: will) find out later that you didn't think of the
   use cases for the mechanism where the policy is useless or actively
   hurts.

If you don't understand how this works, it is nicely documented in
Dave Clark et al.'s famous "tussle" paper.

As a general rule, mechanisms MUST be neutral to the outcome of
tussles.  Design for choice.

(Now there are exceptions to this rules, where a mechanism is actually
being designed for a new applications space that is properly delimited
by the applicability of the policy.  Creating a putative replacement
for a protocol as ubiquitous as HTTP is NOT this case.)

That'll be your lecture for the day :-)
Now the assignment:

What we really should be working on is removing the obstacles we have
today for widely deploying privacy-enhancing mechanisms.  (Hint for
solving this assignment: Designing an NG protocol with "mandatory
encryption" is not helping in this at all.)

Grüße, Carsten

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 18 Jul 2012 17:46:18 +0200

> of course spdy has lots of benefits. key difference :)

Not between the LB and the server. It has benefits on the issues it
was designed to solve : the quality of the connection to the end user.

Regards,
Willy

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 18 Jul 2012 08:50:33 -0700

Given your views, would it be a good protocol design to require TLS
for server authentication, and to allow but not require encryption?
That is, do you think HTTP 2.0 with no mandatory server authentication
is a good or bad protocol design?

--Paul Hoffman

---

From: Eliot Lear <[email-masked]>
Date: Wed, 18 Jul 2012 17:57:46 +0200

Hi Patrick,

> but there is nothing to show for it yet.

Thanks.  I agree.

> However, its not an inherently
> claim.
What I meant by red herring is that I haven't heard anyone object to the
assertion that privacy is good.  I'm just concerned that mandating
crypto without thinking about the UI implications could make things
worse.  I do not know how hard the problem is.  It's not like we haven't
been looking at reputation/certification elsewhere, but more work is
required, as you mention above.

Mozilla and other browser developers are in a very good position to
discuss what user indications might work versus what might not, and what
the protocol implications are.  Also, I'm reminded that because HTTP is
used for everything in the world, the applicability of this work could
be circumscribed to try to make some of these issues more tractable
(like whether a user is present).

>  Transport security needs to be used more widely and we also need

Sure.
> strategy that achieves the same goals. I think everyone is.

Sure.
Warmest regards,

Eliot

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 18 Jul 2012 12:02:21 -0400

No what is being said is.

a) Privacy is a requirement in certain applications
b) Mandating confidentiality does not guarantee privacy
c) Mandating one particular approach to confidentiality does not
guarantee privacy
d) The proposed approach is only designed to meet a specific set of
requirements
e) The cost of doing it right is greater than many implementations will bear

I am all for TLS, our business depends on it.

I have demonstrated a use case where encryption MUST NOT be used. Can
anyone show me a Web browser that does not support TLS? I don't think
there is one.

I am also all for being pro-user except when there are no users which
is actually a major set of use cases for HTTP/1.1.

Also note that the mere presence of a mandate in an IETF spec isn't
worth the paper it is not written on. NO browser that is in use today
implements PKIX according to the spec and no browser provider intends
to comply unless the spec is changed. I can't see how a TLS mandate
would be any more successful.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 18 Jul 2012 12:15:23 -0400

Requiring TLS for server authentication would still be bad design
because the security requirement in most cases is mutual
authentication and TLS without encryption is not a good approach to
mutual auth.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 18 Jul 2012 18:21:52 +0200

> is a good or bad protocol design?

I don't think there is a big difference between encryption and authentication in this argument.
Authentication only is indeed lower-cost: It carries a lower processing cost than encryption, and more importantly it does not reduce the visibility by intermediaries (firewalls, debugging setups, surveillance) as much.  But there is still considerable onus on the process side (getting the certificates out to both ends etc.; deciding what trust models for establishing authentication are appropriate in the first place...).

My summary would be that designing the protocol so it forces mandatory authentication is just the same mistake, only less so.

None of this argument is against the mechanism of TLS by the way: we could run TLS with null encryption and permissive authentication.
But then we are down to cost arguments (round trips, complexity etc.).  If "address ownership" is the right level of authentication for an application (say, getting today's weather maps), I'd say use it.  The trouble here is that we hide the quality of that authentication from users (think DSL at home vs. open WiFi at Starbucks).  We need to expose more of these leaky abstractions!

Grüße, Carsten

---

From: Mark Watson <[email-masked]>
Date: Wed, 18 Jul 2012 16:23:39 +0000

+1

I do encourage people to read the "tussle" paper: http://groups.csail.mit.edu/ana/Publications/PubPDFs/Tussle%20in%20Cyberspace%20Defining%20Tomorrows%20Internet%202005's%20Internet.pdf

…Mark

On Jul 18, 2012, at 8:34 AM, Carsten Bormann wrote:

Privacy is good

Grüße, Carsten

---

From: Roberto Peon <[email-masked]>
Date: Wed, 18 Jul 2012 10:31:30 -0700

There are number of technical issues here.
1) speed of experience
2) deployability of protocol
3) privacy against wireless sniffers (I call this point-to-point privacy)
4) authentication of the server to the client.
5) runtime cost

#5 goes up with TLS, in the short run, though in the long run this isn't
necessarily true if we use a long-lived multiplexed thing on tip of it-- at
least for less optimized stuff that allows the kernel to handle accept(),
etc. It is easy to forget about the cost of dealing with multiple
connections at the system level in the server.
For highly optimized proxies such as haproxy TLS will likely end up a net
cost, no question.

For #4: This is typically indicated by use of the http scheme. If one used
TLS in transporting such a query, the browser should not be in the business
of server auth-- there should be no chance of a cert warning. If you get
point-to-point privacy without auth here, it is strictly better from a
security perspective, even assuming TLS's trust chain is compromised.

#3: TLS does help with this, even without authentication. It isn't perfect,
but it is better than http by quite a bit.

#2: Experience has shown, unfortunately, that deploying something new from
browser to server is either extremely difficult or unreliable. That is the
only case where mandating anything like TLS makes sense to me.

#1 isn't obvious one way or another. For the first request TLS potentially
harms latency as compared to http/1.1. For subsequent requests it comes out
as better (given application protocol changes). More interestingly,
negotiating http/2 over port 80 will require a round trip, which is the
same latency penalty one will pay for using TLS at a site that you have
recently visited assuming we use false-start.

-=R

---

From: Roberto Peon <[email-masked]>
Date: Wed, 18 Jul 2012 10:40:58 -0700

As a reminder, I submitted an ID w.r.t. TLS proxies and MITM.

The key idea in it, ignoring the technical stuff, is that either party
(client, server) has or should have some decisions to make about what the
proxies are allowed to do, and thus their own behavior when dealing with
them.

The proxy always had the power to restrict and control things which flow
through it. Always will.

-=R

---

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

------ Original Message ------
From: "Tim Bray" <[email-masked]>
>>>communications to be snoopable and changeable by 3rd parties without my

Show me the person who will stand up and say "yes I want to pay tax".

This is not a way to prove anything.  Especially when there's no 
discussion of the cost of not paying tax (having to live in cave and 
defend your family against attackers while you starve to death).

Asking a question like that with no consideration of cost is misleading 
at best.

>Uh... privacy is good.  -T

there are a few words missing from the statement "privacy is good" in 
the context of this discussion.

what you're actually saying is "privacy is always good for everyone in 
all circumstances".

That is where there is room for disagreement, with the 
"...always...everyone...all circumstances" part.

Others going on to claim that people who take issue with the 
"...always...everyone...all circumstances" part (because they see it 
even though it's perpetually omitted by the proponents) therefore are 
anti-user is the sort of reasoning that let GW Bush take the world 
where it is today.

We can do better than that.

---

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

In message <emcc23e46a-858d-4484-8c00-11e2e8ec3d3e@bombed>, "Adrien W. de Croy"

>Show me the person who will stand up and say "yes I want to pay tax".

I want to pay tax.

I get health-care, roads, schools for my kids, a low crime-rate,
and lots of other very expensive benefits.

It's a pretty sweet deal actually.

-- 
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: Zhong Yu <[email-masked]>
Date: Wed, 18 Jul 2012 19:04:58 -0500

The man/woman in the middle who has the authority to snoop also has
the authority to temper with certificates. The cost of doing that is
not prohibitively high for the authority, therefore it should be a
point against mandatory encryption.

For little guys though, the cost of certificates can be too high. I
don't think there's a conspiracy from Google etc to stiff
competitions, but these guys probably don't care too much about some
amateurs building toy webapps.

Zhong Yu

---

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

> point against mandatory encryption.

correction: it should NOT be a point against mandatory encryption

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 19 Jul 2012 09:13:59 +0900

Hello Tim,

On 2012/07/19 0:09, Tim Bray wrote:
> On Wed, Jul 18, 2012 at 6:56 AM, Eliot Lear<[email-masked]>  wrote:

> Uh... privacy is good.  -T

Okay, Tim, here's a challenge for you then:

If privacy is important (I'm with you here, of course), and if privacy 
requires TLS (like many others on this list, I have my strong doubts, 
but you seem to think so), how come that your own site 
http://www.tbray.org/ongoing/ still uses http rather than https?

Is the privacy of the readers of Ongoing just less important than the 
privacy of user of the average Web site? Or is it that you just haven't 
realized that was still on http?

Why don't you actually go to the trouble of moving Ongoing to TLS, with 
a chained (i.e. not self-signed) certificate, and tell us how many 
working hours/days and how much money it took you to set it up. This may 
make for an interesting learning experience, and an interesting blog entry.

[This challenge is of course also for all the other people who advocate 
to tie in mandatory TLS with HTTP 2.0; I just picked Tim because I know 
his site and I know he likes such challenges :-).]

Regards,   Martin.

P.S.: I have my own server for my lab (way less slick than Ongoing, I 
have to admit), and I have considered using https: at least about once 
every year, probably more. It would be the right thing to do. But the 
amount of time it would require from me, to set it up and to make sure 
it's set up correctly, is just too much.

---

From: Zhong Yu <[email-masked]>
Date: Wed, 18 Jul 2012 19:54:00 -0500

Very good point. When I tried to make a comment on the site, I'm
prompted with an anti-spam question "Is Adolf Hitler generally
considered to have been good or bad?". If I submit the form in plain
http, and Hitler is snooping, I'll be in trouble.

On Wed, Jul 18, 2012 at 7:13 PM, "Martin J. Dürst"
<[email-masked]> wrote:
>>> web
> requires TLS (like many others on this list, I have my strong doubts, but
> you seem to think so), how come that your own site
> Why don't you actually go to the trouble of moving Ongoing to TLS, with a
> chained (i.e. not self-signed) certificate, and tell us how many working
> hours/days and how much money it took you to set it up. This may make for an
> interesting learning experience, and an interesting blog entry.
>
> [This challenge is of course also for all the other people who advocate to
> tie in mandatory TLS with HTTP 2.0; I just picked Tim because I know his
> site and I know he likes such challenges :-).]
>
> Regards,   Martin.
>
> P.S.: I have my own server for my lab (way less slick than Ongoing, I have
> to admit), and I have considered using https: at least about once every
> year, probably more. It would be the right thing to do. But the amount of
> time it would require from me, to set it up and to make sure it's set up
> correctly, is just too much.
>

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 19 Jul 2012 13:27:08 +1200

> big demand to solve the problems it addresses.

Huh. IPv6 has *reached* just about every end-user in eastern 
civilisation and a good portion of the western as well.

The annoying fact that there are IPv4-only barriers devices all over 
the Internet is not the users or content providers faults.

If HTTP/2 mandates encryption, compression or anything similar that 
raises the developer implementation workload significantly over HTTP/1 
then our efforts will face the same type of barriers with HTTP/1-only 
IDS, firewall and monitoring systems.

Remember we are *already* pretty much confirmed to be adding:
  * binary encoding - difficult to read on the wire, special new tools 
required to interpret it (and learn how to use), new library APIs to 
learn for parsing and generating messages.
  * multiplexing - flow control on that one will be an educational curve 
for most still stuck on the HTTP/1.0 paradigm (1.1 folks only get it 
slightly easier if they understand 1xx status flow control).
  * pipelining - already a difficult subject under HTTP1, making it 
mandatory to support is a good thing but does raise the learning curve.

Adding all these up and we have a noticable barrier to implementation. 
Placing *mandatory* encryption on top to raise the barrier even higher, 
particularly in places where it is clearly not necessary for security OR 
privacy is too much. As the Hulu folks have said, too much of a good 
thing is still too much.

>> added cost for no benefit.

You want to tell that to my customers. You (and most other users) not 
noticing just goes to show how well the middleware gateways and LB have 
been doing translating IPv4 to IPv6 and back again.

The networks over this *quarter* of the world (APNIC and increasingly 
RIPE NCC) are increasingly 'forced' to run IPv6 internally due to 
unavailability of IPv4 allocations and routinely do exactly as you 
suggest 'nobody' does: Run IPv6 between LB and server pool. The 
available IPv4 being reserved largely for use on the America-facing 
connections.
  Then there is the carrier-grade NAT situation for content providers. 
Bit of a no-chance there, but every attempt simply hides more IPv6 away 
from those of you in IPv4-only nets.

> of course spdy has lots of benefits. key difference :)

AYJ

---

From: Tim Bray <[email-masked]>
Date: Wed, 18 Jul 2012 20:23:24 -0700

Fair point; I should. -T

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 18 Jul 2012 21:32:05 -0600

On 7/18/12 6:13 PM, "Martin J. Dürst" wrote:

> I have my own server for my lab (way less slick than Ongoing, I 
> have to admit), and I have considered using https: at least about
> once every year, probably more. It would be the right thing to do.
> But the amount of time it would require from me, to set it up and
> to make sure it's set up correctly, is just too much.

Martin, I think you overestimate the time it takes. Personally, I've
found it to be quite easy. If you'd like, I'll write a blog post about
it sometime soon and post it at my TLS-protected website:
https://stpeter.im/

Peter

P.S. I am of the opinion that if we protocol geeks can't be bothered
to secure our websites or digitally sign our email and the like, we
have no standing to criticize others.

---

From: Nico Williams <[email-masked]>
Date: Wed, 18 Jul 2012 22:42:38 -0500

> it sometime soon and post it at my TLS-protected website:

It's less easy if you use a hosting service, particularly one that
doesn't support SNI.  Then you get charged extra for a dedicated
address.  (At least one hosting service does that.)

There's roadblocks...

Nico
--

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 18 Jul 2012 21:44:16 -0600

On 7/18/12 9:42 PM, Nico Williams wrote:
>>> I have my own server for my lab (way less slick than Ongoing,
>>> I have to admit), and I have considered using https: at least
>>> about once every year, probably more. It would be the right
>>> thing to do. But the amount of time it would require from me,
>>> to set it up and to make sure it's set up correctly, is just
>>> too much.
>> 
>> Martin, I think you overestimate the time it takes. Personally,
>> I've found it to be quite easy. If you'd like, I'll write a blog
>> post about it sometime soon and post it at my TLS-protected
>> website: https://stpeter.im/
> 

Sure, I have a VPS so it's a bit easier.

> There's roadblocks...

Agreed.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 19 Jul 2012 06:10:39 +0000

In message <[email-masked]>, =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3
Qi?= writes:

>I have considered using https: at least about once 
>every year, probably more.

I have never even remotely considered it for my personal server, for
the exact same reason as teacher-parent notes are not notarized.

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 19 Jul 2012 20:17:29 +1200

On 19/07/2012 5:31 a.m., Roberto Peon wrote:
> #5 goes up with TLS, in the short run, though in the long run this 
> isn't necessarily true if we use a long-lived multiplexed thing on tip 
> of it-- at least for less optimized stuff that allows the kernel to 
> handle accept(), etc. It is easy to forget about the cost of dealing 
> with multiple connections at the system level in the server.
> For highly optimized proxies such as haproxy TLS will likely end up a 
> net cost, no question.
>
> For #4: This is typically indicated by use of the http scheme. If one 
> used TLS in transporting such a query, the browser should not be in 
> the business of server auth-- there should be no chance of a cert 
> warning. If you get point-to-point privacy without auth here, it is 
> strictly better from a security perspective, even assuming TLS's trust 
> chain is compromised.
>
> #3: TLS does help with this, even without authentication. It isn't 
> perfect, but it is better than http by quite a bit.
>
> #2: Experience has shown, unfortunately, that deploying something new 
> from browser to server is either extremely difficult or unreliable. 
> That is the only case where mandating anything like TLS makes sense to me.
>
> #1 isn't obvious one way or another. For the first request TLS 
> potentially harms latency as compared to http/1.1. For subsequent 
> requests it comes out as better (given application protocol changes). 
> More interestingly, negotiating http/2 over port 80 will require a 
> round trip, which is the same latency penalty one will pay for using 
> TLS at a site that you have recently visited assuming we use false-start.
>

Not necessarily. The framing design we wrote in network-friendly draft 
allows servers and proxies to auto-detect whether the client is using 
HTTP/1 or HTTP/2 [1] and adjust with zero RTT delay. The client is in a 
more diffcult position and has to suffer using HTTP/1 syntax on the 
first request with an Upgrade:HTTP/2.0, but there we propose several 
headers which the client can use to seed HTTP/2 details with zero delay 
on the upgrade.

The only potential RTT in sight is an HTTP/2 client attempting to start 
with HTTP/2 when contacting an HTTP/1-only server. They can expect an 
HTTP/1 error message RTT before anything useful happens (if at all). I 
am confident we can specify client implementers to use the HTTP/1 
upgrade methodology until servers have had time to roll out their part 
of HTTP/2 and reduce the impact of initial requests.

We have done a bit more work since publishing that draft and now have a 
header design which may eliminate the need for even those transitional 
headers. At worst the first request from a client has some HTTP/1 syntax 
bloat and self-corrects into HTTP/2 efficiency on the response - there 
is never any handshake or option detection RTTs.

This is at the proposed lowest level framing syntax of the protocol. 
Underneath channel encryption, compression, header compaction, data 
integrity pull/push semantics - the lot.

AYJ

> -=R
>
> On Jul 18, 2012 12:16 AM, "Willy Tarreau" <[email-masked] <mailto:[email-masked]>> 
> wrote:
>

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 19 Jul 2012 11:39:01 +0200

Hi Roberto,

> 4) authentication of the server to the client.
(...)
> recently visited assuming we use false-start.

For the two points above, I get your point but partially disagree. As we
discussed in another thread on HyBi a few years ago, I have experience of
a number of places where proxies don't allow TLS to pass through for filtering
reasons.

For instance, one of my customers doesn't allow HTTPS to google.com for a
simple reason : in HTTP they always force safesearch to on in outgoing
requests so that they rely on google's ability to filter out unsuitable
contents. In HTTPS they obviously can't do this so google images then
becomes a single-handed browsing tool. So they don't allow HTTPS on this
domain.

The effect is that connections from the browser to google cannot use SPDY
over port 443 right now and this is not going to change for a long time
due to internal filtering policy reasons.

So outgoing connection attempts to use port 443 will have to fall back to
use port 80 instead (second round trip) while the Upgrade would pass on
the same connection.

TLS is a valid transport to join many directly connected users but is not
very practical for people in enterprises unfortunately. What I'm opposed
to is to force such users to choose between HTTP/2.0 and HTTP/1.1 instead
of choosing between clear and encrypted as they're doing right now. Because
whatever the transport we choose, we're designing HTTP/2.0 to provide much
better end-user experience to users and we should not condition this to
the ability to pass over port 443.

Regards,
Willy

---

From: Anil Sharma <[email-masked]>
Date: Thu, 19 Jul 2012 09:55:54 +0000

" in HTTP they always force safesearch to on in outgoing
requests so that they rely on google's ability to filter out unsuitable
contents. In HTTPS they obviously can't do this so google images then
becomes a single-handed browsing tool."

Didn't understand this point? From compute server point of view (which is providing you search results) it shouldn't matter whether transport used was secure or not?
Did I miss something?

Best,
Anil 

-----Original Message-----
From: Willy Tarreau [mailto:[email-masked]] 
Sent: Thursday, July 19, 2012 3:09 PM
To: Roberto Peon
Cc: Paul Hoffman; Phillip Hallam-Baker; [email-masked]; [email-masked]; Mike Belshe
Subject: Re: Mandatory encryption

Hi Roberto,

(...)

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 19 Jul 2012 12:02:28 +0200

> Didn't understand this point? From compute server point of view (which is providing you search results) it shouldn't matter whether transport used was secure or not?

When the request is sent in clear text, the proxy modifies it to force
"safesearch=on" in the requests so that Google refrains from returning
unsuitable contents. In https, it obviously cannot force that on the
users' request so the user has complete access to the whole internet
cached in "google images". There are places where this type of access
is not accepted at all so google is not in the SSL whitelist.

Regards,
Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 19 Jul 2012 10:08:04 +0000

In message <[email-masked]>, Willy Tarreau writes:

>TLS is a valid transport [...]

Am I the only one who think we should be able to mix protected
and unprotected transactions on the same TCP stream ?

I really don't see why the user should have to open a new connection
just because they want to log into a site, and it would allow
proxies, gateways and routers to use fewer connections more
efficiently.

(Of course, this largely depends on my proposal for an always
unprotected envelope, but I think I already "sold" that ?)

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 19 Jul 2012 12:17:10 +0200

> and unprotected transactions on the same TCP stream ?

No you're not the only one, I like it too, as well as I'd like to
ensure that websocket and HTTP can share the same TCP connection
as well.

> proxies, gateways and routers to use fewer connections more

In fact, mixing streams saves TCP connections. However, processing
encryption on a stream is always expensive as it requires data copy
at the software level.

If we one day support datagram-based transport (which I hope for
many reasons), then I'd favor splitting the streams so that we can
rely on the NIC's ability to encrypt datagrams at a zero cost.

Regards,
Willy

---

From: Anil Sharma <[email-masked]>
Date: Thu, 19 Jul 2012 10:17:39 +0000

-----Original Message-----
From: Willy Tarreau [mailto:[email-masked]] 
Sent: Thursday, July 19, 2012 3:32 PM
To: Anil Sharma
Cc: Roberto Peon; Paul Hoffman; Phillip Hallam-Baker; [email-masked]; [email-masked]; Mike Belshe
Subject: Re: Mandatory encryption

When the request is sent in clear text, the proxy modifies it to force
"safesearch=on" in the requests so that Google refrains from returning
-----------------------------> Why can't TLS proxy do it ( anyways I thought the browser or the user decides it but even if lets its company policy and proxy does it for all the request)   Just trying to understand......

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 19 Jul 2012 12:23:02 +0200

On Thu, Jul 19, 2012 at 10:17:39AM +0000, Anil Sharma wrote:
> -----------------------------> Why can't TLS proxy do it ( anyways I thought
> the browser or the user decides it but even if lets its company policy and
> proxy does it for all the request)   Just trying to understand......

It would require deciphering the stream, sending a fake certificate
pretending to be the real server. Some proxies do this right now, this
is one of the ugly tricks we're seeing more and more and that a number
of people want to see disappear in favor of a user choice of letting
the proxy analyze the contents (the principle of the GET https://). Also
if you've read this thread, having a proxy tamper your request in HTTPS
without you being aware of it is quite contrary to the directions being
taken :-)

Regards,
Willy

---

From: Karl Dubost <[email-masked]>
Date: Thu, 19 Jul 2012 08:44:45 -0400

Le 18 juil. 2012 à 20:13, Martin J. Dürst a écrit :
> Is the privacy of the readers of Ongoing just less important than the privacy of user of the average Web site? 

Context. (oh how I dislike the work privacy ^_^, I chose opacity a while ago)

* In which contexts, the communication needs to be opaque to any intermediaries?
* What are the mechanisms which allow that?
* What is the cost of implementing/using these mechanisms for any participants in the chain of communications from the emitter to the receiver?

- Requesting a simple Web page on example.org, a person might not bother. 
- Until this specific request down to the URI itself might put one in trouble (aka what they read make them suspicious)
- Sending a message in a Web form to a person, again it depends. Will it be public? Is it only for this specific person?
- Opaque down to how much of it is opaque.

If I send a letter by post office mail, I expect them to not read. The envelope being closed is a weak security mechanism, but super simple to implement (seal a message by blocking eyesight with glue). The sender address may be completely opaque. The integrity is assessed by the fact it has not be opened. Note that just strong light is often enough to see through.

If I send a postcard, I don't expect the same thing. Sender address is still completely opaque, but the content is open. What do we say on postcards. 

A letter with a tracking number often requires the sender address.

The Web is not the physical world. The humans are still physical entities and trust relationships are a very hard topic. More opacity became necessary because entire businesses have been built on the ability to "abuse the de facto readability of human interactions". Any move towards more opacity will come at a cost for these businesses. That will be a hard fight. Nobody wants to give up its piece of the yummy cake.

PS: Personally, I wish for more opacity, or more exactly for my ability as a user to choose the mechanism of opacity (see letters above) depending on the context. I want to be able to assess (if/when I have a concern) which were the parties involved in the communications and which access they had to the message.

-- 
Karl Dubost - http://dev.opera.com/
Developer Relations, Opera Software

---

From: Henry Story <[email-masked]>
Date: Thu, 19 Jul 2012 15:29:39 +0200

On 19 Jul 2012, at 02:13, Martin J. Dürst wrote:

> If privacy is important (I'm with you here, of course), and if privacy requires TLS (like many others on this list, I have my strong doubts, but you seem to think so), how come that your own site http://www.tbray.org/ongoing/ still uses http rather than https?
> 
> Is the privacy of the readers of Ongoing just less important than the privacy of user of the average Web site? Or is it that you just haven't realized that was still on http?

I think in the case of Ongoing privacy is not in fact important. But security is! That is as a reader of
Ongoing I don't care at all that the articles sent by Tim are encrypted. What I do care is that the articles I receive are exactly what Tim wrote. So if Tim writes about a great camera buying experience, I want the link I receive that he put in his blog to be the one Tim intended it to be, and not be man in the middled and changed to an link to another web site. 

TLS allows null encryption in its protocol, and having that would be great. 

In fact knowing that I am on Tim's site and not on some other site ( because DNS was corrupted ) is also impportant. I want to know I am on Tim's site with the assurance of at least the same level of strength as the reliability of DNS (Which should be DNSsec)

Now we should not be critical for people because they have not implemented TLS (even with 0 encryption). Because the internet is an organic entity that grows, and just as we do not ask babies to be born bearing arms, we don't get a structure like the internet or the web to be born fully secure. It's architecture permits it to be, and now the Web is close to being 20, and it's time for it to join the army. :-)

> 
> Why don't you actually go to the trouble of moving Ongoing to TLS, with a chained (i.e. not self-signed) certificate, and tell us how many working hours/days and how much money it took you to set it up. This may make for an interesting learning experience, and an interesting blog entry.
> 
> [This challenge is of course also for all the other people who advocate to tie in mandatory TLS with HTTP 2.0; I just picked Tim because I know his site and I know he likes such challenges :-).]
> 
> Regards,   Martin.
> 
> P.S.: I have my own server for my lab (way less slick than Ongoing, I have to admit), and I have considered using https: at least about once every year, probably more. It would be the right thing to do. But the amount of time it would require from me, to set it up and to make sure it's set up correctly, is just too much.
> 

Social Web Architect
http://bblfish.net/

---

From: Henry Story <[email-masked]>
Date: Thu, 19 Jul 2012 15:52:42 +0200

On 19 Jul 2012, at 15:42, Karl Dubost wrote:

> 
> Le 19 juil. 2012 à 09:29, Henry Story a écrit :
>> It's architecture permits it to be, and now the Web is close to being 20, and it's time for it to join the army. :-)
> 
> 
> what an awful metaphor ;)

Not if you think of being in the army and freedom as going hand in hand, as for example it is very clearly in Switzerland, where every adult male goes for one week every year to the army, which is a citizens army, formed as militias. Since in Switzerland everything is put to a vote - a bit like in the IETF - and everybody goes to the army, they have not been to war for well over 100 years.

Giving responsibility of your freedom to someone else is already giving up freedom. Furthermore the whole can only be secure if everyone participates in its security. So I am advocating a hippie army of happy hackers here :-)

Henry

Social Web Architect
http://bblfish.net/

---

From: Reto Bachmann-Gmür <[email-masked]>
Date: Fri, 20 Jul 2012 16:20:48 -0700

On Wed, Jul 18, 2012 at 5:13 PM, "Martin J. Dürst"
<[email-masked]>wrote:

> hours/days and how much money it took you to set it up. This may make for
> an interesting learning experience, and an interesting blog entry.
>

Popping in here because I indeed remember the pain getting this CA-signed
certificate for my personal site. I did it because I felt publishing a
webid on an unsecured server is quite pointless (well it offers around the
same security as verify an identity by checking the email address).

By contrast I remember no pain migrating from telnet to ssh. So my hope was
that if encryption becomes standard on the web using it (both as client and
as server) becomes much easier. I doubt that the current CA/PKI approach is
a reasonable default behaviour. Trust on first use (TOFU) enhanced with
either social public key exchange or using notary server (as in
perspectives[1]) might offer a better balance of security and simplicity of
use.

Cheers,
Reto

PS: But yes, an answer to question "why is you blog http and not https?"
could be "because cool uris don't change and when security becomes standard
that S is obsolete".

1.
http://static.usenix.org/event/usenix08/tech/full_papers/wendlandt/wendlandt_html/

---

From: Mike Belshe <[email-masked]>
Date: Mon, 30 Jul 2012 21:43:19 -0700

> Fair point; I should. -T

Yeah, belshe.com should too :-)

Part of the reason it is hard is because we haven't built the tools we
need.  Why haven't we built better tools?  Because its too easy to opt out.
 Every day, millions of site operators like bray and belshe sacrifice the
needs of the Internet for their own general laziness.

If the net were secure by default and offered no option to amateur blokes
like us, we'd soon have a one-liner command line mechanism to
request/sign/issue/install our server certs and we'dl all be laughing about
how we used to say it was "hard".

Mike

> have

---

From: Yoav Nir <[email-masked]>
Date: Tue, 31 Jul 2012 09:28:27 +0300

On Jul 30, 2012, at 9:43 PM, Mike Belshe wrote:

On Wed, Jul 18, 2012 at 8:23 PM, Tim Bray <[email-masked]<mailto:[email-masked]>> wrote:
Fair point; I should. -T

Yeah, belshe.com<http://belshe.com/> should too :-)

Part of the reason it is hard is because we haven't built the tools we need.  Why haven't we built better tools?  Because its too easy to opt out.  Every day, millions of site operators like bray and belshe sacrifice the needs of the Internet for their own general laziness.

If the net were secure by default and offered no option to amateur blokes like us, we'd soon have a one-liner command line mechanism to request/sign/issue/install our server certs and we'dl all be laughing about how we used to say it was "hard".

Disagree. belshe.com<http://belshe.com> is just somebody's blog. It's not financial information, there are no privacy issues, no medical data, no potentially embarrassing association with sexual minorities. Why would you want to spend any resources securing that?

And securing that has costs. There's extra CPU (although I guess the smallest server you can buy can handle your site both with and without SSL), there's the cost of certificates, there's the administrative effort in getting and deploying the certificates, and there's the loss of caching ability all over the Internet.

Sure, my bank, my HMO and mail.google.com<http://mail.google.com> need to have encryption. Yes, as long as HTTP without S exists, browsers can be tricked into doing this unencrypted. But why should you and Tim bear the cost of securing those banking sites? Let them use HSTS or some future DNS-based strict transport security.

Yoav

---

From: Tim Bray <[email-masked]>
Date: Mon, 30 Jul 2012 23:55:58 -0700

On Mon, Jul 30, 2012 at 11:28 PM, Yoav Nir <[email-masked]> wrote:
> Disagree. belshe.com is just somebody's blog. It's not financial
> information, there are no privacy issues, no medical data, no potentially
> embarrassing association with sexual minorities. Why would you want to
spend
> any resources securing that?

Excuse me, what exactly do you know about my sexual preferences or Mike
Belshe’s and why are you so sure that we might not want to discuss them
without accidentally putting our readers in a place where the Basiji come
knocking at the door?

This is why it’s reasonable to think it important that privacy be the
default.  Because it if it isn’t, then turning privacy on is a powerful
signal to the Men In The Middle to start watching.

It’s unfortunate that you find association with minorities embarrassing.  -T

>
> And securing that has costs. There's extra CPU (although I guess the
> smallest server you can buy can handle your site both with and without
SSL),
> there's the cost of certificates, there's the administrative effort in
> getting and deploying the certificates, and there's the loss of caching
> ability all over the Internet.
>
> Sure, my bank, my HMO and mail.google.com need to have encryption. Yes, as
> long as HTTP without S exists, browsers can be tricked into doing this
> unencrypted. But why should you and Tim bear the cost of securing those
> banking sites? Let them use HSTS or some future DNS-based strict transport
> security.
>
> Yoav
>
>

---

From: Yoav Nir <[email-masked]>
Date: Tue, 31 Jul 2012 10:13:56 +0300

On Jul 30, 2012, at 11:55 PM, Tim Bray wrote:

On Mon, Jul 30, 2012 at 11:28 PM, Yoav Nir <[email-masked]<mailto:[email-masked]>> wrote:
> Disagree. belshe.com<http://belshe.com/> is just somebody's blog. It's not financial
> embarrassing association with sexual minorities. Why would you want to spend

Excuse me, what exactly do you know about my sexual preferences or Mike Belshe’s and why are you so sure that we might not want to discuss them without accidentally putting our readers in a place where the Basiji come knocking at the door?

I know nothing. Partially because neither you nor Mike say anything about this in your blogs.

This is why it’s reasonable to think it important that privacy be the default.  Because it if it isn’t, then turning privacy on is a powerful signal to the Men In The Middle to start watching.

This is again having the people who don't need it pay for those who do. There should be enough people who need privacy for various reasons to give too many signals for the Basij to watch them all.

I did say "potentially embarrassing", and there's a reason why many jurisdiction prohibit questions about sexual orientation in job interviews. Individuals MAY consider such matters private, whereas you broadcast your opinions of SPDY for the entire world to hear.

Yoav

---

From: Eliot Lear <[email-masked]>
Date: Wed, 01 Aug 2012 01:05:20 +0200

> need.  Why haven't we built better tools?  Because its too easy to opt

Or too hard to opt in.

>
> If the net were secure by default and offered no option to amateur
> blokes like us, we'd soon have a one-liner command line mechanism to
> request/sign/issue/install our server certs and we'dl all be laughing
> about how we used to say it was "hard".

I look forward to that day.  But it is not today, and your use of the
term "secure" is loose.  It is possible to make things worse by
attempting to make things more "secure".  Forcing the users to ignore an
indication that works *somewhat* would make things worse.

Eliot