Subject: Moving forward on improving HTTP's security

From: Mark Nottingham <[email-masked]>
Date: Wed, 13 Nov 2013 18:01:34 +0800

In Vancouver, we continued the discussion that we started in Berlin regarding the use of encryption in HTTP/2.

There seems to be strong consensus to increase the use of encryption on the Web, but there is less agreement about how to go about this.

The most relevant proposals were:

A. Opportunistic encryption for http:// URIs without server authentication -- a.k.a. "TLS Relaxed" as per draft-nottingham-http2-encryption.

B. Opportunistic encryption for http:// URIs with server authentication -- the same mechanism, but not "relaxed", along with some form of downgrade protection.

C. HTTP/2 to only be used with https:// URIs on the "open" Internet. http:// URIs would continue to use HTTP/1 (and of course it would
still be possible for older HTTP/1 clients to still interoperate with https:// URIs).

In subsequent discussion, there seems to be agreement that (C) is preferable to (B), since it is more straightforward; no new mechanism needs to be specified, and HSTS can be used for downgrade protection.

(C) also has this advantage over (A), and furthermore provides stronger protection against active attacks.

The strongest objections against (A) seemed to be about creating confusion about security and discouraging use of "full" TLS, whereas those against (C) were about limiting deployment of better security.

Keen observers have noted that we can deploy (C) and judge adoption of the new protocol, later adding (A) if neccessary. The reverse is not necessarily true.

Furthermore, in discussions with browser vendors (who have been among those most strongly advocating more use of encryption), there seems to be good support for (C), whereas there's still a fair amount of doubt/disagreement regarding (A).

As a result, I believe the best way that we can meet the goal of increasing use of TLS on the Web is to encourage its use by only using HTTP/2.0 with https:// URIs.

This can be effected without any changes to our current document; browser vendors are not required to implement HTTP/2.0 for http:// URIs today. However, we will discuss formalising this with suitable requirements to encourage interoperability; suggestions for text are welcome.

To be clear - we will still define how to use HTTP/2.0 with http:// URIs, because in some use cases, an implementer may make an informed choice to use the protocol without encryption. However, for the common case -- browsing the open Web -- you'll need to use https:// URIs and if you want to use the newest version of HTTP.

This is by no means the end of our security-related work. For example:

* Alternate approaches to proxy caching (such as peer-to-peer caching protocols) may be proposed here or elsewhere, since traditional proxy caching use cases will no longer be met when TLS is in wider use.

* As discussed in the perpass BoF, strengthening how we use TLS (e.g., for Perfect Forward Security) is on the table.

* A number of people expressed interest in refining and/or extending how proxies work in HTTP (both 1.0 and 2.0), as discussed in draft-nottingham-http-proxy-problem (among many other relevant drafts).

Furthermore, other security-related work in the IETF (see the perpass BoF) and elswhere (e.g., W3C) may affect HTTP. For example, a number of people have pointed out how weaknesses in PKIX affect the Web.

Your input, as always, is appreciated. I believe this approach is as close to consensus as we're going to get on this contentious subject right now. As HTTP/2 is deployed, we will evaluate adoption of the protocol and might revisit this decision if we identify ways to further improve security.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 13 Nov 2013 12:03:33 +0100

On 2013-11-13 11:01, Mark Nottingham wrote:
> ...

I'm really confused now, because I don't think option C) as outlined 
above has actually been discussed.

 From the minutes:

> 727	0) Don't know (yet)
> 728	
> 729	[strong humms for can't live with]
> 730	
> 731	1) Do nothing - hope that hTTPS gets more adoption
> 732	
> 733	[strong humms for can't live with]
> 734	
> 735	2) Opportunistic encryption w/o server authentication for HTTP URIs - just for
> 736	passive attacks
> 737	
> 738	[ less strong for can't live with ]
> 739	
> 740	3) Opportunistic encryption with server authentication AND downgrade protection
> 741	(somehow) for HTTP URIs; no requirement upon HTTP/2.0 when not available
> 742	
> 743	[ weakest for can't live with ]
> 744	
> 745	4) Requre secure underlying protocol for HTTP/2.0 (at least in web browsing)
> 746	
> 747	[ weaker for can't live with ]

Are you saying that 4) == C), and that 4) was about using https only?

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 13 Nov 2013 19:43:06 +0800

> Are you saying that 4) == C), and that 4) was about using https only?

In a nutshell, yes.

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

---

From: Julian Reschke <[email-masked]>
Date: Wed, 13 Nov 2013 12:47:03 +0100

>> Are you saying that 4) == C), and that 4) was about using https only?

I'm still confused. What you say implies that http: URIs will not use 
HTTP/2. We did *not* discuss this as option 4.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 13 Nov 2013 20:07:17 +0800

On 13 Nov 2013, at 7:47 pm, Julian Reschke <[email-masked]> wrote:

> I'm still confused. What you say implies that http: URIs will not use HTTP/2. We did *not* discuss this as option 4.

Julian, 

Requiring the use of a secure underlying protocol naturally excludes opportunistic approaches, which puts http:// URIs off the table. People who want to use HTTP/2 for http:// URIs will need to redirect them to https:// (and possibly use HSTS, depending upon their use case).

If you’d like to make a different proposal, you’re certainly free to. In my estimation, after discussion in the room, on the list, with implementers, various ADs and others, this is the best chance we have of moving forward and actually getting better security for HTTP started. If a different consensus emerges, I’m happy to follow it, but I’m not willing to let this issue turn into a rathole that knocks us off of schedule (a position that has regularly been verified with the WG).

Regards,

—

---

From: Julian Reschke <[email-masked]>
Date: Wed, 13 Nov 2013 13:42:44 +0100

> Requiring the use of a secure underlying protocol naturally excludes opportunistic approaches, which puts http:// URIs off the table. People who want to use HTTP/2 for http:// URIs will need to red…

That's not what our spec says right now.

I'm also not sure how use of a secure underlying protocol automatically 
excludes opportunistic approaches, unless you are *specifically* 
referring to what we currently specify for the upgrade from HTTP/1.1 to 
2.0 on "http:".

To be clear: my main concern here is not the actual bits on the wire, 
but ruling out use of HTTP/2.0 for "http:" URIs.

> If you’d like to make a different proposal, you’re certainly free to. In my estimation, after discussion in the room, on the list, with implementers, various ADs and others, this is the best chance…

As far as I can tell, what you are proposing is not what has been 
discussed during the actual working group meeting. We had several hums, 
and as far as I can tell, we had not even rough consensus for any of 
these options. The weakest "[ weakest for can't live with ]" outcome is 
recorded for option 3, not 4.

Apparently, this needs more discussion.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 13 Nov 2013 21:14:03 +0800

On 13 Nov 2013, at 8:42 pm, Julian Reschke <[email-masked]> wrote:

> To be clear: my main concern here is not the actual bits on the wire, but ruling out use of HTTP/2.0 for "http:" URIs.

And the *precise* language around that is still TBD. I’m somewhat of a mind to not specify it at all, in that the implementations will naturally do this anyway, but since the strongest indications we have is that people want us to do *something*, those requirements may fulfil that role.

> As far as I can tell, what you are proposing is not what has been discussed during the actual working group meeting.

Your understanding of what happened seems like it’s different than the other people who I’ve spoken to. Regardless of that, however, we don’t need to discuss every option at physical meetings; we need to discuss them on the list. That’s what’s happening now.

> We had several hums, and as far as I can tell, we had not even rough consensus for any of these options. The weakest "[ weakest for can't live with ]" outcome is recorded for option 3, not 4.

Hums are not a means of judging consensus; they’re a means for the chair to gather information about the people in the room — nothing more. As a reminder, we make decisions in the IETF based upon technical merit, not voting.

I am very aware that we didn’t have ample time to discuss this issue in our Vancouver meeting. I doubt that having had two extra days (never mind hours) would have helped, and we wouldn’t have learned significantly more information even if we had them, since the positions were so divided. 

As a result, I’m making an informed judgement call, based upon discussions so far and the options available to us. I do not do so lightly, and have been in active consultation with many of those it will affect, as well as IETF leadership. If that call is wrong, I’m confident that the WG will correct it, but again, that is *not* voting.

> Apparently, this needs more discussion.

Of course. I’ve announced what I believe our current state is; if there is serious pushback that has technical merit, we’ll have to revisit it. And as I’ve said many times, I’m open to proposals — especially those that can a) gain consensus b) actually get implemented and c) get approved by the whole IETF community. Haven’t seen any others yet.

Regards,

---

From: Michael Sweet <[email-masked]>
Date: Wed, 13 Nov 2013 08:21:17 -0500

Mark,

> To be clear - we will still define how to use HTTP/2.0 with http:// URIs, because in some use cases, an implementer may make an informed choice to use the protocol without encryption. However, for…

For the record, I strongly believe that support for unencrypted HTTP/2.0 is still needed and useful, particularly when you are routing it over an already “secure" channel to a resource-constrained device.  And there will likely be practical real-life limitations of what browser vendors choose to implement, i.e., no HTTP/2.0 support for http:// URIs.  However,  I honestly don’t see how this WG can actually enforce/mandate https:// and still allow http:// URIs.  So long as unencrypted URIs are supported by HTTP/2.0, the best you can do is make security recommendations since TLS is not REQUIRED (in the RFC 2119 sense) for the open web.

I also believe that HTTP/1.x has been so successful because of its ease (and freedom) of implementation. But IMHO restricting its use to https:// will only limit its use/deployment to sites/providers that can afford to deploy it and prevent HTTP/2.0 from replacing HTTP/1.1 in the long run.

_______________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Julian Reschke <[email-masked]>
Date: Wed, 13 Nov 2013 14:33:22 +0100

> And the *precise* language around that is still TBD. I’m somewhat of a mind to not specify it at all, in that the implementations will naturally do this anyway, but since the strongest indications…

How can implementations do "it" if we don't specify how?

> Your understanding of what happened seems like it’s different than the other people who I’ve spoken to. Regardless of that, however, we don’t need to discuss every option at physical meetings; we n…

Well, it's backed by the minutes, as far as I can tell.

And yes, the WG meeting is just advisory; what's relevant is what 
happens here on the mailing list. That's why I was confused by the 
statement:

"In subsequent discussion, there seems to be agreement that (C) is 
preferable to (B), since it is more straightforward; no new mechanism 
needs to be specified, and HSTS can be used for downgrade protection."

because I don't believe these discussions happened here on the mailing 
list (or, for that matter, on another IETF mailing list I'm subscribed to).

> Hums are not a means of judging consensus; they’re a means for the chair to gather information about the people in the room — nothing more. As a reminder, we make decisions in the IETF based upon t…

Yes.

> I am very aware that we didn’t have ample time to discuss this issue in our Vancouver meeting. I doubt that having had two extra days (never mind hours) would have helped, and we wouldn’t have lear…

Indeed.

> As a result, I’m making an informed judgement call, based upon discussions so far and the options available to us. I do not do so lightly, and have been in active consultation with many of those it…

Well, your mail makes it sound as if a decision already has been made, 
and that you're willing to revisit it if the WG pushes back. That's 
different from making a *proposal*, discuss it over here (and maybe 
*then* make a decision).

> Of course. I’ve announced what I believe our current state is; if there is serious pushback that has technical merit, we’ll have to revisit it. And as I’ve said many times, I’m open to proposals —…

How do you judge the technical merit exactly?

Do you believe it's acceptable that the default naming scheme for the 
web ("http") is affected (in that either users keep getting redirected, 
or bookmarks/links will have to change)?

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 13 Nov 2013 14:54:30 +0100

On Wed, Nov 13, 2013 at 08:21:17AM -0500, Michael Sweet wrote:
> I also believe that HTTP/1.x has been so successful because of its ease (and
> freedom) of implementation. But IMHO restricting its use to https:// will
> only limit its use/deployment to sites/providers that can afford to deploy it
> and prevent HTTP/2.0 from replacing HTTP/1.1 in the long run.

That's a good point. I'd say I know some people who push *terabits* of pink
pixels over the net and who had never heard about HTTP/2 nor SPDY before I
talked to them about it and who still don't see the value there. Just like
they do zero TLS and do not expect to ever use it. So there's a use for
everything.

But I think that we could specify all uses of the protocol (eg: think about
web services running in clear text which would benefit from 2.0) and at the
same time let browsers ship with the default options that suggests use of 2.0
for https:// and 1.1 for http:// just like we've had options in the past to
talk 1.1 or 1.0 to proxies, etc... 

The protocol which will succeed will be the one which does not change the
users' habits while still improving their experience. We need to keep that
in mind. For example, if browsers emit a warning each time a user visits a
porn site that does not enable encryption, the users will keep an older
browser to visit these sites, and these sites will take care of supporting
older browsers, it will be as simple as this!

I think that both Pat and William told us several times that users don't
want to be bothered. It's up to us to meet their expectations :-)

Willy

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 13 Nov 2013 15:04:57 +0100

* Mark Nottingham wrote:
>Your understanding of what happened seems like it’s different than the 
>other people who I’ve spoken to. Regardless of that, however, we don’t 
>need to discuss every option at physical meetings; we need to discuss 
>them on the list. That’s what’s happening now.

As I understand your message, the discussion is over, the decision has
been made. That is what various news media are reporting and what is
implied by your use of language like "revisit this decision". If your
purpose was not to record that the subject matter has received due
consideration on the mailing list and has now been decided and closed,
and just meant to make a proposal, then you should clarify accordingly.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Julian Reschke <[email-masked]>
Date: Wed, 13 Nov 2013 15:11:18 +0100

> they do zero TLS and do not expect to ever use it. So there's a use for

We need so understand that there are two almost orthogonal 
considerations for "HTTP":

(a) whether somebody gets the wire-format related improvements (header 
compression, push, multiplexing)

(b) whether communication will be in the clear (1), encrypted but not 
authenticated (2), encrypted and authenticated (3)

Looking at our charter (<http://datatracker.ietf.org/wg/httpbis/charter/>):

> It is expected that HTTP/2.0 will:
> * Substantially and measurably improve end-user perceived latency in most
> cases, over HTTP/1.1 using TCP.
> * Address the "head of line blocking" problem in HTTP.
> * Not require multiple connections to a server to enable parallelism, thus
> improving its use of TCP, especially regarding congestion control.
> * Retain the semantics of HTTP/1.1, leveraging existing documentation (see
> above), including (but not limited to) HTTP methods, status codes, URIs, and
> here appropriate, header fields.
 > ...

...so if we don't define HTTP/2.0 for "http:" URIs, we'll be missing one 
of the goals in our charter.

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 13 Nov 2013 15:19:43 +0100

Hi Julian,

> of the goals in our charter.

I whole heartly agree and that was my point in my conclusion. We need to
*define* it for everything and see how users *adopt* it. I'm convinced
that there will be a lot of valid usages for the cleartext version,
starting with application developers for whom it's always a mess to have
to request a certificate or to analyse a capture to see their headers,
and continuing with CDNs which are absolutely required these days if we
don't want to break the whole internet.

Best regards,
Willy

---

From: Tao Effect <[email-masked]>
Date: Wed, 13 Nov 2013 09:20:38 -0500

Hi list!

I only just heard about this discussion now, and so I signed up on the list.

I strongly urge the HTTP working group and the IETF (if that's a different entity) to not rush this and allow more time for feedback from the internet community.

The IETF is not the internet, and I assure you that there are a lot of people out there working on various solutions independently. They have valuable ideas to share, and feedback to offer. I think it's worth giving them a chance to speak before declaring something "HTTP 2.0".

What I have read so far of the suggestions here leads me to think the ideas are still very immature.

Correct me if I'm wrong, but is "HTTP/2.0" still using today's PKI/CA system?

If so, it is not worthy of the "2.0" designation, as any system that preserves this broken system does not provide any meaningful security guarantees.

Kind regards,
Greg Slepak
Tao Effect, LLC

--
Please do not email me anything that you are not comfortable also sharing with the NSA.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 13 Nov 2013 15:26:56 +0100

> If so, it is not worthy of the "2.0" designation, as any system that preserves this broken system does not provide any meaningful security guarantees.

Both 1.1 and 2.0 use the PKI/CA system only by indirection (through TLS).

I agree that there are problems with this system, but addressing those 
needs to happen in a different working group.

Best regards, Julian

---

From: Tao Effect <[email-masked]>
Date: Wed, 13 Nov 2013 09:40:35 -0500

Thanks Julian,

> I agree that there are problems with this system, but addressing those needs to happen in a different working group.

And that would be...?

Cheers,
Greg

On Nov 13, 2013, at 9:26 AM, Julian Reschke <[email-masked]> wrote:

> I agree that there are problems with this system, but addressing those needs to happen in a different working group.
> 
> Best regards, Julian
> 
>

---

From: Julian Reschke <[email-masked]>
Date: Wed, 13 Nov 2013 15:49:16 +0100

>> I agree that there are problems with this system, but addressing those needs to happen in a different working group.

<https://tools.ietf.org/wg/tls/> maybe?

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 13 Nov 2013 14:54:07 +0000

On 11/13/2013 02:40 PM, Tao Effect wrote:
> Thanks Julian,
> 
>> I agree that there are problems with this system, but addressing
>> those needs to happen in a different working group.
> 
> And that would be...?

#include <standard-answer.h>

That would be one that gets chartered as a result of a
good proposal with a reasonable liklihood of resulting
in success both in terms of RFCs being produced and
getting implemented and deployed, and where there are
enough folks with relevant clue interested. (If someone
has such a proposal feel free to contact me or Sean.)

In the meantime there is the wpkops working group [1]
who are trying to document the current web pki and how
that differs from e.g. RFC 5280 and who could do with
help in that. That's not really a pre-requisite to new
web pki developments, but it would be excellent if
such developments were based on the deployed reality
(with all its flaws) as a realistic starting point,
which is what the wpkops group are trying to capture.

S.

[1] http://tools.ietf.org/wg/wpkops/

---

From: Tao Effect <[email-masked]>
Date: Wed, 13 Nov 2013 10:14:21 -0500

Thanks Stephen!

Email bookmarked for future reference. ^_^

- Greg

On Nov 13, 2013, at 9:54 AM, Stephen Farrell <[email-masked]> wrote:

> Signed PGP part

---

From: Tao Effect <[email-masked]>
Date: Wed, 13 Nov 2013 10:49:22 -0500

> I agree that there are problems with this system, but addressing those needs to happen in a different working group.

Be extremely alert and wary for the support that this is likely to receive from those selling SSL certificates.

Obviously they have a monetary incentive to keep that broken and insecure system running.

I can see it now: "Paying for HTTPS certs is just like requiring people to carry car insurance in real life."

And other, similar bullsh*t.

- Greg

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 13 Nov 2013 23:56:39 +0800

On 13 Nov 2013, at 10:04 pm, Bjoern Hoehrmann <[email-masked]> wrote:

> been made.

No, I never said that the discussion is over. I said “there seems to be…”, “I believe,” and so forth. 

What I *do* want to avoid, however, is the back-and-forth advocacy that this sort of issue inevitably involves, and which doesn’t make any substantial contribution. Please restrict feedback to concrete technical issues regarding the matter at hand (that’s directly to the rest of the list, by the way, not Bjoern and Julian).

> That is what various news media are reporting and what is
> implied by your use of language like "revisit this decision”.

That’s an unfortunate choice of phrasing introduced by a last-minute change. My apologies.

> If your

My purpose was to report what I believe to be a viable path forward, and have that confirmed on the list. I honestly believe that this is implementable and represents the best balance of concerns and preferences that have been expressed, along with the constraints we work under.

In particular, we need to specify something that the browser vendors will actually do, and that will ultimately get published as an RFC; we cannot force either. While I cannot guarantee these results, I do believe that this proposal will pass both of these tests, based upon a lot of legwork over the last two weeks.

If you have new information that might help us evaluate this, please present it. Whatever happens, we will be evaluating the path we take as we move forward.

Regards,

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 13 Nov 2013 23:59:46 +0800

Hi Julian,

On 13 Nov 2013, at 9:33 pm, Julian Reschke <[email-masked]> wrote:

> Well, your mail makes it sound as if a decision already has been made, and that you're willing to revisit it if the WG pushes back. That's different from making a *proposal*, discuss it over here (and maybe *then* make a decision).

I would put it differently. I see only one viable path forward at this point in time, based upon the myriad constraints we face. If another becomes available, of course we will consider it. 

> How do you judge the technical merit exactly?

On a case by case basis. How do you expect me to answer that question? 

> Do you believe it's acceptable that the default naming scheme for the web ("http") is affected (in that either users keep getting redirected, or bookmarks/links will have to change)?

...*if* they want to use the latest version of HTTP, and provided that another mechanism isn’t added later. 

I do want to explore this issue; we might need to either layer on opportunistic encryption (which is NOT yet firmly ruled out; we’ll evaluate whether it’s still needed as we progress), modify our charter, or address it in some other way.

Regards,

---

From: Peter Lepeska <[email-masked]>
Date: Wed, 13 Nov 2013 11:25:46 -0500

I'd like to see the group hold off on making this decision until we've also
come up with an agreed upon way for proxies to function in an HTTP2, all
TLS Internet. Without it we're essentially requiring proxies to do MITM to
function. Is this increasing security?

Peter

On Wed, Nov 13, 2013 at 10:59 AM, Mark Nottingham <[email-masked]> wrote:

> >> As a result, I’m making an informed judgement call, based upon
> discussions so far and the options available to us. I do not do so lightly,
> and have been in active consultation with many of those it will affect, as
> well as IETF leadership. If that call is wrong, I’m confident that the WG
> will correct it, but again, that is *not* voting.
> >
> different from making a *proposal*, discuss it over here (and maybe *then*
> make a decision).
>
> I would put it differently. I see only one viable path forward at this
> point in time, based upon the myriad constraints we face. If another
> becomes available, of course we will consider it.
>
> >> Of course. I’ve announced what I believe our current state is; if there
> is serious pushback that has technical merit, we’ll have to revisit it. And
> as I’ve said many times, I’m open to proposals — especially those that can
> a) gain consensus b) actually get implemented and c) get approved by the
> whole IETF community. Haven’t seen any others yet.
> >
> web ("http") is affected (in that either users keep getting redirected, or
> bookmarks/links will have to change)?
>
> I do want to explore this issue; we might need to either layer on
> opportunistic encryption (which is NOT yet firmly ruled out; we’ll evaluate
> whether it’s still needed as we progress), modify our charter, or address
> it in some other way.
>
> Regards,
>
> --

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 14 Nov 2013 00:27:13 +0800

Hi Peter,

We have a group of people working on use cases and proposals for that very topic now. 

Regards,

On 14 Nov 2013, at 12:25 am, Peter Lepeska <[email-masked]> wrote:

> I'd like to see the group hold off on making this decision until we've also come up with an agreed upon way for proxies to function in an HTTP2, all TLS Internet. Without it we're essentially requiring proxies to do MITM to function. Is this increasing security?
> 
> Peter
> 
>

---

From: Peter Lepeska <[email-masked]>
Date: Wed, 13 Nov 2013 11:27:59 -0500

That's great. Let me know if I can help.

Peter

On Wed, Nov 13, 2013 at 11:27 AM, Mark Nottingham <[email-masked]> wrote:

> > I'd like to see the group hold off on making this decision until we've
> also come up with an agreed upon way for proxies to function in an HTTP2,
> all TLS Internet. Without it we're essentially requiring proxies to do MITM
> to function. Is this increasing security?
> >
> > Peter
> >
> >
> > >> Of course. I’ve announced what I believe our current state is; if
> there is serious pushback that has technical merit, we’ll have to revisit
> it. And as I’ve said many times, I’m open to proposals — especially those
> that can a) gain consensus b) actually get implemented and c) get approved
> by the whole IETF community. Haven’t seen any others yet.
> > >

---

From: Peter Lepeska <[email-masked]>
Date: Wed, 13 Nov 2013 11:45:25 -0500

Seems like this decision (requiring TLS for HTTP2) is dependent on the
details of the proxy inter-operability issue. And so it should wait until
that gets ironed out.

Also I want to go on record agreeing with Julian that the hums were
inconclusive. And this was partially b/c the options were not well defined
and the "I can't live with" approach was confusing and also I think b/c
there was no "rough consensus".

Thanks,

Peter

On Wed, Nov 13, 2013 at 11:27 AM, Peter Lepeska <[email-masked]>wrote:

>> > > Well, your mail makes it sound as if a decision already has been
>> made, and that you're willing to revisit it if the WG pushes back. That's

---

From: Tao Effect <[email-masked]>
Date: Wed, 13 Nov 2013 12:14:34 -0500

On Nov 13, 2013, at 11:25 AM, Peter Lepeska <[email-masked]> wrote:
> 
> Without it we're essentially requiring proxies to do MITM to function. Is this increasing security?

The only thing worse than no security, is a false sense of security.

:-p

- Greg

P.S. Please disregard the duplicate email accidentally sent from my other account.

---

From: Tim Bray <[email-masked]>
Date: Wed, 13 Nov 2013 09:18:58 -0800

tl;dr: Opportunistic encryption being thrown over the side.  I do not think
this reflects the consensus I heard in the room or see on the mailing list.

(Or am I missing something?)

On Wed, Nov 13, 2013 at 2:01 AM, Mark Nottingham <[email-masked]> wrote:

> In Vancouver, we continued the discussion that we started in Berlin
> regarding the use of encryption in HTTP/2.
>
> There seems to be strong consensus to increase the use of encryption on
> the Web, but there is less agreement about how to go about this.
>
> A. Opportunistic encryption for http:// URIs without server
> authentication -- a.k.a. "TLS Relaxed" as per
> draft-nottingham-http2-encryption.
>
> B. Opportunistic encryption for http:// URIs with server authentication
> -- the same mechanism, but not "relaxed", along with some form of downgrade
> protection.
>
> C. HTTP/2 to only be used with https:// URIs on the "open" Internet.
> http:// URIs would continue to use HTTP/1 (and of course it would
> In subsequent discussion, there seems to be agreement that (C) is
> preferable to (B), since it is more straightforward; no new mechanism needs
> to be specified, and HSTS can be used for downgrade protection.
>
> The strongest objections against (A) seemed to be about creating confusion
> about security and discouraging use of "full" TLS, whereas those against
> (C) were about limiting deployment of better security.
>
> Keen observers have noted that we can deploy (C) and judge adoption of the
> new protocol, later adding (A) if neccessary. The reverse is not
> necessarily true.
>
> Furthermore, in discussions with browser vendors (who have been among
> those most strongly advocating more use of encryption), there seems to be
> good support for (C), whereas there's still a fair amount of
> doubt/disagreement regarding (A).
>
> As a result, I believe the best way that we can meet the goal of
> increasing use of TLS on the Web is to encourage its use by only using
> HTTP/2.0 with https:// URIs.
>
> This can be effected without any changes to our current document; browser
> vendors are not required to implement HTTP/2.0 for http:// URIs today.
> However, we will discuss formalising this with suitable requirements to
> encourage interoperability; suggestions for text are welcome.
>
> To be clear - we will still define how to use HTTP/2.0 with http:// URIs,
> because in some use cases, an implementer may make an informed choice to
> use the protocol without encryption. However, for the common case --
> browsing the open Web -- you'll need to use https:// URIs and if you want
> to use the newest version of HTTP.
>
> * Alternate approaches to proxy caching (such as peer-to-peer caching
> protocols) may be proposed here or elsewhere, since traditional proxy
> caching use cases will no longer be met when TLS is in wider use.
>
> * As discussed in the perpass BoF, strengthening how we use TLS (e.g., for
> Perfect Forward Security) is on the table.
>
> * A number of people expressed interest in refining and/or extending how
> proxies work in HTTP (both 1.0 and 2.0), as discussed in
> draft-nottingham-http-proxy-problem (among many other relevant drafts).
>
> Furthermore, other security-related work in the IETF (see the perpass BoF)
> and elswhere (e.g., W3C) may affect HTTP. For example, a number of people
> have pointed out how weaknesses in PKIX affect the Web.
>
> Your input, as always, is appreciated. I believe this approach is as close
> to consensus as we're going to get on this contentious subject right now.
> As HTTP/2 is deployed, we will evaluate adoption of the protocol and might
> revisit this decision if we identify ways to further improve security.
>
>
>

---

From: James M Snell <[email-masked]>
Date: Wed, 13 Nov 2013 09:22:06 -0800

To be honest, much of this comes across to me as knee-jerk security
theater. Sure, using TLS is a good thing, but by itself it doesn't
come even remotely close to dealing with the range of fundamental
security and privacy issues that have come to light over the past few
months. If not handled properly, it could definitely give a false
sense of security.

[snip]
> The most relevant proposals were:

FWIW, I intend to make another proposal once (a) the base http/2
protocol is complete and (b) protocol extensions have been dealt with
properly.

[snip]
> As a result, I believe the best way that we can meet the goal of increasing use of TLS on the Web is to encourage its use by only using HTTP/2.0 with https:// URIs.

-1. HTTP/2 should not be limited to TLS only. If someone wishes to
craft text that strongly encourages use of TLS in specific
applications of HTTP/2, then that would be fine. But the protocol
itself should not require it.

> This can be effected without any changes to our current document; browser vendors are not required to implement HTTP/2.0 for http:// URIs today. However, we will discuss formalising this with suita…

FWIW, I have to concur with the others on this thread, Mark. The
language you're using here makes it sound like the decision has
already been made.

> To be clear - we will still define how to use HTTP/2.0 with http:// URIs, because in some use cases, an implementer may make an informed choice to use the protocol without encryption. However, for…

Again, -1 to making this a normative requirement. Our task ought to be
ensuring that people who bother to read the specification are fully
informed of the choices they are making, and not to make those choices
for them. Yes, I get it, some security is better than no security, but
adding constraints that only partially address the problem, just
because it makes us feel good or because it looks better from a PR
perspective, is not the right approach.

What I think would be helpful is taking some time to draw up a description of:

  1. The specific types of threats to HTTP/1.1 and HTTP/2 we feel are
significant.
  2. The specific types of threats we collectively feel ought to be
addressed by HTTP/2, and the ones we feel are beyond our scope
  3. A broader list of options for how those threats can be mitigated

In other words, an I-D describing the relevant threat model.

Once we have that, we can make a more informed collective decision.

- James

---

From: Tim Bray <[email-masked]>
Date: Wed, 13 Nov 2013 09:31:06 -0800

> months. If not handled properly, it could definitely give a false

Let’s not let the perfect be the enemy of the good.

FWIW, here’s one voice in support of HTTP/2==TLS.  And another saying let’s
not give up on opportunistic encryption.

> > This can be effected without any changes to our current document;
> browser vendors are not required to implement HTTP/2.0 for http:// URIs
> today. However, we will discuss formalising this with suitable requirements
> to encourage interoperability; suggestions for text are welcome.
> >
>
> > To be clear - we will still define how to use HTTP/2.0 with http://URIs, because in some use cases, an implementer may make an informed choice
> to use the protocol without encryption. However, for the common case --
> > * As discussed in the perpass BoF, strengthening how we use TLS (e.g.,
> for Perfect Forward Security) is on the table.
> >
> > Furthermore, other security-related work in the IETF (see the perpass
> BoF) and elswhere (e.g., W3C) may affect HTTP. For example, a number of
> people have pointed out how weaknesses in PKIX affect the Web.
> >
> > Your input, as always, is appreciated. I believe this approach is as
> close to consensus as we're going to get on this contentious subject right
> now. As HTTP/2 is deployed, we will evaluate adoption of the protocol and
> might revisit this decision if we identify ways to further improve security.
> >
> >
>
>

---

From: Tao Effect <[email-masked]>
Date: Wed, 13 Nov 2013 12:46:19 -0500

On Nov 13, 2013, at 12:31 PM, Tim Bray <[email-masked]> wrote:
> FWIW, here’s one voice in support of HTTP/2==TLS.

Not much content there supporting your vote. :-(

A vote doesn't count (in my book at least), if it doesn't have strong rationale before it.

To me this also comes across as security theater (what a wonderful expression).

Let's get this clear:

1. Perfection is not being requested. Just something other than "abysmal".

2. TLS that depends on CAs is not by any means "good". It is bad. Very bad. I would even support a viewpoint that says it's worse than HTTP because of the false sense of security that it gives people.

- Greg

On Nov 13, 2013, at 12:31 PM, Tim Bray <[email-masked]> wrote:

> FWIW, here’s one voice in support of HTTP/2==TLS.  And another saying let’s not give up on opportunistic encryption.
> 
> 
> 
>  
> 
>

---

From: Mike Belshe <[email-masked]>
Date: Wed, 13 Nov 2013 10:14:27 -0800

Agree with Tim; I am also in support of 100% TLS all the time.

I would like us to do both Mark's proposals:
   (A)  opportunistic upgrade of http to SSL
and
   (C) HTTP/2.0 is TLS all the time.

Mike

On Wed, Nov 13, 2013 at 9:46 AM, Tao Effect <[email-masked]> wrote:

> 2. TLS that depends on CAs is not by any means "good". It is *bad.* Very
> bad. I would even support a viewpoint that says it's worse than HTTP
> because of the false sense of security that it gives people.
>
> - Greg
>
> --
> FWIW, here’s one voice in support of HTTP/2==TLS.  And another saying
> let’s not give up on opportunistic encryption.
>
>
>
>
>
>>
>>
>> browsing the open Web -- you'll need to use https:// URIs and if you
>> want to use the newest version of HTTP.
>> >
>>
>> > * A number of people expressed interest in refining and/or extending
>> how proxies work in HTTP (both 1.0 and 2.0), as discussed in

---

From: Michael Sweet <[email-masked]>
Date: Wed, 13 Nov 2013 13:26:31 -0500

Honestly if there is no unencrypted path then you are just updating HTTPS, not HTTP/1.1.

---

From: Tao Effect <[email-masked]>
Date: Wed, 13 Nov 2013 13:27:38 -0500

> Agree with Tim; I am also in support of 100% TLS all the time.

Here are some nice quotes from the EFF about the system you are supporting (without any explanation):

As we learned from the SSL Observatory project, there are 600+ Certificate Authorities that your browser will trust; the attacker only needs to find one of those 600 that she is capable of breaking into. This has been happening with catastrophic results.

Certificate-based attacks are a concern all over the world, including in the U.S., since governments everywhere are eagerly adopting spying technology to eavesdrop on the public. Vendors of this technology seem to suggest the attacks can be done routinely. 

In many cases, people's lives are literally ended (or destroyed) because of this system.

I do not support such a system, and am very suspicious of folks voicing their support without a word of explanation.

I am reminded of how easy it is for a malicious entity to infiltrate a group and manipulate their opinion through sock-puppets. Not to say that you are one, but it's something that I'm reminded of each time I come across these types of situations.

Let's not have another NSA/NIST situation here.

Links:

https://www.eff.org/deeplinks/2011/03/iranian-hackers-obtain-fraudulent-https
https://www.eff.org/deeplinks/2011/09/post-mortem-iranian-diginotar-attack

Cheers,
Greg

---

From: Rob Trace <[email-masked]>
Date: Wed, 13 Nov 2013 18:36:55 +0000

We are one browser vendor who is in support of HTTP 2.0 for HTTP:// URIs.  The same is true for our web server.  I also believe that we should strongly encourage the use of TLS with HTTP, but not at the expense of creating a standard that is as broadly applicable as HTTP 1.1.

I think this statement correctly captures the proposal:

> To be clear - we will still define how to use HTTP/2.0 with http://

> URIs, because in some use cases, an implementer may make an

> informed choice to use the protocol without encryption.

This is essentially what the document states today and this would fulfill the requirements from the charter.

-Rob

From: Michael Sweet [mailto:[email-masked]]
Sent: Wednesday, November 13, 2013 10:27 AM
To: Mike Belshe
Cc: Tao Effect; Tim Bray; James M Snell; Mark Nottingham; HTTP Working Group
Subject: Re: Moving forward on improving HTTP's security

On Nov 13, 2013, at 1:14 PM, Mike Belshe <[email-masked]<mailto:[email-masked]>> wrote:

Mike

On Wed, Nov 13, 2013 at 9:46 AM, Tao Effect <[email-masked]<mailto:[email-masked]>> wrote:
On Nov 13, 2013, at 12:31 PM, Tim Bray <[email-masked]<mailto:[email-masked]>> wrote:
Let's not let the perfect be the enemy of the good.

FWIW, here's one voice in support of HTTP/2==TLS.

Let's get this clear:

- Greg

On Nov 13, 2013, at 12:31 PM, Tim Bray <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Nov 13, 2013 at 9:22 AM, James M Snell <[email-masked]<mailto:[email-masked]>> wrote:

Let's not let the perfect be the enemy of the good.

FWIW, here's one voice in support of HTTP/2==TLS.  And another saying let's not give up on opportunistic encryption.

On Wed, Nov 13, 2013 at 2:01 AM, Mark Nottingham <[email-masked]<mailto:[email-masked]>> wrote:
[snip]

[snip]

- James

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 13 Nov 2013 10:42:30 -0800

I think people should decouple the discussion from TLS. The key part of the
various channels is the reliance on secure channels. If there are issues
with TLS or the PKI or whatever we're relying on for the secure channel,
let's fix it. If you want to discuss those issues, please address them in
the appropriate working group.

On Wed, Nov 13, 2013 at 10:27 AM, Tao Effect <[email-masked]> wrote:

> *As we learned from the SSL Observatory <https://www.eff.org/observatory>
> project, there are 600+ Certificate Authorities
> <https://www.eff.org/files/colour_map_of_CAs.pdf> that your browser will
> trust; the attacker only needs to find one of those 600 that she is capable
> of breaking into. This has been
> <https://www.eff.org/deeplinks/2011/03/iranian-hackers-obtain-fraudulent-https>
> happening
> <https://www.eff.org/deeplinks/2011/08/iranian-man-middle-attack-against-google>
> with catastrophic results
> <https://www.eff.org/deeplinks/2011/09/post-mortem-iranian-diginotar-attack>.*
>
>
> *Certificate-based attacks are a concern all over the world, including in
> the U.S. <https://twitter.com/#%21/csoghoian/status/111416087979114497>,
> since governments everywhere are eagerly adopting spying technology to
> eavesdrop on the public. Vendors of this technology seem to suggest the
> attacks can be done routinely
> <http://files.cloudprivacy.net/ssl-mitm.pdf>. *
>
>
> I do not support such a system, and am very suspicious of folks voicing
> their support without a word of explanation.
>
> I am reminded of how easy it is for a malicious entity to infiltrate a
> group and manipulate their opinion through sock-puppets. Not to say that
> you are one, but it's something that I'm reminded of each time I come
> across these types of situations.
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 13 Nov 2013 10:47:49 -0800

On 13 November 2013 10:42, William Chan (陈智昌) <[email-masked]> wrote:
> If there are issues with TLS or the PKI or whatever we're relying on for the
> secure channel, let's fix it.

Yes.  We outsource the bulk of HTTP security work to the SEC area
working groups, primarily TLS.  They are acutely aware of the issues
and are working on improving the situation.  Let's concentrate on what
we can do.

---

From: Tao Effect <[email-masked]>
Date: Wed, 13 Nov 2013 13:53:36 -0500

OK, I agree with this sentiment.

What worries me is the emphasis that I see being placed on HTTP 2.0 being "secure".

Perhaps it is somewhat of a marketing problem, but nevertheless, it's a marketing problem with potentially serious security consequences.

If HTTP/2.0 is flexible enough to allow for very different types of authentication practices than the ones currently done with the PKI/CA system, then I would support it.

Just make it _clear_ then that HTTP/2.0 is not about improving security.

If this is not made crystal clear, then people will continue to see news headlines on tech sites that give people the impression that something is actually being done to improve the internet's security with this "move to HTTP 2.0!", which is horse sh*t.

- Greg

---

From: Mike Bishop <[email-masked]>
Date: Wed, 13 Nov 2013 18:57:13 +0000

While the language may be strong, I agree with the sentiment that they are distinct mechanisms.  Mark has proposed a mechanism, independent of HTTP/2.0, which can be used to migrate from an HTTP connection to an HTTPS connection.  That’s a separate proposal from HTTP/2.0.  The actual “security” of HTTPS is entirely dependent on TLS and completely orthogonal to HTTP/2.0.

From: Tao Effect [mailto:[email-masked]]
Sent: Wednesday, November 13, 2013 10:54 AM
To: Martin Thomson
Cc: "William Chan (陈智昌)"; Mike Belshe; Tim Bray; James M Snell; Mark Nottingham; HTTP Working Group
Subject: Re: Moving forward on improving HTTP's security

- Greg

On Nov 13, 2013, at 1:47 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

On 13 November 2013 10:42, William Chan (陈智昌) <[email-masked]<mailto:[email-masked]>> wrote:

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 13 Nov 2013 11:06:37 -0800

Would it be unreasonable to request that we also not debate PR here, unless
it's directly pertinent to the internet drafts we are standardizing? I
don't really want to change how we do things just because of news headlines
on tech sites. I'd rather discuss the technical merits of encouraging
further use of secure communication channels in the various situations
described in Mark's original email.

On Wed, Nov 13, 2013 at 10:53 AM, Tao Effect <[email-masked]> wrote:

> Perhaps it is somewhat of a marketing problem, but nevertheless, it's a
> marketing problem with potentially serious security consequences.
>
> If HTTP/2.0 is flexible enough to allow for very different types of
> authentication practices than the ones currently done with the PKI/CA
> system, then I would support it.
>
> Just make it *_clear_* then that HTTP/2.0 *is not about improving
> security.*
>
> If this is not made crystal clear, then people will continue to see news
> headlines on tech sites that give people the impression that something is
> actually being done to improve the internet's security with this "move to
> HTTP 2.0!", which is horse sh*t.
>
> - Greg
>
> --

---

From: Tao Effect <[email-masked]>
Date: Wed, 13 Nov 2013 14:12:36 -0500

On Nov 13, 2013, at 2:06 PM, William Chan (陈智昌) <[email-masked]> wrote:

> Would it be unreasonable to request that we also not debate PR here, unless it's directly pertinent to the internet drafts we are standardizing? I don't really want to change how we do things just because of news headlines on tech sites. 

You're not being asked to change "how you do things".

You're being asked to not spread potentially dangerous misinformation.

- Greg

On Nov 13, 2013, at 2:06 PM, William Chan (陈智昌) <[email-masked]> wrote:

> Would it be unreasonable to request that we also not debate PR here, unless it's directly pertinent to the internet drafts we are standardizing? I don't really want to change how we do things just because of news headlines on tech sites. I'd rather discuss the technical merits of encouraging further use of secure communication channels in the various situations described in Mark's original email.
> 
>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 13 Nov 2013 11:16:52 -0800

On Wed, Nov 13, 2013 at 11:12 AM, Tao Effect <[email-masked]> wrote:

> Would it be unreasonable to request that we also not debate PR here,
> unless it's directly pertinent to the internet drafts we are standardizing?
> I don't really want to change how we do things just because of news
> headlines on tech sites.
>
>

Sorry, if we're spreading potentially dangerous misinformation, let's fix
that. Can you identify which internet draft has said information so we can
fix it?

> Would it be unreasonable to request that we also not debate PR here,
> unless it's directly pertinent to the internet drafts we are standardizing?
> I don't really want to change how we do things just because of news
> headlines on tech sites. I'd rather discuss the technical merits of
> encouraging further use of secure communication channels in the various
> situations described in Mark's original email.
>
>
> On Wed, Nov 13, 2013 at 10:53 AM, Tao Effect <[email-masked]>wrote:
>

---

From: Tao Effect <[email-masked]>
Date: Wed, 13 Nov 2013 14:32:00 -0500

On Nov 13, 2013, at 2:16 PM, William Chan (陈智昌) <[email-masked]> wrote:
> Sorry, if we're spreading potentially dangerous misinformation, let's fix that. Can you identify which internet draft has said information so we can fix it?

Am I limited to internet drafts? I haven't been following the ones on HTTP/2.0. Like most people, I'm dazzled by catchy subject titles.

- Greg

On Nov 13, 2013, at 2:16 PM, William Chan (陈智昌) <[email-masked]> wrote:

> Sorry, if we're spreading potentially dangerous misinformation, let's fix that. Can you identify which internet draft has said information so we can fix it?
>  
> 
> - Greg
> 
> --

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 13 Nov 2013 11:40:16 -0800

OIC, this is on Hacker News. That explains this. Yes, people like to read a
lot into how people word their emails on various mailing lists. Whatever.
If you want to be the email subject police, feel free. I'd rather get real
work done. Let's go back to the main discussion please.

On Wed, Nov 13, 2013 at 11:32 AM, Tao Effect <[email-masked]> wrote:

> Am I limited to internet drafts? I haven't been following the ones on
> HTTP/2.0. Like most people, I'm dazzled by catchy subject titles.
>
> - Greg
>
> --
> On Wed, Nov 13, 2013 at 11:12 AM, Tao Effect <[email-masked]>wrote:
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 13 Nov 2013 11:49:51 -0800

On Nov 13, 2013 11:32 AM, "Tao Effect" <[email-masked]> wrote:
>> Sorry, if we're spreading potentially dangerous misinformation, let's
fix that. Can you identify which internet draft has said information so we
can fix it?

Internet drafts (at least the ones with -ietf- in them) attempt to capture
the current consensus of the writing group, and by extension, the IETF.
They are imperfect, but they really are much better at tracking state than
mailing lists.

I encourage you to stay and help us figure this out. Please remember to
respect the fact that others do want what is best, and that disagreements
generally only arise from small differences in view on what a good outcome
looks like and what the best approach in achieving that outcome might be.
Even if you think someone is a sock puppet (and I certainly don't know of
anyone who I'd apply that label to here), calling them one to their face
isn't going to help.

---

From: Tao Effect <[email-masked]>
Date: Wed, 13 Nov 2013 14:58:35 -0500

Thanks Martin,
> calling them one to their face isn't going to help.
> 
Note that I didn't call anyone a sock-puppet (I explicitly denied doing so). From the wording though, I can see how you might have thought I'd implied it:

"Not to say that you are one, but it's something that I'm reminded of each time I come across these types of situations."

- Greg

On Nov 13, 2013, at 2:49 PM, Martin Thomson <[email-masked]> wrote:

> Internet drafts (at least the ones with -ietf- in them) attempt to capture the current consensus of the writing group, and by extension, the IETF. They are imperfect, but they really are much better at tracking state than mailing lists.
> 
> I encourage you to stay and help us figure this out. Please remember to respect the fact that others do want what is best, and that disagreements generally only arise from small differences in view on what a good outcome looks like and what the best approach in achieving that outcome might be. Even if you think someone is a sock puppet (and I certainly don't know of anyone who I'd apply that label to here), calling them one to their face isn't going to help.
>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 13 Nov 2013 12:01:42 -0800

Well, it should be no surprise that the Chromium project is still planning
on supporting HTTP/2 only over a secure channel (aka TLS unless something
better comes along...). So, that's (C).

As to opportunistic encryption, we have mixed opinions on the team on that.
Mike, Tim, can you explain why you like (A)? Here are some concerns I've
heard on it:
* The marginal security benefit of unauthenticated encryption is fairly
marginal. Which adversary is this intended to defeat? It might defeat
something like Firesheep for now, until tools like that get updated to MITM
as well. Does it shift the economics very much on passive pervasive
monitoring? What wins do y'all foresee here?
* As for downsides, will people read too much into the marginal security
benefit and thus think that it's OK not to switch to HTTPS? If so, that
would be terrible. It's hard to assess how large this risk is though. Do
you guys have thoughts here?

---

From: Tim Bray <[email-masked]>
Date: Wed, 13 Nov 2013 12:18:16 -0800

> monitoring? What wins do y'all foresee here?

Shifting the economics on pervasive surveillance seems like the big deal to
me. It becomes much less attractive for three-letter agencies to just
collect everything and data-mine it.  MITM-ing on a large scale doesn’t
sound very practical.

> you guys have thoughts here?

I agree that’s a risk, but we’re all kind of talking out of our asses here
because we don’t have any data.  My intuition is that people who actually
understand the issues will understand the shortcomings of opportunistic and
not use it where inappropriate, and people who don’t get why they should
encrypt at all will get some encryption happening anyhow.  But intuition is
a lousy substitute for data.

>> On Wed, Nov 13, 2013 at 9:46 AM, Tao Effect <[email-masked]>wrote:
>>
>>> On Wed, Nov 13, 2013 at 9:22 AM, James M Snell <[email-masked]>wrote:
>>>
>>>> browser vendors are not required to implement HTTP/2.0 for http://URIs today. However, we will discuss formalising this with suitable
>>>> requirements to encourage interoperability; suggestions for text are
>>>> welcome.
>>>> >
>>>>
>>>> > * As discussed in the perpass BoF, strengthening how we use TLS
>>>> (e.g., for Perfect Forward Security) is on the table.
>>>> >

---

From: Mike Belshe <[email-masked]>
Date: Wed, 13 Nov 2013 12:25:55 -0800

On Wed, Nov 13, 2013 at 12:01 PM, William Chan (陈智昌)
<[email-masked]>wrote:

> As to opportunistic encryption, we have mixed opinions on the team on
> that. Mike, Tim, can you explain why you like (A)? Here are some concerns
> I've heard on it:

That's exactly right.  The argument that we shouldn't do it because it only
works "until tools get updated to MITM" doesn't work for me, because that's
just  the way security is.  You never finish "security", you just keep
raising the bar.

Given the widespread snooping that has been so widely publicized in recent
months, I think it is imperative that we raise the bar here now.

> you guys have thoughts here?

I hadn't even considered this - its so odd!  I can't see anyone not using
TLS because of this - if you don't know when you need TLS, then you
probably won't notice that we're encrypting your HTTP.  So I see it as
something that just protects users automagically without them even knowing.
  I don't believe this as a serious concern.

Mike

---

From: Mike Belshe <[email-masked]>
Date: Wed, 13 Nov 2013 12:41:50 -0800

<off topic conspiracy theory>

I wonder how many of those on this list arguing against TLS are either
    a) hackers
    b) working for the NSA or some other government agency
    c) otherwise actively leveraging plaintext HTTP today for business or
pleasure

Because honestly, unless you're one of those people, there is no good
reason not to be 100% encrypted now.

And I'm tired of hearing the "backoffice" argument - recent developments
prove that even the backoffice needs to be 100% encrypted.  Ok - sorry, I'm
ranting now...:-)

</off topic>

On Wed, Nov 13, 2013 at 12:25 PM, Mike Belshe <[email-masked]> wrote:

>
>
>
> On Wed, Nov 13, 2013 at 12:01 PM, William Chan (陈智昌) <
> [email-masked]> wrote:
>
>> Well, it should be no surprise that the Chromium project is still
>> planning on supporting HTTP/2 only over a secure channel (aka TLS unless
>> something better comes along...). So, that's (C).
>>
> That's exactly right.  The argument that we shouldn't do it because it
> only works "until tools get updated to MITM" doesn't work for me, because
> that's just  the way security is.  You never finish "security", you just
> keep raising the bar.
>
>>>>> > * Alternate approaches to proxy caching (such as peer-to-peer
>>>>> caching protocols) may be proposed here or elsewhere, since traditional
>>>>> proxy caching use cases will no longer be met when TLS is in wider use.
>>>>> >
>>>>> > Furthermore, other security-related work in the IETF (see the
>>>>> perpass BoF) and elswhere (e.g., W3C) may affect HTTP. For example, a
>>>>> number of people have pointed out how weaknesses in PKIX affect the Web.
>>>>> >

---

From: Zhong Yu <[email-masked]>
Date: Wed, 13 Nov 2013 15:04:14 -0600

I don't think anybody is "arguing against TLS". You like TLS, more power to you.

However isn't it kind of presumptuous for some people to mandate it
for everybody, for the greater good of course, even though a lot of
people, perhaps not super smart, but possessing basic analytic skills
nevertheless, decide for themselves that TLS is not the best choice,
based on their own constraints and interests?

Zhong Yu

On Wed, Nov 13, 2013 at 2:41 PM, Mike Belshe <[email-masked]> wrote:
> Because honestly, unless you're one of those people, there is no good reason
> not to be 100% encrypted now.
>
>> <[email-masked]> wrote:
>>>
>>> would be terrible. It's hard to assess how large this risk is though. Do you
>>> guys have thoughts here?
>>
>>
>> TLS because of this - if you don't know when you need TLS, then you probably
>> won't notice that we're encrypting your HTTP.  So I see it as something that
>> just protects users automagically without them even knowing.   I don't
>> believe this as a serious concern.
>>
>> Mike
>>
>>
>>
>>
>>
>>>
>>>
>>>
>>>>> 2. TLS that depends on CAs is not by any means "good". It is bad. Very
>>>>> bad. I would even support a viewpoint that says it's worse than HTTP because
>>>>> of the false sense of security that it gives people.
>>>>>
>>>>> - Greg
>>>>>
>>>>> --
>>>>>> > URIs, because in some use cases, an implementer may make an informed choice
>>>>>> > browsing the open Web -- you'll need to use https:// URIs and if you want to
>>>>>> > use the newest version of HTTP.
>>>>>> >
>>>>>>
>>>>>> > perpass BoF) and elswhere (e.g., W3C) may affect HTTP. For example, a number
>>>>>> > of people have pointed out how weaknesses in PKIX affect the Web.
>>>>>> >

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 13 Nov 2013 22:05:49 +0100

Hi Mike,

On Wed, Nov 13, 2013 at 12:25:55PM -0800, Mike Belshe wrote:
> The argument that we shouldn't do it because it only

At least now I know where the bar is : if my browser tells me I'm encrypted,
I'm supposed to be secure by current standards. Otherwise I'm not supposed
to.

With the always-on method you're advocating for, I'll have no way to tell
whether I am or not. Still the MITM will continue to happen because there
are many legitimate needs for this (whether it's caching, malware protection
or protecting your kids against rapist which chase online). And users will
not have this indicator anymore telling them whether they're MITM-able or
not.

At the moment the situation is quite clear :
  - you're in HTTP, you're MITM-ed. Period. You're likely to pass through
    an intercepting caching proxy at your ISP etc... so let's say you're
    almost 100% sure to be MITM-ed.

  - you're in HTTPS at home, excluding the malware running in the browser
    and the rogue certificates, you're supposed to be secured.

  - you're in HTTPS at your company with the browser deployed by your
    employer, you have to check with your employer (or in your browser)
    if the browser is configured to accept an intercepting proxy's certs
    or not.

But with all-TLS it's not possible to tell the difference anymore, because
ISPs will require that end users use connection kits as it was done 20 years
ago which contain their certificates that you need to install in your browser,
and these certs will be stored in an even worse way than the current 600 CAs.
So you'll be apparently HTTPs all the time from home, but with no easy way to
tell whether you're MITM-ed by your ISP or not, nor by anyone else who has
already stolen your ISP's certs.

And that's definitely not the Internet I want. I want to continue to connect
to PayPal securely and to read some blogs/forums without having to click to
pass through outdated certificates or those which were emitted for the main
domain and not the sub-domain ones, just to give a few examples of what is
commonly encountered. I want to be able to trust my connection when I need
to. Not to be taught I must trust it otherwise I have no access.

Willy

---

From: Mike Belshe <[email-masked]>
Date: Wed, 13 Nov 2013 13:23:41 -0800

> not have this indicator anymore telling them whether they're MITM-able or

To paraphrase, you're saying:
   "I don't like TLS because I use the presence of TLS to know that I could
be hacked right now.   But if you turn on TLS always, I won't be able to
tell if I can get hacked."

This makes no sense whatsoever.

> to. Not to be taught I must trust it otherwise I have no access.

To summarize:
  1) You're happy with the security you get with TLS to Paypal now
  2) You're unhappy with that same security (TLS) enforced everywhere
because it is suddenly less secure.

This is also illogical.  We're not changing TLS.

Mike

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 13 Nov 2013 22:54:04 +0100

> tell if I can get hacked."

Huh ? No. I mean "The TLS model is fine for me as long as it's used where
needed and if it's not abused because I expect all actors in the chain to
care about security". Let's ensure we don't break that weak link from the
root CAs to me by making its use mandatory for all no-value stuff that
nobody cares about and which will make it normal for everyone to deploy
broken configs and rogue CAs everywhere for the sake of simplicity.

> because it is suddenly less secure.

Exactly.

> This is also illogical.  We're not changing TLS.

Yes you are. You're not changing the protocol but the economics and
the actors' motives to deliver certs the proper way. When certs are
needed to connect to my printer, I doubt I'll have to order a new
cert every year to connect to it once every 3 years at most to change
its IP address. Instead the manufacturer will want a 10 years cert,
and since he won't be able to get that, some CAs will start to offer
this (possibly at a high price). We'll possibly find it much easier
and cheaper to become a valid CA and to issue certs for anyone. I'm
sorry but the day I can issue a paypal cert myself and have my browser
accept it without me having to do anything with its configuration, I'll
start to get a little bit scared.

Right now it's simple : TLS is annoying to deploy so you do it where
it matters. It can be free but at least it requires some care and you
are willing to accept that for the sites you value. Once you don't
value anymore the certs you are installing and users start to do wrong
things such as clicking 100 times a day "Ignore this cert error" because
everyone uses crappy certs, the TLS model will be useless.

Willy

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 13 Nov 2013 21:57:46 +0000

I have to agree that the logic here is hard to find.

> broken configs and rogue CAs everywhere for the sake of simplicity.

Break the link by making it mandatory sounds like wild supposition.

S

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 13 Nov 2013 23:07:56 +0100

> Break the link by making it mandatory sounds like wild supposition.

Well, TLS was supposedly unbreakable till it became the norm to break
it on MITM proxies in companies. When there's a good reason for doing
it, the adequate methods are deployed. Whether they are "you just need
to install the attached certs in your browser to get rid of the warnings
when you're browsing" or "you may only use the browser preinstalled on
the PC".

Right now there's no motive for doing so. When ISPs with small links and
big caches will see they have two choices :
  - send a cert to all their customers
  - multiply their bandwidth by 10

Do you really think they'll pick the second one ? No, they'll do the first
one and only multiply the pipe by 2 do handle the few users who accept to
pay more for getting rid of the cache without sacrificing the security. It
is very simple, users will definitely accept this en masse because they
don't care. It already works perfectly in large companies and everyone is
happy with that. And better, with most of the bandwidth going to smartphones,
themselves massively sold by mobile providers, it will be transparent for the
user, the phone will come preinstalled with the "valid certs" and it will be
mentionned in the contract that the ISP reserves the right to see the traffic
in cleartext for law enforcement and everyone will accept except a few, just
the same that absolutely want to get the sources of every component in their
phones and which no ISP wants to have as customers.

I don't see how hard it is to understand in fact :-/

Willy

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 13 Nov 2013 14:11:40 -0800

Please Mike, tell us what you _really_ think :P

On Wed, Nov 13, 2013 at 12:41 PM, Mike Belshe <[email-masked]> wrote:

>> Given the widespread snooping that has been so widely publicized in
>> recent months, I think it is imperative that we raise the bar here now.
>>
>
I think we're in agreement here. This is raising the bar. The question is
how much. And to weigh them against the costs. Which is why I'm curious
about your thoughts here about how much it raises the bar. And also curious
about your thoughts on the costs as discussed below. Do you think it
significantly raises the bar?

>>   I don't believe this as a serious concern.
When we talk about the choice of using TLS, we're primarily talking about
server operators here. And to be clear, the opportunistic encryption
mechanism relies on server-side configuration (perhaps set as default), to
set up either DNS or HTTP response headers (a la Alternate-Protocol or
Alt-Svc) or something like that to advertise that it's OK to send HTTP URIs
to port 443. So yeah, this configuration must exist (unless it's forced on,
which I don't see happening), even if it's set by default in common
packages. Now the scenarios that seem possibly concerning are:
1) if a server operator wants security, said operator may examine the
configuration and think "Oh good, this encryption option is enabled by
default!" and stop there.
2) if a server operator wants to make the website secure and looks into
what it takes to enable HTTPS for it. Said operator sees this
configuration, but notes that it's not authenticated. That's suboptimal, so
maybe fix it?
  a) The next step is to look into acquiring a certificate, but that's a
PITA and sometimes costly (woo StartSSL free certs!). Maybe just settle for
unauthenticated encryption, because it's nearly as good, right?
  b) The next step is to look into fixing all the mixed content issues with
the website in order to switch on HTTPS. Despair ensues because fixing
mixed content is a PITA. So the operator goes back to looking at the
configuration option and thinks "Well, fixing the website so I can switch
to HTTPS is a PITA, so why don't I settle for this unauthenticated
encryption? It's almost as good, right?".

These are all scenarios where I don't want people to settle for
unauthenticated encryption. They should go full HTTPS ftw! But as Tim
points out, we're all talking out of our asses here. I don't feel
especially confident of my intuitions. I don't have any data here, beyond
all the data that shows that people don't understand security, which makes
me concerned about people understanding how marginal the value of
opportunistic unauthenticated encryption is. I just fear that in our desire
to do good here, we may ultimately worsen the security of the web. Are you
very confident that offering an option for opportunistic unauthenticated
encryption is clearly a win here?

As an aside, it might be nice if we channeled people's desire to improve
security towards more clearly productive activities. Brian Smith made a
similar comment at IETF last week. I really like the idea of expending more
effort in automating/simplifying SSL configuration at webservers. It'd be
great if during webserver setup, it prompted if you wanted an SSL cert and
automated/simplified the acquisition and setup of the certificate. There
are probably a lot of gotchas/pitfalls with this, but I want to think that
they are solvable.

Cheers.

>>>>>> > * A number of people expressed interest in refining and/or
>>>>>> extending how proxies work in HTTP (both 1.0 and 2.0), as discussed in
>>>>>> > Your input, as always, is appreciated. I believe this approach is
>>>>>> as close to consensus as we're going to get on this contentious subject
>>>>>> right now. As HTTP/2 is deployed, we will evaluate adoption of the protocol
>>>>>> and might revisit this decision if we identify ways to further improve
>>>>>> security.
>>>>>> >
>>>>>> >
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

---

From: Mike Belshe <[email-masked]>
Date: Wed, 13 Nov 2013 14:32:19 -0800

> I don't see how hard it is to understand in fact :-/

Look, we've had this debate time and time again and its always the people
with vested interests that are against TLS.  I have yet to hear from a
single person that is against TLS who isn't either a hacker, a government
agent, or a seller of software which relies on unsecured traffic.  Not one.
 Actually, the hackers don't care that much.

I do hear what you're writing, that you think use of more TLS will somehow
cripple existing TLS, but you're ignoring that it is hackable now...  Our
use of it doesn't change that.  Despite shortcomings, we do need to raise
the bar -  there is real, documented evidence of that.  And TLS will evolve
too, and we (http) will evolve with it.

Upwards and onwards!

Mike

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 13 Nov 2013 22:36:50 +0000

I thought we already did the mandatory TLS argument to death many times.

We added MITM in WinGate mostly because Google and FB went to https.  
Google and FB you may take a bow.

Does this improve security of the web overall?  IMO no.  People can now 
snaffle banking passwords with a filter plugin.

You really want to scale this out?  How will that make it any better?

You're suggesting anyone wanting to run an http2 server now has to 
purchase, and pay for the ongoing maintenance of a cert, and take the 
cost on additional CPU to handle the load?

Organisations have to live with the pain in the neck of deploying 
signing certs to clients, dealing with visitor devices etc etc.  This = 
reduction in user experience.

So, IMO making TLS mandatory = reduced security, worse user experience, 
and increased costs.

That's progress I guess.

------ Original Message ------
From: "Stephen Farrell" <[email-masked]>
To: "Willy Tarreau" <[email-masked]>; "Mike Belshe" <[email-masked]>
Cc: "William Chan (?????????)" <[email-masked]>; "Tao Effect" 
<[email-masked]>; "Tim Bray" <[email-masked]>; "James M 
Snell" <[email-masked]>; "Mark Nottingham" <[email-masked]>; "HTTP 
Working Group" <[email-masked]>
Sent: 14/11/2013 10:57:46 a.m.
Subject: Re: Moving forward on improving HTTP's security

---

From: James M Snell <[email-masked]>
Date: Wed, 13 Nov 2013 14:40:24 -0800

On Wed, Nov 13, 2013 at 2:32 PM, Mike Belshe <[email-masked]> wrote:
[snip]
> Actually, the hackers don't care that much.

Such generalizations are pointless, really; and do nothing to move the
ball forward. FWIW, I am against mandatory TLS and I do not fall into
any of your categories above. Oh, certainly, there may very well
people others who work for the same company I do that might fall into
one of these categories, but I'm not here representing them, nor am I
here representing my employer. I'm here as an individual with
absolutely zero "vested interest" against TLS. I'm sure I am not the
only one who doesn't fit into the pigeon holes you have carved out, so
please, let's stop the pointless rhetoric and stick to the *technical*
merits of the proposals.

Strongly recommending the use of TLS is fine; even making it the
default option is fine; mandating TLS is not fine and could be
actively counterproductive to addressing the real underlying problems
by either providing a false sense of security or by actively
encouraging abuse.

- James

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 14 Nov 2013 11:51:35 +1300

On 2013-11-14 09:01, William Chan wrote:
> planning

Your choice. But thanks to your team for providing a new diriving force 
behind HTTPS-to-HTTP MITM gateways. It is causing a surprising amount of 
extra sales and consulting work over here. Forgive me for not repeating 
myself about the whys of that.

> that.

I posit that the actual benefit of it is actually zero, or possibly 
negative once the encryption overhead costs in terms of CPU and key 
management are accounted for. DANE is helping a lot in some cases, but 
there are still overheads.

HTTP/1 has long been capable of transferring messages with encrypted 
bodies and even partially encrypted headers. The level of uptake on that 
is very low. The only reason I can see for that changing is if 
implementers are given no choice in the matter, and the comments about 
chunked on this old Node.js thread is a good indicator of how popular 
that will be.
   [1] https://groups.google.com/forum/#!topic/nodejs/su23ZpGxhIw

> you guys have thoughts here?

More likely they will look at the imbalanced cost/benefit and shy away 
from both HTTPS and HTTP/2.0 entirely.

Or is that the intention here? to offer alternatives that are so 
obviously unworkable that adopting TLS is seen as the best thing by 
comparison despite all its flaws?

Amos

---

From: Karl Dubost <[email-masked]>
Date: Wed, 13 Nov 2013 18:09:25 -0500

(trimming the cc)

Le 13 nov. 2013 à 15:41, Mike Belshe <[email-masked]> a écrit :
>     c) otherwise actively leveraging plaintext HTTP today for business or pleasure

I'm one of this (indeed rare) person who is having a Web site, do not have analytics, do not have comments, or anything, do not set any cookies of any sort, etc. Plain HTTP works for me in the sense that it is easy to set up, and hack. Installing a server and requiring certificates is still not easy (in my scale of easy).

We should definitely push for better security. Make HTTP2 dependent on security everywhere might make it harder if the rest of the stack doesn't follow: Aka make it as dead simple to enable security than to start an http server. :)

-- 
Karl Dubost
http://www.la-grange.net/karl/

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 14 Nov 2013 00:16:26 +0100

>  Actually, the hackers don't care that much.

Mike, please stop saying I'm "against TLS", you sound like you don't read
or don't understand. I'm "for TLS" but "not for everything". And I'm in
neither category either.

> cripple existing TLS, but you're ignoring that it is hackable now...

No I don't ignore it. And I also know it's not the biggest weakness of the
Web right now either (mobile code in the form of malware is doing a lot more
harm than TLS). But at least we can still educate people for not blindly
clicking on "I accept the risk" all the day when they do this, and instead
teach them to read the details and accept or not depending on what they see
and the importance of the site they're visiting (eg: if forums.foo.com
presents a cert saying www.foo.com, and you're just looking for some hints
to configure your graphics driver, probably you don't mind about the warning).

Having them do so 1-3 times a day is probably acceptable. Doing it 10 times
more because the vast majority of the sites that will be forced to migrate
to TLS will have no interest in it and will not take care of doing it right
is a big problem.

> Our use of it doesn't change that.

For sure. So let's insist on something that you say yourself is already
hackable before we even have anything solid to base the design on ? Your
reasoning sounds strange to me (we'll use TLS only for HTTP/2 because
it's hackable so for sure it will improve).

> Despite shortcomings, we do need to raise the bar -  there is real,
> documented evidence of that.

I agree with that as well. My conviction is that doing what you plan to
do will not raise the bar at all but will put it on the floor. We're
allowed to disagree, we've had that conversation many times and at least
we're consistent. It's a matter of beliefs, just like people have political
opinions or religions.

> And TLS will evolve too, and we (http) will evolve with it.

Great, so let's see it evolve first.

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 14 Nov 2013 00:22:29 +0100

> by either providing a false sense of security or by actively

Perfectly agreed. I think that Mark's proposal of http2 by default
for TLS and 1.1 by default for HTTP is fine and balanced. It provides
incentive without making things mandatory. You want better experience ?
Use HTTP/2 with security. If a web site cares about response time it
will support HTTP/2 with security. Those who don't care will not have
to make that jump. And those who want/need to have the features of
HTTP/2 without security for whatever reasons will simply have to
change their browser's settings, use another browser, or maybe will
just use some libs or command line tools because this will not be
about a browser at all.

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 14 Nov 2013 00:27:43 +0100

> myself about the whys of that.

Speaking about sales, our customers now target larger models of load
balancers on average thanks to this new trend of putting TLS just to
look good. That's great, some sites have just one connection per client,
so we see only fresh new connections, the worst case! So they have to
buy a device capable of 60K HTTP CPS to use only 5K HTTPS CPS, for sure
the technical improvements pleases the sales people :-)

Willy

---

From: Eliot Lear <[email-masked]>
Date: Wed, 13 Nov 2013 15:59:40 -0800

Hi Mark,

Your proposal seems to logically follow from the exchange we had in the
plenary, that in essence this group should place a bet that the benefits
of HTTP2 would propel adoption of TLS.  Seems to me that is a good
research question where the answer would be a model of the sorts of
behaviors we can reasonably expect.

In the longer term, might we reasonably expect interoperability problems
due to incompatible national cryptographic standard mandates?  That is:
if the U.S. requires one form of encryption for a transaction and Russia
requires another, and there is no means to meet in the middle, there
will be no communication.  I don't know if this one can be mitigated,
but it should probably be studied.  Maybe the right thing is to not have
these systems communicate.  That would bound our all encompassing view
of interoperability, but maybe that's a good thing.  Balkanization,
however, is not.  Not all of these problems are this working group's, of
course.  Some cross over to layer 9.

Third, there are some who are doing object-level encryption and may not
desire transport encryption.

The WG might or might not not care about the answers to these
questions.  That is, perhaps HTTP2 is targeted to a specific
application, and we should allow for that.  But if that's the case, we
should perhaps say that.

Please don't take these questions as opposition to what you propose. 
Rather I am trying to understand the tradeoffs.

Eliot

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 14 Nov 2013 13:00:53 +1300

> everyone uses crappy certs, the TLS model will be useless.

I have come to disagree on the "right now" aspect. Several years ago, 
maybe even last year it was true. TLS was known for its use by banks and 
other organisations using it to protect financial or personal 
transactions of various kinds. Under these economics is was widely 
regarded by both network admin and their managers as a Good Thing(tm) to 
leave untouched, even to tunnel through the firewalls and other local 
security protections.

Since the relatively less important but very popular google and facebook 
services have been encrypted the situation has already almost been 
reversed. The belief in TLS being something to leave inviolate has 
disappeared almost completely and, as far as my experience goes, the 
only reason for *some* installations not performing MITM on HTTPS has 
been whether the organisation obeys the legal restraints.

Take careful note that we were talking about these as upcoming trend 
just last year, and unfortunately the swing trend has been accelerating 
extremely fast. This has already happened *without* the bulk of the 
Internet being TLS-enabled. The situation has become almost routine for 
new middleware installations to be setup with MITM of TLS ports under 
the business case that the routine transactions need to be governed - 
encrypted or not.

What we need for HTTP/2 in the way of security is something *better* 
than what "normal" TLS has to offer today (a little bit anyway). Whether 
that comes from the TLS WG or a feature design in HTTP/2 is what we need 
to be discussing. Lets end this enable-TLS-everywhere-and-well-be-fine 
B***sh*t.

Also, if you want something efficient over TLS just do SPDY. HTTP/2 
needs to be workable for the wider web than TLS/SSL enthusiasts.

AYJ

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 13 Nov 2013 16:09:33 -0800

> I thought we already did the mandatory TLS argument to death many times.

We did :) And I don't think we're going to convince one another here. I
feel like I understand your position and disagree with it. And I think the
vice versa is true. I stated my preference earlier, but I don't expect to
convince you. As much as it'd be nice to have the spec mandate this, so I
could use it as a weak hammer to beat people on the head with when they
don't want to use TLS, I don't really think we'll achieve rough consensus.
But I'll impose my will insofar as I can affect Chromium policy and push
more HTTPS adoption as much as I can.

>  Google and FB you may take a bow.

FWIW, I'm happy those companies went HTTPS, and I'm sad that y'all are
offering MITM features in your products. I suppose that if I ask you not to
MITM traffic, you wouldn't listen, would you? :P If you feel that MITM is
bad for the web, why are you implementing this? Is it simply because if you
don't, then someone else will and people will switch from your product?

> snaffle banking passwords with a filter plugin.

Just to be clear, the MITM works because the enterprises are adding new SSL
root certificates to the system cert store, right? I agree that that is
terrible. I wouldn't use that computer :) I hope we increase awareness of
this issue.

> You really want to scale this out?  How will that make it any better?

I believe that making communications secure by default will overall improve
the security of the web as long as most devices don't have these additional
SSL root certificates used by the MITM proxies. You are taking a cynical
view on the outcome when communications become secure by default. I
disagree. I think that it's worthwhile to force entities that want to
examine communications to have to MITM SSL. I think that the negative PR of
a government or ISP or whatever trying to force installations of additional
root certificates on end users' machines would be a strong disincentive to
employ these policies. I agree it might lead more enterprises to MITM their
employees who use corporate devices. It is a sad world indeed if it's the
status quo for everyone to use devices with extra root certs so
intermediaries can MITM SSL connections.

> purchase, and pay for the ongoing maintenance of a cert, and take the cost
> on additional CPU to handle the load?
>

Yes, I want to use HTTP/2 as a carrot to incentivize server operators to
use HTTPS. There are tradeoffs that prevent folks from adopting HTTPS. I'm
hoping HTTP/2 helps adjust the tradeoffs in HTTPS' favor somewhat, due to
its reduced user perceived latency and improved connection reuse leading to
improved scalability compared to HTTP/1.X over TLS.

>
> Organisations have to live with the pain in the neck of deploying signing
> certs to clients, dealing with visitor devices etc etc.  This = reduction
> in user experience.
>

You mean the additional root certs installed on client machines? Good, I'm
glad it's a PITA for y'all, so maybe you'll stop doing it or do it less
often, and maybe corporations will stop asking you to do this for them.
This is terrible and I'm personally not interested in making it easier for
organizations to snoop on their members/employees/students/etc. I'm in
favor of reduced user experience where the user is someone who wants to
MITM SSL traffic.

> So, IMO making TLS mandatory = reduced security, worse user experience,

I respectfully disagree with your outcome prediction.

> Cc: "William Chan (?????????)" <[email-masked]>; "Tao Effect" <
> [email-masked]>; "Tim Bray" <[email-masked]>; "James M

---

From: Mike Belshe <[email-masked]>
Date: Wed, 13 Nov 2013 16:16:05 -0800

Making TLS mandatory in HTTP will be the best thing to ever happen to TLS
innovation as well.

Mike

On Wed, Nov 13, 2013 at 4:09 PM, William Chan (陈智昌)
<[email-masked]>wrote:

> Just to be clear, the MITM works because the enterprises are adding new
> SSL root certificates to the system cert store, right? I agree that that is
> I believe that making communications secure by default will overall
> improve the security of the web as long as most devices don't have these
> additional SSL root certificates used by the MITM proxies. You are taking a
> cynical view on the outcome when communications become secure by default. I

---

From: Grahame Grieve <[email-masked]>
Date: Thu, 14 Nov 2013 11:25:20 +1100

If corporate security needs is what is driving MITM attacks, then
perhaps HTTP should enable something along the lines of a delegated
security model, though I don't know whether that can be done securely
or not (where secure includes the browser user knowing that it what is
going on)

On the wider question of whether http/2 should mandate TLS, it seems
to me that this is driven by your feelings about http/2 scope. If you
think that http/2 = "the web", then of course http/2 should force TLS.
But if you think that http/2 = a general communications protocol that
is also used by the web, then you won't think that http/2 should
enforce TLS

It seems to me that the use case for "needs efficiency features of
http/2" + "can't deal with the certificate requirements of TLS" is
very slim set. Why not enforce TLS in http/2, and commit to
maintaining HTTP/1 going forward in the unlikely event that something
in the underlying framework was to invalidate HTTP/1?

Grahame

On Thu, Nov 14, 2013 at 11:09 AM, William Chan (陈智昌)
<[email-masked]> wrote:
> We did :) And I don't think we're going to convince one another here. I feel
> like I understand your position and disagree with it. And I think the vice
> versa is true. I stated my preference earlier, but I don't expect to
> Yes, I want to use HTTP/2 as a carrot to incentivize server operators to use
> HTTPS. There are tradeoffs that prevent folks from adopting HTTPS. I'm
>> certs to clients, dealing with visitor devices etc etc.  This = reduction in
>> user experience.
>
>
> often, and maybe corporations will stop asking you to do this for them. This
> is terrible and I'm personally not interested in making it easier for
> organizations to snoop on their members/employees/students/etc. I'm in favor
> of reduced user experience where the user is someone who wants to MITM SSL
> traffic.
>
>>
>>
>> <[email-masked]>; "Tim Bray" <[email-masked]>; "James M Snell"
>> <[email-masked]>; "Mark Nottingham" <[email-masked]>; "HTTP Working Group"
>> <[email-masked]>

-- 
-----
http://www.healthintersections.com.au /
[email-masked] / +61 411 867 065

---

From: Jason Duell <[email-masked]>
Date: Wed, 13 Nov 2013 16:43:50 -0800

On 11/13/2013 03:09 PM, Karl Dubost wrote:
> I'm one of this (indeed rare) person who is having a Web site, do not have analytics, do not have comments, or anything, do not set any cookies of any sort, etc. Plain HTTP works for me.

And plain HTTP/1.1 will continue to work for you, and that's a good, 
fine thing. Your simple site is unlikely to benefit much from the 
latency/multiplexing/etc improvements that HTTP/2 gives. Sites that do 
are more likely to the ones that carry user identity or other info that 
is better to keep secure.  Hence the carrot approach: use TLS if you 
want the fancy bells and whistles from HTTP/2.

The proposal Mark has laid out sounds like a reasonable compromise, and 
I suspect the other networking module peers at Mozilla feel similarly.

Jason Duell
Mozilla

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 14 Nov 2013 02:09:20 +0100

Hi William,

> more HTTPS adoption as much as I can.

Working groups are precisely the places where educated people learn from
others that what they thought they knew was not exactly true and tend to
make better collective choices than isolated ones. And if you, with your
choice *alone* were making a mistake, how many users would that affect ?

I remember talking with Mike in Paris about the use of gzip compression
in SPDY and HTTP/2. I disagreed for performance reasons. Mike preferred
to stay on gzip than other algos such as LZ4 because gzip is standard and
deployed everywhere. Our disagreement was purely based on the technical
quality of gzip for this, none of us thought about any possible security
implication.

Then came that BEAST attack making smart use of compression to guess
clear text by only observing the on-wire compressed & ciphered size.
We discussed this privately afterwards and both of us admitted that
it was *the* good reason for not doing it this way and that both of
us would have failed by picking either algorithm just because of the
nature of the vulnerability that we overlooked in our "battle" for
what algorithm was more suited to the task.

All that to say that it's fine to have ideas, it's fine to have opinions
and to defend them, but in the long term it can serve you and your users
even better if you push less hard and let some of your other team members
share their point of view, fears and doubts, which in the end might result
in strengthening your choice or on the opposite reconsidering it, but at
all times further improving your products.

Sadly your comment above makes me feel like this browser became *yours*
and reflects your sole usage instead of the ones of a group, which can
be counter-productive in the long run. But probably this was just a
wording mistake or just a sign of excess of enthousiasm.

> don't, then someone else will and people will switch from your product?

Sometimes when you're requested to do something you don't agree with for
various reasons, you can at least help do it the least detestable way. Eg:
there are many valid use cases for MITM right now and when you're asked to
design this and you have some consideration for privacy and security, you'll
probably try to educate the customer to only route the connections with
certain SNIs to the MITM proxies and not the rest (just an example).

If at least it's enough to allow a school to give internet lessons to young
kids and force "safe search on" on Google images, it will be a good point.
And if the teacher uses the same PCs to connect to his/her bank account,
you probably don't want the solution you design to be able to MITM that
at all and you'll design it so that this cannot happen by accident.

> terrible. I wouldn't use that computer :) I hope we increase awareness of

And are you certain that you're not already having such CAs in your
phone that allow your mobile phone provider or one of its subsidiaries
to decipher your traffic just because it allows them to cache contents
and score better in page load speed when compared to competitors ?

> SSL root certificates used by the MITM proxies.

But that's the key point. If some companies are paying millions to have
these features, surely they don't do it for fun. What is irresponsible is
to declare their needs do not exist and refuse to talk to them on the sole
basis that they do something you disagree with. I'd rather try to enumerate
all the reasons why they're doing this and see how we can cover most of
them and how we can help them not need the remaining ones (even by pushing
for changing laws sometimes).

> You are taking a cynical
> view on the outcome when communications become secure by default.

No, Amos is realistic because he has seen the people who do this. Have you
ever met these people ? Have you ever worked for a customer in a hosting
company or at an ISP's ? I think not that much, otherwise you would be
less certain about yourself on these points because you'd have seen that
what you claim will not happen is already being done almost everywhere
because of the same reasons several people here have repeated over and over.

> I disagree. I think that it's worthwhile to force entities that want to

In my opinion, as soon as we'll accept that MITM is something that some
companies *need* and which is currently being done the most insecure way,
we'll make a great progress because we'll design a protocol so that it is
possible with the users' knowledge, consent, and choice of sites. Only
after that we can try to think about the remaining cases (eg: dealing with
cert errors for every site that doesn't care).

> improved scalability compared to HTTP/1.X over TLS.

I agree it can significantly help which is why Mark's proposal can make
sense to some extents. But at the same time I know a number of places
where it will not be accepted at all to multiply the number of servers
for cost and maintenance reasons.

> often, and maybe corporations will stop asking you to do this for them.

Do you *really* think that a company changes its behaviour regarding laws
or bandwidth because one guy says "hey, chief, could you please tell your
chief to tell his chief to tell his chief to tell his chief to tell his
chief to tell his chief that it's a PITA to install certs on customer's
machines" ? No. The guy at the top says "we must comply with laws and not
waste bandwidth". The guys below know they need to log. Other ones can
only cache because there's no provision for adding more fibers in the
ocean. Etc... And at the bottom, there is you. The guy who's tasked for
helping them design an MITM cache so that their customers can still have
some internet despite the wires being overly saturated.

> organizations to snoop on their members/employees/students/etc.

We're not speaking about making it easier for them but making it safer
and visible for the end user. *That* is a difference. Maybe some guys
would not have been killed in some countries if they knew they were
snooped when planning their meetings for some riots. Unfortunately, due
to some of the next web designers (us) being stubborn and denying reality,
users still have no way to know if their connection is safe or snooped
these days. That's sad.

> I'm in

That's what several of us already proposed several times ago in the past
and I think it's an acceptable trade-off : "we offer you some free WiFi
access which logs everything but it's not as fast as a transparent one,
unfortunately we have to comply with local laws. Be careful not to access
sensible sites".

Best regards,
Willy

---

From: Patrick McManus <[email-masked]>
Date: Wed, 13 Nov 2013 20:14:06 -0500

> terrible. I wouldn't use that computer :) I hope we increase awareness of
This is a super important point. If someone can install a root cert onto
your computer then you are already owned - there is no end to the other
things they can do too. Call it a virus, call it an enterprise, but call it
a day - you're owned and there is no in-charter policy this working group
can enact to change the security level of that user for good or for bad..

The good news is not everyone is already owned and SSL helps those people
today.

[Wily said]

> on additional CPU to handle the load?

[Will said]

> improved scalability compared to HTTP/1.X over TLS.

On balance, I agree with Will. This is my area of biggest concern though -
I hope and expect to see innovation in the PKI management space to make
things less painful. I had a side conversation in Vancouver about how
something like alternate-services can be used to support routing to full
https based on conditional understanding of SNI and I could imagine that
being a useful thing to help past a rough edge of https:// everywhere. I'm
interested in other practical ideas for easing the transition that people
might suggest.

As for tls-relaxed for http://, I agree with Mark's original
characterization that there are a lot of mixed opinions about it even
inside small organizations. Its not clear how to evaluate how much value it
has (if any) or how much it undermines https:// (if at all). The jury is
still out.

-P

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 14 Nov 2013 09:34:07 +0800

Hi Eliot,

> behaviors we can reasonably expect.

Yes, as much as any such model can be accurate. The second-order and following effects are the hard part.

> course.  Some cross over to layer 9.

Yep, this has come up a few times. Stephen is still working on characterising the outcome of the PERPASS BoF, AIUI, but there was discussion there of profiling / recommending best practice for TLS, and this would fall into that discussion. Don’t know where that’ll happen yet.

> application, and we should allow for that.  But if that's the case, we

Personally, I’m very interested in these approaches, and may be experimenting with them to see where it gets us. Whether that’s an alternate to the current approach or the spiritual successor to shttp:// URIs is anybody’s guess at the moment. Hopefully running code will help illuminate that discussion.

> Rather I am trying to understand the tradeoffs.

Not at all; we all are. The point I want to re-emphasise to everyone is that the intent is to build on that approach, as well as constantly evaluate it. 

Cheers,

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 14 Nov 2013 01:37:27 +0000

On 11/14/2013 01:09 AM, Willy Tarreau wrote:
> least detestable

The second word of that phrase seems to me to be
almost perfectly appropriate for MITM attack product
features. But, importantly, I think your use of
the phrase does expose the reality of what we all
think of doing that, even, I suspect and hope, those
who do it for fun or profit. Thank you.

As to the supposed requirements that lead to those
detestable product features - if enforcing policy on
HTTP traffic is what is claimed to be required then
I would love to see this wg go figure out ways of doing
that using HTTP (rather than *ab*using TLS) so as to
not affect the many many other protocols that depend
on TLS not being as detestable as the implementations
you're talking about. But personally speaking I don't
know how you can do that without screwing up the many
other protocols that depend on https:// and in the
process making those also detestable.

Cheers,
S.

PS: "Supposed" above is I think fair for most of the
"requirements" claimed in this space. There is some
validity to realtime inbound malware scanning but
the rest seems like nonsense. I do wonder why people
who pay for those products don't realise this;-)

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 14 Nov 2013 09:40:37 +0800

Amos,

On 14 Nov 2013, at 8:00 am, Amos Jeffries <[email-masked]> wrote:

> Lets end this enable-TLS-everywhere-and-well-be-fine B***sh*t.

My proposal explicitly said that we had more work to do, and that we’d be coordinating with other parts of the IETF as well as other organisations to improve Web security overall. No one that I see is seriously asserting that we’re anywhere near done.

Using emotive language — whether you star out letters or not — does not help people understand what’s happening here. Please be careful how you characterise other people’s positions. 

Cheers,

—

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 13 Nov 2013 17:42:23 -0800

> choice *alone* were making a mistake, how many users would that affect ?

Just to be clear, I'm not ignoring your comments. I merely stated in
response to the comment that, yes, we've discussed this before, and no,
nothing's really changed. We understand each other's positions and
information as already shared with this working group. And taking that into
consideration, I respectfully disagree with your (intermediary folks)
stance. And you guys are going to MITM traffic even though I think you
shouldn't. I'm just being realistic about the current state of affairs.

> wording mistake or just a sign of excess of enthousiasm.

Hm, it's not clear to me what you mean here. I certainly am not the
Chromium dictator, as much as that would be awesome :P I just affect
project policy to the degree which I have influence, which is generally how
it works in an organization. And I've stated for you what policy I try to
effect is. Anyhow, if you don't mind, I'd rather not make this discussion
about me. I spend far too much time talking about myself.

> at all and you'll design it so that this cannot happen by accident.

I disagree with the use of MITM to achieve these ends. I think we don't
need to break end to end security to achieve these goals. As an example,
here's a Chrome feature to provide parental controls rather than implement
them in a MITM proxy: http://www.bbc.co.uk/news/technology-24635752.

> SSL

I'm reasonable confident because I use an Android Nexus phone receiving OTA
from Google. If Google's installing additional certs, I will likely throw a
fit and call them out on it.

> improve

The key point, as Pat noted, is that the majority of users don't have these
extra root certs. I never said these organizations' needs do not exist. I
just disagree with their using MITM as the mechanism to achieve their goals.

> signing

No, I believe I said I recognized the likelihood that enterprise adoption
of MITM proxies would increase.

> users still have no way to know if their connection is safe or snooped

We've been thinking about this stuff. Security UI is hard =/

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 14 Nov 2013 09:52:47 +0800

Hi Mike,

On 14 Nov 2013, at 4:41 am, Mike Belshe <[email-masked]> wrote:

> Because honestly, unless you're one of those people, there is no good reason not to be 100% encrypted now.
> 
> And I'm tired of hearing the "backoffice" argument - recent developments prove that even the backoffice needs to be 100% encrypted.  Ok - sorry, I'm ranting now...:-)
> 
> </off topic>

This isn’t helping the discussion, and surrounding it in <off topic> doesn’t mean you get to say whatever you want to say*. Everyone, please refrain from talking / speculation about people’s motivations.

Regards,

* Off topic: http://www.youtube.com/watch?v=Af-Id_fuXFA

> On Wed, Nov 13, 2013 at 12:01 PM, William Chan (陈智昌) <[email-masked]> wrote:
> Well, it should be no surprise that the Chromium project is still planning on supporting HTTP/2 only over a secure channel (aka TLS unless something better comes along...). So, that's (C).
> 
> As to opportunistic encryption, we have mixed opinions on the team on that. Mike, Tim, can you explain why you like (A)? Here are some concerns I've heard on it:
> * The marginal security benefit of unauthenticated encryption is fairly marginal. Which adversary is this intended to defeat? It might defeat something like Firesheep for now, until tools like that get updated to MITM as well. Does it shift the economics very much on passive pervasive monitoring? What wins do y'all foresee here?
> 
> That's exactly right.  The argument that we shouldn't do it because it only works "until tools get updated to MITM" doesn't work for me, because that's just  the way security is.  You never finish "security", you just keep raising the bar. 
> 
> Given the widespread snooping that has been so widely publicized in recent months, I think it is imperative that we raise the bar here now.
> 
>  
> * As for downsides, will people read too much into the marginal security benefit and thus think that it's OK not to switch to HTTPS? If so, that would be terrible. It's hard to assess how large this risk is though. Do you guys have thoughts here?
> 
> I hadn't even considered this - its so odd!  I can't see anyone not using TLS because of this - if you don't know when you need TLS, then you probably won't notice that we're encrypting your HTTP.  So I see it as something that just protects users automagically without them even knowing.   I don't believe this as a serious concern.
> 
> Mike
> 
> 
> 
> 
>  
> 
>

---

From: Frédéric Kayser <[email-masked]>
Date: Thu, 14 Nov 2013 02:56:45 +0100

May I ask if encryption is a free operation? or (as I suspect) does it impact CPU usage and therefore power consumption on both (servers and clients) sides, possibly increasing server rooms electricity bills, reducing smartphones autonomy and make F5 Networks stocks surge. I let you guess if my preoccupation is self-seeking or rather environmental… 
I thought that HTTP/2 would progressively entirely replace HTTP/1.1 but making HTTPS mandatory is probably the best way to keep it around indefinitely.

Tim Bray wrote:

> Shifting the economics on pervasive surveillance seems like the big deal to me. It becomes much less attractive for three-letter agencies to just collect everything and data-mine it.  MITM-ing on a large scale doesn’t sound very practical.
>  
> I agree that’s a risk, but we’re all kind of talking out of our asses here because we don’t have any data.  My intuition is that people who actually understand the issues will understand the shortcomings of opportunistic and not use it where inappropriate, and people who don’t get why they should encrypt at all will get some encryption happening anyhow.  But intuition is a lousy substitute for data.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 14 Nov 2013 10:04:03 +0800

On 13 Nov 2013, at 8:07 pm, Mark Nottingham <[email-masked]> wrote:

> People who want to use HTTP/2 for http:// URIs will need to redirect them to https:// (and possibly use HSTS, depending upon their use case).

Just to clarify here — this is in the context of the “open” Web for the browsing use case.

Cheers,

---

From: Tao Effect <[email-masked]>
Date: Wed, 13 Nov 2013 21:10:12 -0500

On Nov 13, 2013, at 8:56 PM, Frédéric Kayser <[email-masked]> wrote:

> May I ask if encryption is a free operation? or (as I suspect) does it impact CPU usage and therefore power consumption on both (servers and clients) sides, possibly increasing server rooms electricity bills, reducing smartphones autonomy and make F5 Networks stocks surge.

IMO, of the various concerns raised so far, this is one of the more lower-priority ones, because:

1. Encryption is a "free operation" (to an extent) if the hardware supports it.
2. People's lives are more important than an electricity bill (I know, however, that many disagree on this one).

That's not to say that I think the this proposal is a brilliant one.

I do support encrypting HTTP (even mandating it), but it must be done correctly, not in some half-assed way that just unnecessarily complicates everyone's life and doesn't actually improve today's security.

- Greg

> 
>  I let you guess if my preoccupation is self-seeking or rather environmental…

---

From: Roberto Peon <[email-masked]>
Date: Wed, 13 Nov 2013 18:10:51 -0800

The radio far dominates battery life considerations w.r.t IO on mobile
devices, so if we were super worried about that, we'd be working on getting
the best possible compression algorithm for entity-bodies.

I note that with Mark's proposed 'C':
Encryption is not mandatory- one simply uses HTTP/1.1 if one don't want
encryption. Noone is thus forced to do anything: they're not forced to
spend more CPU, etc., unless they believe the benefit outweighs the cost.

Honestly, this is where we are anyway. We don't have the power, even if we
wished it, to throw away HTTP/1.X and so we'll always be competing against
its cost/benefit.

I'm pretty happy with either 'C' or any other proposal that provides strong
downgrade protection.

-=R

On Wed, Nov 13, 2013 at 5:56 PM, Frédéric Kayser <[email-masked]> wrote:

> May I ask if encryption is a free operation? or (as I suspect) does it
> impact CPU usage and therefore power consumption on both (servers and
> clients) sides, possibly increasing server rooms electricity bills,
> reducing smartphones autonomy and make F5 Networks stocks surge. I let you
> guess if my preoccupation is self-seeking or rather environmental…
> I thought that HTTP/2 would progressively entirely replace HTTP/1.1 but
> making HTTPS mandatory is probably the best way to keep it around
> indefinitely.
>
>
> Tim Bray wrote:
>
> Shifting the economics on pervasive surveillance seems like the big deal
> to me. It becomes much less attractive for three-letter agencies to just

---

From: Tao Effect <[email-masked]>
Date: Wed, 13 Nov 2013 21:58:06 -0500

Sorry list,

I'd like to apologize for my word choice in that previous email, it was completely uncalled for, and I regretted it almost immediately after sending it. Alas, this is where gmail's undo feature would have saved me, but I do not trust gmail. :-p

Mark contacted me off list and wisely pointed out that disparaging an idea without giving explanation for it is also unhelpful, and I agree 100% with that, and again, apologize to Mark and the whole list for my mistake.

I have been reading through the RFC throughout the day, and will point more constructive comments to the list later, and hopefully, in a much more tasteful manner.

Sincerely,
Greg Slepak

---

From: Frédéric Kayser <[email-masked]>
Date: Thu, 14 Nov 2013 04:01:12 +0100

This also means HTTP/2 is not for everyone, it's only for big business, and you cannot get the speed benefit without some hardware investments.
It also means that speed consciousness webdesigners will still have to continue using the awful CSS sprites trick when their target server is still HTTP/1.1 based.
HTTP/2 sounded like a magical speed promise… that would be quickly adopted, but now it just looks like an alternative solely made for the big guys.

Roberto Peon wrote:

> The radio far dominates battery life considerations w.r.t IO on mobile devices, so if we were super worried about that, we'd be working on getting the best possible compression algorithm for entity-bodies.
> 
> Encryption is not mandatory- one simply uses HTTP/1.1 if one don't want encryption. Noone is thus forced to do anything: they're not forced to spend more CPU, etc., unless they believe the benefit outweighs the cost.
> 
> Honestly, this is where we are anyway. We don't have the power, even if we wished it, to throw away HTTP/1.X and so we'll always be competing against its cost/benefit.
> 
> I'm pretty happy with either 'C' or any other proposal that provides strong downgrade protection.
> 
> -=R

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 14 Nov 2013 11:04:00 +0800

Thanks, and don’t beat yourself too badly — we’re all guilty of this in some way. The current conversation is… challenging, in that we all have strong feelings about it. 

Great to have you contributing.

Cheers,

---

From: Roberto Peon <[email-masked]>
Date: Wed, 13 Nov 2013 19:24:32 -0800

As far as I've seen, most small businesses get little enough traffic that
they wouldn't notice any difference w.r.t CPU usage.
.. and if it bothers them, they'd use HTTP/1.1 for web stuff, or are
already doing so.

In any case, it is extremely likely that HTTP/2.0 on port 80 is nearly
undeployable for the web today. There are too many MITM proxies out there
that expect port 80 to carry only a subset of HTTP/1.1, and make a mess of
anything else.

So, any web deployment of HTTP/2 that is going to be reliable WILL use
encryption, and WILL incur the cost of encryption.

.. as such, the only real question here is simply about authentication.

I do expect that we'll see HTTP/2.0 in the clear, but that would be inside
of a VPN or other private network, and Mark's original email was talking
about the web usecase.

-=R

On Wed, Nov 13, 2013 at 7:01 PM, Frédéric Kayser <[email-masked]> wrote:

> This also means HTTP/2 is not for everyone, it's only for big business,
> and you cannot get the speed benefit without some hardware investments.
> It also means that speed consciousness webdesigners will still have to
> continue using the awful CSS sprites trick when their target server is
> still HTTP/1.1 based.
> HTTP/2 sounded like a magical speed promise… that would be quickly
> adopted, but now it just looks like an alternative solely made for the big
> guys.
>
> Roberto Peon wrote:
>
> > Honestly, this is where we are anyway. We don't have the power, even if
> we wished it, to throw away HTTP/1.X and so we'll always be competing
> against its cost/benefit.
> >

---

From: Tao Effect <[email-masked]>
Date: Thu, 14 Nov 2013 00:27:03 -0500

On Nov 13, 2013, at 10:04 PM, Mark Nottingham <[email-masked]> wrote
> Great to have you contributing.

Thanks Mark, and thanks for the off-list email, I thought it was brilliant. As time permitted, I pursued some of the links you sent, and I especially liked the "Tao of the IETF". ^_^

Again, apologies for criticizing the proposal without providing any explanation. I finished reading the RFC and have written down my observations and objections below:

1. $$$

Who's going to pay for these certs that nobody actually needs (because of authentication methods that don't need CAs), and why is this unnecessary and annoying financial burden being placed on anyone who wants to run a world-facing HTTP/2.0 server?

2. $$$ + The Terrorist Lurking Just Behind the Corner™

What happens if a monopoly appears (imagine your worst nightmare, a monopoly of monopolies: Symantec+Verizon+ATT+AOL Time Warner), and all of a sudden starts to either:

1. Gobble up the browser vendors and/or put them on their payroll; or,
2. Lobby their way through the legislative bodies of the world to force us to use their certs Because Terrorism™ ?

Yeah, that's a bit of a loony scenario, but it's actually possible thanks to the silly idea of Certificate Authorities.

3. Annoying Small Businesses

Is it possible that a danger exists whereby some people (certain nuisance-type small business) might end up kicked off the net because HTTP 1.0 has "successfully" been migrated over to HTTP/2.0 and the Internet Identity Verification Bureaucracy (slogan: "May I see your papers plz?!?") cannot seem to find the application they sent in last month?

Yet another loony-toons scenario brought to you by: Certificate Authorities.

(I know, I know, "Not our problem, leave it to the TLS guys to fix later". I address this below.)

4. Cultivating Apathy and Enabling Fascists

Will adopting a protocol (TLS) that is known to provide inadequate security put a roadblock on the path to implementing real security in web browsers?

I'm rather concerned that, having successfully upgraded their browsers to the brand-spanking shiny new HTTP/2.0 goodness, people will have little enthusiasm for dismantling the basis of the authentication system that TLS uses (Certificate Authorities).

Instead, it might go something like this:

"Yeah! Go us! We made the web encrypted! We're... Encryption Heroes!!"

Objections raised by the nerds in tinfoil hats will be brushed aside with the words such as, "adequate". After all, why bother addressing these technicalities when we all see so many users smiling at all the shining lock icons all over the net?

Symantec/VeriSign's executives will also be smiling, even wider smiles, because they get to literally print money as if they were suddenly the Federal Reserve. "Oh, you want a key? Here you go, that'll be $20, come back same time next year to renew your security subscription!"

This is essentially fraud. They are selling a "product" that takes approximately zero effort to create, and they get to charge annual fees for it while promising security that does not actually exist. Meanwhile, the cold creep of the surveillance state settles down upon the quiet town...

5. Conclusion and RFC #>9000

The intent expressed on this list by Mark and the browser vendors seems quite noble, but anytime the security issue is brought up, all I've seen is it being pushed aside to "another working group".

OK, that's perfectly fine, but let them do their work, and leave the security decisions to them.

There exist many proposals for how to fix this situation. The ones that I think will work all involve getting rid of the CAs. That, properly implemented, would do the trick.

But I haven't heard from any browser vendor, or any IETF Greybeard, that putting the CAs on the chopping block is part of the plan.

That does not mean I'm against businesses being able to monitor company traffic (with consent and knowledge of their employees, etc.). Said alternative proposals can be (and some are) able to do such administrivia. We don't need CA to do that, however.

Therefore, I propose a fourth alternative (to the three existing ones).

Option D: Do nothing.

This is not a problem for this WG to solve. Don't give TLS any novel treatment until it is fixed. Leave the security details to Security Details, and when it's fixed, work together with them on how to use it with HTTP/2.0.

Lao Tze would approve.

The pros of this approach:

1. The problem remains like a painful thorn in everyone's backside, gnawing at our collective subconscious.

That's exactly as it should be. "Fake fixes" aren't fixes.

The cons of this approach:

1. The problem remains like a painful thorn in everyone's backside, gnawing at our collective subconscious.

That's exactly as it should be. "Fake fixes" aren't fixes.

Thanks for considering.

- Greg

---

From: cowwoc <[email-masked]>
Date: Thu, 14 Nov 2013 00:32:10 -0500

I second Karl's point. I think you'd get a lot more people on board if 
you simplified the processes surrounding SSL, from configuration to 
dealing with CAs. Running a CA is both an expensive and complex 
operation. As a result, dealing with them is equally painful and expensive.

If you could improve these fronts, you'd have my vote.

Gili

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 14 Nov 2013 13:41:34 +0800

Hi Greg,

A few quick responses from my standpoint inline; I imagine others will step up with more details.

> Who's going to pay for these certs that nobody actually needs (because of authentication methods that don't need CAs), and why is this unnecessary and annoying financial burden being placed on anyo…

As many have pointed out, certs are free from some vendors today. Many expect this situation to get better, not worse, over time.

That’s not to say we’re tied to the current model of public key infrastructure; many have been proposing improvements to it, or completely replacements for it. Although that’s not within our charter, we can consider referencing such work as part of HTTP.

> Yeah, that's a bit of a loony scenario, but it's actually possible thanks to the silly idea of Certificate Authorities.

How does that make *less* use of encryption a better outcome? 

> (I know, I know, "Not our problem, leave it to the TLS guys to fix later". I address this below.)

That seems like a straw man. No one is proposing that HTTP/1.1 will stop working or being implemented, and no implementer has an incentive to stop support it; doing so would be suicide in a very competitive market.

> This is essentially fraud. They are selling a "product" that takes approximately zero effort to create, and they get to charge annual fees for it while promising security that does not actually exist. Meanwhile, the cold creep of the surveillance state settles down upon the quiet town…

This problem has a lot of visibility. Again, I don’t see how less use of encryption helps solve it.

> That does not mean I'm against businesses being able to monitor company traffic (with consent and knowledge of their employees, etc.). Said alternative proposals can be (and some are) able to do su…

Please realise this is part of a MUCH larger discussion; Stephen should be posting the next steps for the perpass BoF soon, and there are still discussions about what to do echoing around the IETF and other places. I haven’t heard anyone say that this is the LAST step in improving security; just a strong sense that we needed to start.

> This is not a problem for this WG to solve. Don't give TLS any novel treatment until it is fixed. Leave the security details to Security Details, and when it's fixed, work together with them on how…

There was VERY strong consensus that this is not acceptable in Vancouver. What do others think?

Cheers,

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 14 Nov 2013 07:45:15 +0100

> who do it for fun or profit. Thank you.

I don't think anyone really disagrees with this. Amos and Adrien said 
they had to implement this because there is strong demand, not that
they loved the concept. Nobody sane (technically speaking) loves the
concept of trying to fool the user who believes there is some security
when the tools are not designed to inform him about what's happening.

> process making those also detestable.

I think it's neither TLS nor HTTP's role to do to provide the
solution to this, but at least it's certainly not HTTP's role
to make efforts to ensure that this results in the worst
situation for the end user when that's done anyway! In my opinion
it's mostly a matter of user interface as long as the protocol
does not needlessly complicate things.

> who pay for those products don't realise this;-)

I would turn the question the other way around : you should wonder why
you believe the rest is nonsense if people are paying a lot for this.
You just don't have the same motivations as them, but for some, it's
just being able to do so or run out of business. And just a reminder,
we started this discussion about the fact that the ones who just MITM
clear HTTP for caching will have a good reason for doing it with HTTPS
if we enforce encryption where not needed. So you add the economics as
a new motivation to do this. For most ISPs, the bandwidth costs are much
higher than anything else, and margins are extremely low. So if the
bandwidth requirements increase, they risk their business. Caching
then becomes mandatory for some. With or without TLS, it's just an
implementation detail when you're talking to someone who doesn't know
if his company will survive past the end of the year.

Willy

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 14 Nov 2013 16:07:07 +0900

If I Rob this correctly, this may mean that a future version of IE will 
implement HTTP 2.0 without encryption for http: URIs.

Next let's say that Apache 3.0 implements HTTP 2.0 which can be 
configured to run without encryption (after all, Apache is used in 
internal contexts, too).

What's the chance of this *not* leaking out into the open internet and 
forcing other browser vendors to also allow HTTP 2.0 for http: URIs 
without encryption? After all, experience has shown that users quickly 
abandon a browser that doesn't work for some websites, and that browser 
vendors know about this and try to avoid it.

Just some thoughts.

Regards,    Martin.

[Not a hacker,..., but just a maintainer of some small web sites with 
not enough time to set up certificates and TLS (similar to Karl).]

On 2013/11/14 3:36, Rob Trace wrote:
> On Nov 13, 2013, at 1:14 PM, Mike Belshe<[email-masked]<mailto:[email-masked]>>  wrote:
>
>
> On Wed, Nov 13, 2013 at 9:46 AM, Tao Effect<[email-masked]<mailto:[email-masked]>>  wrote:
> On Nov 13, 2013, at 12:31 PM, Tim Bray<[email-masked]<mailto:[email-masked]>>  wrote:
> On Nov 13, 2013, at 12:31 PM, Tim Bray<[email-masked]<mailto:[email-masked]>>  wrote:
>
>
> On Wed, Nov 13, 2013 at 9:22 AM, James M Snell<[email-masked]<mailto:[email-masked]>>  wrote:
> On Wed, Nov 13, 2013 at 2:01 AM, Mark Nottingham<[email-masked]<mailto:[email-masked]>>  wrote:
> [snip]
>>

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 14 Nov 2013 08:15:10 +0100

Hi Roberto!

> they wouldn't notice any difference w.r.t CPU usage.

I agree on this point, but it cuts the world in two parts who see an
increased cost in different areas :
  - those who won't notice the difference in CPU usage but will clearly
    see a difference in complexity due to the new requirement of managing
    their certs ;

  - those who are large enough to correctly manage certs and who will
    definitely see a difference in CPU usage. Just an example, haproxy
    happily runs at 40 Gbps when transfering video streams on commodity
    hardware and I've seen people use it in prod with sustained 20 Gbps
    traffic. The same hardware cannot do more than 5 Gbps in AES-GCM
    which is the fastest cipher we found. They'll have to significantly
    multiply the number of machines for the same task then !

> .. and if it bothers them, they'd use HTTP/1.1 for web stuff, or are

I'm not much worried about that in fact. "Legacy" web servers will continue
to exist for years and decades. I'm more concerned about the requirement of
TLS for HTTP/2 as a protocol instead of as an implementation, that some tend
to promote. HTTP/1 works on any stream, including unix sockets between
processes. If we limit HTTP/2 to just the outside, we lose the benefits of
its improvements end-to-end (eg: server push etc). Also HTTP is not solely
used by browsers but by many other products and we want to ensure that they
will still be able to benefit from this. Last point concerning browsers, for
having worked with application development teams, I know that the most painful
thing these persons face is to test their code. They'll definitely need a way
to unlock their browser to use HTTP/2 to the local server otherwise none of
the cool new features will really be adopted by complexity of testing.

> that expect port 80 to carry only a subset of HTTP/1.1, and make a mess of

Which is one reason for playing with the "default" setting : default to 1.1
for HTTP and 2.0 for TLS makes sense to me. And acting like this saves us
from trying to optimise the Upgrade handshake. So we have it for legacy
usages (development, testing, non-browser uses, etc...) and we know that
from the protocol point of view, it's sane even if not optimal. And we can
use ALPN for TLS.

However we must absolutely improve proxy support so that there is incentive
for using explicit proxies with HTTP/2. This is critically important in mobile
environment where most of the time is spent between the browser and the ISP.
Having a TLS-only proxy definitely is a good thing and makes a lot of things
easier and safer.

> encryption, and WILL incur the cost of encryption.

And pink pixel providers will remain on 1.1 for a very long time, while
they're very sensitive to site response time. Maybe the attempts to provide
2.0 in clear will come from them.

> of a VPN or other private network, and Mark's original email was talking

Absolutely.

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 14 Nov 2013 08:21:46 +0100

> vendors know about this and try to avoid it.

And so what ? It's not a problem. Some browsers will likely implement
it at least with a config option that's disabled by default, and these
browsers will be the ones picked by developers during their tests,
because developers pick the browser that makes their life easier.

Willy

---

From: Mike Belshe <[email-masked]>
Date: Thu, 14 Nov 2013 00:04:04 -0800

I agree, TLS is too hard to use today.  We need more tools and simpler
processes.

The reason it hasn't been simplified is not because security inhibits
simplicity.  It's because we're able to quickly opt out of any security
whatsoever and lazily go about our ways...

So for those of you that would like more encryption & authentication
generally, but are resisting TLS for fear of additional work - fear not!
 The best way to make TLS easier is to use is to make it mandatory.

Mike

---

From: Roberto Peon <[email-masked]>
Date: Thu, 14 Nov 2013 00:24:30 -0800

Ignoring improving aggregate security for a second (it would be beyond
foolish to do so longer than this paragraph), everyone seems to be
forgetting how poorly non http/1.1 actually works out there on the wild
wild internet.

10-20% failure rates are simply unacceptable for both site operators and
client writers.

-=R
 On Nov 13, 2013 9:09 PM, Martin J. Dürst <[email-masked]> wrote:

> Next let's say that Apache 3.0 implements HTTP 2.0 which can be configured
> to run without encryption (after all, Apache is used in internal contexts,
> too).
>
> forcing other browser vendors to also allow HTTP 2.0 for http: URIs without
> encryption? After all, experience has shown that users quickly abandon a
> browser that doesn't work for some websites, and that browser vendors know
> about this and try to avoid it.
>
> Just some thoughts.
>
> Regards,    Martin.
>
> [Not a hacker,..., but just a maintainer of some small web sites with not
> enough time to set up certificates and TLS (similar to Karl).]
>
>> We are one browser vendor who is in support of HTTP 2.0 for HTTP://URIs.  The same is true for our web server.  I also believe that we should
>> strongly encourage the use of TLS with HTTP, but not at the expense of
>> creating a standard that is as broadly applicable as HTTP 1.1.
>>
>>
>>
>> FWIW, here's one voice in support of HTTP/2==TLS.  And another saying
>> let's not give up on opportunistic encryption.
>>
>>
>>
>>
>>
>>

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 14 Nov 2013 09:30:27 +0100

>  The best way to make TLS easier is to use is to make it mandatory.

Better start by removing the option for browsers to bypass TLS errors.
That way sites using TLS will need to take care of doing it correctly.
It's unacceptable that some public sites use a single "www.foo.com" cert
for all the subdomains knowing that users won't bother much. I regularly
see a few of them, I just don't have the last one in mind right now, but
I could easily provide examples.

And I've been one of the bad players here for a test : https://demo.1wt.eu/
presents a certificate for this name just for testing purposes, and the
same cert is presented all over the 1wt.eu domain. Not a big deal, there
is nothing important there and it still allows me/some users to test TLS
support there, nothing more. If browsers could not have even opened the
1wt.eu site, I would have configured the proxy to only support the demo
site for the cert and not the other one. The reason for a single cert is
that having a wildcard was not free. Another point, I could not request
a free cert for "1wt.eu" itself, and wildcards do not allow the main
domain and subdomains at the same time.

The wise visitor will notice that the cert has expired. I was notified
by StartSSL that the cert had to be renewed, which I did, but it was
rejected on the basis that the digit "1" looks like the letter "l" and
could be fooled. Cool. So I can't have a cert anymore for this domain
I've used for 10 years or so. All that not being important, I quickly
ended my attempts to replace this cert.

Also just to give a few numbers :

   - since 1/1/2013, I got 4192 HTTPS requests on this proxy.

   - 1254 of them were for demo.1wt.eu (the registered cert name)

   - 2938 were for the other domains that emit a cert error saying the
     cert doesn't match the web site, which means that users accepted
     to click through the browser's warning. 2 thirds of the requests
     should never have passed through!

   - 1511 requests were made *after* the cert had expired, meaning that
     users don't even care about this error either and still click on
     "I understand the risks".

The problem is exactly here. There is only security when users don't
explicitly and intentionally bypass the controls we implement for them.

I would like to have the time and skills to set up an open wifi access
that would do some MITM TLS and just log requests, in order to provide
statistics. I'm quite sure we'd see numbers similar to those above.

So first let's prevent users from bypassing this control, wait for things
to stabilize and get the user (and web site owner) feedback about what is
needed to enable TLS again on their site. Doing it the other way around
makes us certain that the statistics presented above from *real traffic*
can only get worse.

Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 14 Nov 2013 08:39:23 +0000

In message <[email-masked]>

>I agree, TLS is too hard to use today.  We need more tools and simpler

And this is one of (many) reasons why I think HTTP/2.0 should be
defined as a protocol to run on a transparent byte-pipe.

That would give us a neatly layered situation, where the mapping
from "http:", "https:", "httpng:", and even "httpNSAsucks:" to
how the byte-pipe is constructed is decoupled from what we move
through the byte-pipe once it is constructed.

-- 
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: "Adrien de Croy" <[email-masked]>
Date: Thu, 14 Nov 2013 09:34:42 +0000

------ Original Message ------
From: "William Chan (陈智昌)" <[email-masked]>
>offering MITM features in your products. I suppose that if I ask you 
>not to MITM traffic, you wouldn't listen, would you? :P If you feel 
>that MITM is bad for the web, why are you implementing this? Is it 
>simply because if you don't, then someone else will and people will 
>switch from your product?
we only write the proxy software and provide the feature.  The customer 
decides whether to turn it on or not.
The customers have been asking for this feature for years. We held off, 
but had to concede when Google and FB went to https, as the rate of 
requests went up.  Much of the competition had been offering it for 
several years.

So do you really think the vendor company that steadfastly refuses to 
offer it will be the one left standing?  There are already plenty of 
vendors offering this feature.  It's a competitive necessity.

>
>>
>>Does this improve security of the web overall?  IMO no.  People can 
>>now snaffle banking passwords with a filter plugin.
>
>SSL root certificates to the system cert store, right? I agree that 
>that is terrible. I wouldn't use that computer :) I hope we increase 
>awareness of this issue.
correct.  You can tell if you're being intercepted if the root cert 
doesn't look like who it should be.

>improve the security of the web as long as most devices don't have 
>these additional SSL root certificates used by the MITM proxies. You 
>are taking a cynical view on the outcome when communications become 
>secure by default. I disagree.
I'm not talking about a hypothetical future.  We're seeing it now.  More 
and more MITMs are being deployed.  That's not a cynical or pessimistic 
view, it's simply accepting reality.

>I think that it's worthwhile to force entities that want to examine 
>communications to have to MITM SSL. I think that the negative PR of a 
>government or ISP or whatever trying to force installations of 
>additional root certificates on end users' machines would be a strong 
>disincentive to employ these policies. I agree it might lead more 
>enterprises to MITM their employees who use corporate devices. It is a 
>sad world indeed if it's the status quo for everyone to use devices 
>with extra root certs so intermediaries can MITM SSL connections.
Many people operating these things don't get a choice.

Try telling a company boss that they shouldn't care if their employees 
cyber-slack all day because you can't tell what they are surfing.  Tell 
them they shouldn't care if their employees download malware and infect 
their networks because they can't scan it for viruses.

>Yes, I want to use HTTP/2 as a carrot to incentivize server operators 
>to use HTTPS. There are tradeoffs that prevent folks from adopting 
>HTTPS. I'm hoping HTTP/2 helps adjust the tradeoffs in HTTPS' favor 
>somewhat, due to its reduced user perceived latency and improved 
>connection reuse leading to improved scalability compared to HTTP/1.X 
>over TLS.
>
>>
>>signing certs to clients, dealing with visitor devices etc etc.  This 
>>= reduction in user experience.
>
>You mean the additional root certs installed on client machines? Good, 
>I'm glad it's a PITA for y'all, so maybe you'll stop doing it or do it 
>less often, and maybe corporations will stop asking you to do this for 
>them.
And maybe not.  You really think corporates are going to stop caring 
about these things?  They are caring more and more, not less and less.

If everyone had a realistic choice, they could choose to stop MITM, but 
malware using https put paid to that.  The argument has already been put 
about the necessity of caching, that you'd presumably also be happy to 
throw under the bus.

>This is terrible and I'm personally not interested in making it easier 
>for organizations to snoop on their members/employees/students/etc.
make sure you're not making incorrect assumptions about this so-called 
"snooping".  Is it really snooping if the only thing that sees the data 
is an AV agent?

>I'm in favor of reduced user experience where the user is someone who 
>wants to MITM SSL traffic.
I'm also in favour of it being visible to the user whether they are 
being intercepted MITMed.

Regards

Adrien

>
>>
>>So, IMO making TLS mandatory = reduced security, worse user 
>>experience, and increased costs.
>>
>>That's progress I guess.
>

---

From: Roland Zink <[email-masked]>
Date: Thu, 14 Nov 2013 10:55:24 +0100

> through the byte-pipe once it is constructed.
+1

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Thu, 14 Nov 2013 11:20:53 +0100

> details of the proxy inter-operability issue. And so it should wait until

I concur, specifiying proxies after protocol decisions have already been
set does not have a positive history. And proxies are not just solved by
peer-to-peer caching. The perimeter security issue has not been solved at
all right now.

-- 
Nicolas Mailhot

---

From: Roland Zink <[email-masked]>
Date: Thu, 14 Nov 2013 11:24:08 +0100

What will be the goal of mandating TLS?
  1) Is it end to end security?
  2) Is it just securing the connection to the next hop?

If it is 1) how can proxy based services like virus scanning and caching 
be done?
If it is 2) how is end to end security achieved?

Regards,
Roland

On 14.11.2013 10:34, Adrien de Croy wrote:
> From: "William Chan (陈智昌)" <[email-masked] 
> <mailto:[email-masked]>>
>> On Wed, Nov 13, 2013 at 2:36 PM, Adrien de Croy <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>
>>     We added MITM in WinGate mostly because Google and FB went to
>>     https.  Google and FB you may take a bow.
>>
>>
>> FWIW, I'm happy those companies went HTTPS, and I'm sad that y'all 
>> are offering MITM features in your products. I suppose that if I ask 
>> you not to MITM traffic, you wouldn't listen, would you? :P If you 
>> feel that MITM is bad for the web, why are you implementing this? Is 
>> it simply because if you don't, then someone else will and people 
>> will switch from your product?
> The customers have been asking for this feature for years. We held 
> off, but had to concede when Google and FB went to https, as the rate 
> of requests went up.  Much of the competition had been offering it for 
> several years.
> So do you really think the vendor company that steadfastly refuses 
> to offer it will be the one left standing?  There are already plenty 
> of vendors offering this feature.  It's a competitive necessity.
>>
>>
>>     Does this improve security of the web overall?  IMO no.  People
>>     can now snaffle banking passwords with a filter plugin.
>>
>>
>> Just to be clear, the MITM works because the enterprises are adding 
>> new SSL root certificates to the system cert store, right? I agree 
>> that that is terrible. I wouldn't use that computer :) I hope we 
>> increase awareness of this issue.
> I'm not talking about a hypothetical future.  We're seeing it now.  
> More and more MITMs are being deployed.  That's not a cynical or 
> pessimistic view, it's simply accepting reality.
>> enterprises to MITM their employees who use corporate devices. It is 
>> a sad world indeed if it's the status quo for everyone to use devices 
> cyber-slack all day because you can't tell what they are surfing.  
> Tell them they shouldn't care if their employees download malware and 
> infect their networks because they can't scan it for viruses.
>>
>>
>>     You're suggesting anyone wanting to run an http2 server now has
>>     to purchase, and pay for the ongoing maintenance of a cert, and
>>     take the cost on additional CPU to handle the load?
>>
>>
>>     signing certs to clients, dealing with visitor devices etc etc.
>>      This = reduction in user experience.
>>
>>
>> You mean the additional root certs installed on client machines? 
>> Good, I'm glad it's a PITA for y'all, so maybe you'll stop doing it 
>> or do it less often, and maybe corporations will stop asking you to 
>> do this for them.
> If everyone had a realistic choice, they could choose to stop MITM, 
> but malware using https put paid to that.  The argument has already 
> been put about the necessity of caching, that you'd presumably also be 
> happy to throw under the bus.
>> This is terrible and I'm personally not interested in making it 
>> easier for organizations to snoop on their 
>> members/employees/students/etc.
> "snooping".  Is it really snooping if the only thing that sees the 
> data is an AV agent?
>>     From: "Stephen Farrell" <[email-masked]
>>     <mailto:[email-masked]>>
>>     To: "Willy Tarreau" <[email-masked] <mailto:[email-masked]>>; "Mike Belshe"
>>     <[email-masked] <mailto:[email-masked]>>
>>     Cc: "William Chan (?????????)" <[email-masked]
>>     <mailto:[email-masked]>>; "Tao Effect"
>>     <[email-masked] <mailto:[email-masked]>>; "Tim
>>     Bray" <[email-masked] <mailto:[email-masked]>>;
>>     "James M Snell" <[email-masked] <mailto:[email-masked]>>;
>>     "Mark Nottingham" <[email-masked] <mailto:[email-masked]>>; "HTTP
>>     Working Group" <[email-masked] <mailto:[email-masked]>>

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Thu, 14 Nov 2013 11:48:21 +0100

Le Mer 13 novembre 2013 22:54, Willy Tarreau a écrit :
>  When certs are
> its IP address.

Printers are a big equipment. People are already connecting lightbulbs for
christsakes (did not one here hear about the Internet of things stuff? I
can tell you it is happening, I see the first parts in my proxy traffic).
There is no way in hell the current PKI/CA system can scale to this number
of devices no one really wants to secure anyway without making
certificates effectively meaningless (and my bank would disagree with
this)

And make a protocol revision supposed to be future-proof for at least a
decade depend on this system when it is already broken ? Madness

TLS is not advocated for security or freedom values it is advocated by big
websites operators like Google who resent anyone interfering with the
control they have of their visitors now. It's giving big brother a bigger
stick because who the hell can even pretend Google-enduser relationship is
remotely balanced. (replace Google with any of the other Internet giants,
none of those is free from the temptation to abuse a direct
in-controllable link to end-users, and Snowden showed).

This is quite transparent in the latest exchanges "small fishes will
continue to use http/1, we want tls+http/2 for out giant monitoring
platforms, and btw revisiting cookies? Forget about it"

-- 
Nicolas Mailhot

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 14 Nov 2013 19:49:17 +0900

Hello Willy,

> because developers pick the browser that makes their life easier.

Sorry I wasn't clear enough. What I meant was: Does it make sense, as 
Mark proposed at the start of this thread, to rely on browsers to not 
implement HTTP 2.0 over the clear, if one of the major browser makers is 
already saying they won't follow?

Of course for you or me that's not a problem because we are not strongly 
insisting on HTTP 2.0 over TLS only.

Regards,   Martin.

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Thu, 14 Nov 2013 11:52:10 +0100

Le Mer 13 novembre 2013 23:32, Mike Belshe a écrit :

> with vested interests that are against TLS.

Because Google and friends have no vested interest? They don't have any
relationship with data collection? They've never been condemned in court?
They revenues do not depend on being the only ones able to monitor people
on the Internet? Mozilla revenues do not depend on Google?

>I have yet to hear from a
> agent, or a seller of software which relies on unsecured traffic.

I'm none of those. ham radio operators are none of those.

Please remove your blinders.

-- 
Nicolas Mailhot

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 14 Nov 2013 19:55:38 +0900

> 10-20% failure rates are simply unacceptable for both site operators and

This is a very important point. But if HTTP 2.0 is going to be the big 
thing we think it is, shouldn't most of these problems be addressed in a 
rather short timeframe (maybe not weeks, but also not years)?

If somebody wanted to argue for using HTTP 2.0 in the open (i.e. over 
port 80) as much as possible, couldn't they come up with a scheme that 
tries port 80, and falls back with some extremely lenient variant of TLS 
if port 80 doesn't work? (Please note that this is only a strawman, not 
actually something I'd advocate.)

Regards,   Martin.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 14 Nov 2013 10:58:46 +0000

In message <[email-masked]>, "Nicol

>I'm none of those. ham radio operators are none of those.

Me neither.

See also: http://queue.acm.org/detail.cfm?id=2508864

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Thu, 14 Nov 2013 12:04:56 +0100

Le Jeu 14 novembre 2013 02:09, Willy Tarreau a écrit :
> Eg:

Actually you're pretty much forced to whitelist the SNIs that re not to be
MITM-ed today, because big operators and cloud platforms trivially defeat
any attempt at lightweight control by consolidating very diverse services
on the same SNIs. So operators with clearly defined SNIs that can let be
passed safely are becoming the exception not the norm.

I fact cloud platforms have become such a hodgepodge or safe and unsafe
elements right now I'm firmly convinced that even if it was an acceptable
risk to let their content pass without inspection for malware, giving up
the routing information (to at least try to filter the most objectionnable
parts) is becoming completely unrealistic. And TLS as it stands today does
not permit this short of going to full breakage.

-- 
Nicolas Mailhot

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Thu, 14 Nov 2013 12:16:38 +0100

Le Jeu 14 novembre 2013 02:37, Stephen Farrell a écrit :

> the rest seems like nonsense.

What's the nonsense about filtering video platforms if you don't want to
pay for the bandwidth and your user jobs do not include looking videos on
youtube? Or filtering all the web services that enable to tunnel pretty
much any protocol on http to bypass the firewalls that were set up to
protect your internal equipments?

> I do wonder why people

Because the costs of a security incident, or of users massively using the
web as an entertainment platform like at home, dwarf both the costs of
setting up control equipments or trying to educate users any other way?

How many users does it take in an organisation before they get out of
control and IT support is reduced to an helldesk? Not a lot I can tell you
(except if you're lucky enough when all your users are IT professionals
and even then it won't be an home run).

-- 
Nicolas Mailhot

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 14 Nov 2013 12:18:54 +0100

Hello Martin,

> already saying they won't follow?

He didn't propose this, he proposed that it's not *used* by default, which
is very different. I think this is what could drive TLS adoption up the
most reasonable way without making it a blind requirement with all the
downsides that can be expectd.

> insisting on HTTP 2.0 over TLS only.

You know, I'm for not deciding for others what's best for them. Engineers
design and propose, users adopt, and the most suited design wins (and
rarely the best).

Regards,
Willy

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Thu, 14 Nov 2013 12:24:27 +0100

>> terrible. I wouldn't use that computer :) I hope we increase awareness

Then you won't be paid because the internal reporting app where you
declare your work hours will use the same PKI and you'll need the cert to
access it. (and if you say that's bad: that the same trick Google uses by
putting its recapcha service for example on the same SNI than other Google
services. you can't allow one without the others)

You won't force enterprises not to MITM without giving them alternatives
to monitor their traffic, and you won't help employees by having them
fight their employer on such issues (if anything, they have better stuff
to fight about).

-- 
Nicolas Mailhot

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 14 Nov 2013 11:31:07 +0000

In message <[email-masked]>, "Nicol
as Mailhot" writes:

>to monitor their traffic, [...]

Not to mention enterprises who are mandated by law to do so:

Jails, Libraries, Schools, Mental Institutions are all subject to
such restrictions one place or another on the plant.

We may think that these laws are wrong, but this forum is not
in a position to change them.

And if we make a protocol that must be broken open to comply with The
Law, it will be broken open, even if that compromises everybodys
privacy, globally.

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 15 Nov 2013 02:15:20 +1300

On 14/11/2013 2:42 p.m., William Chan (陈智昌) wrote:
<snip
> them in a MITM proxy: http://www.bbc.co.uk/news/technology-24635752.

I am glad you brought that up. This littl egem of a quote is straight
from the SafeSearch documentation as of right now:

  "This technique will not work on searches done using SSL Search."

It is also noteworthy to remember that not too many weeks ago the same
page had a step-by-step process on how to enable SafeSearch for HTTPS
traffic. Starting with words along the lines of "install a MITM proxy"
and including "rewrite the URL".

I am glad that is gone at least. But there is still no good alternative
to MITM yet.

Amos

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 15 Nov 2013 03:19:23 +1300

> view, it's simply accepting reality.

We need some numbers to back this up.

* Here is the graph of Squid user queries about intercept / MITM proxy.
For bias reduction I have eliminated the Squid Project members who
respond to a lot of user queries.

http://markmail.org/search/?q=intercept+list%3Aorg.squid-cache.squid-users+-from%3A%22Henrik+Nordstrom%22+-from%3A%22Alex+Rousskov%22+-from%3A%22Amos+Jeffries%22

Around about May 2012 an upward spike of more than double the normal
request rate at which the volume has so for over a year now remained
steady relative to the cyclic nature of queries.
(https://blog.mozilla.org/futurereleases/2012/05/09/rolling-out-https-google-search/)

* SSL MITM by comparison was under discussion for several years before
the sudden spike.

* Discussion of HTTPS shows a flat graphs, but the message topics switch
from primarily discussion of HTTPS in reverse-proxy installations,
towards interception of HTTPS.

* Discussion of transparent proxy shows a flat graph. There is an odd
reduction in the last few years but thet is matched by when we split the
traffic mode config options into intercept/sslbump/accel and started
down-playing teh term "transparent proxy" for MITM discussion.

Amos

---

From: Michael Sweet <[email-masked]>
Date: Thu, 14 Nov 2013 11:41:46 -0500

Printers are a classic example of how the PKI/CA system is not ready for providing TLS support for the IoT.  Most printers don’t have stable addresses or hostnames.  The closest you’ll get is the mDNS hostname, e.g., vendorxxxxxx.local., which makes it hard to deploy CA-signed X.509 certificates, either by the vendor or the customer.  So that leaves you with self-signed certificates, usually generated by the printer itself when the customer clicks on the button that turns on TLS support.

In order to provide authentication of the printer you are sending to (to avoid leaking confidential information, for example your latest blood test results), clients currently can perform certain operations (either an “identify” operation that makes the printer beep, flash, and/or display a message, or a simple print job that can be used to confirm things) to establish a minimal level of trust, much like you’d do when pairing with a Bluetooth device. This pairing is *not* foolproof - a MITM proxy could still intercept and forward these pairing operations and the user/client would be none the wiser - but it *does* help prevent passive monitoring and subsequent MITM/impersonation attacks and is probably the best we can do today (for printers at least).

The point of all this is just that adding/requiring TLS for HTTP/2.0 does not, by itself, make HTTP/2.0 more secure, and that deploying TLS properly is not as simple as clicking a button.  Last week the prevailing assumption was that “active attacks are too expensive”, but in the last couple days we have discovered that assumption is not correct and that MITM proxies are widely deployed already.  Addressing that is likely far outside the scope of the HTTP WG, but clearly we can talk about the security considerations, recommend TLS as a general technology that can be used (with caveats) to enhance the security of HTTP/2.0, but leave ourselves open to existing (VPN, IPSEC, etc.) and new security technologies by requiring http:// support (no TLS).

We could also work with the HTTP Auth WG to define a common mutual authentication framework (IIRC there are a couple drafts on the table already), possibly one that identifies all parties in the chain (yes my hands are waving, I don’t know whether that is possible/feasible).  This could work for both http:// and https:// URLs and potentially help solve some trust/validation issues for TLS.

---

From: James M Snell <[email-masked]>
Date: Thu, 14 Nov 2013 08:46:58 -0800

While this is a perfectly valid argument, so far the response from the
folks championing mandatory TLS seems to be, "Well then, just keep
using HTTP/1.1 then". In fact, that exact sentiment has been voiced
several times in this thread.

- James

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 14 Nov 2013 17:02:03 +0000

Just on two points...

On 11/14/2013 04:41 PM, Michael Sweet wrote:
> The point of all this is just that adding/requiring TLS for HTTP/2.0
> does not, by itself, make HTTP/2.0 more secure, 

Adding even opportunistic encryption does make things more secure.
Nobody sensible said anything makes things "secure" without some
qualification.

> and that deploying
> TLS properly is not as simple as clicking a button.  Last week the
> prevailing assumption was that “active attacks are too expensive”,

That's not correct. Lots of discussion last week related to making
pervasive attacks more expensive which is very different to the above.
For example active attacks are much more detectable and hence
riskier which is very different.

Having said that I do agree that the printer/device-as-server
issue is a real one.

S

> but in the last couple days we have discovered that assumption is not
> correct and that MITM proxies are widely deployed already.

---

From: James M Snell <[email-masked]>
Date: Thu, 14 Nov 2013 09:09:08 -0800

Ok, so this raises the question. For clarification it would be great
if some of the folks from Chromium or Firefox could answer this:

  - The proposal that Mark put on the table is HTTP2 over HTTPS Only
for open Internet traffic.
  - William has said that Chromium, at least, will ONLY support HTTP2
over HTTPS, period, without any qualification given about "open" or
"private" internet traffic,

  Therefore, it would be helpful to know...

  - If my printer running on my secure local wifi network hosts an
HTTP/2 server without using TLS, will I be able to use Chrome to
access my printers HTTP/2 server.

If not, then we have a definite problem.

- James

---

From: Michael Sweet <[email-masked]>
Date: Thu, 14 Nov 2013 12:08:52 -0500

Assuming that HTTP/2.0 will be successful (and I hope that to be the case), and assuming that people here care about security (sure seems like it from the volume of mail in the last few days, slashdot story, etc.), HTTP/2.0 needs to actually address how you make a secure implementation of it - that means going beyond mandating TLS - (mutual) authentication, validation, etc.  Security != TLS.

Saying “use HTTP/1.1” doesn’t actually help, since the same security issues that HTTP/1.1 faces today are the issues that HTTP/2.0 will face tomorrow.  

We should also answer the question: what problems is HTTP/2.0 trying to solve?  Are we just concerned with public web browsing, or is the WG trying to make a better version of HTTP/1.1 that can be used in all of the same situations?  Based on the charter I honestly thought that the point of HTTP/2.0 was the latter, but it seems like everyone is just afraid of what the NSA/GCHQ/insert-acronym-here is doing or will do with the bits flowing over the Internet. Clearly that is an important new data point that will influence the design of future protocols, but slapping TLS on HTTP/2.0 or forcing people that can’t/won't use TLS to HTTP/1.1 is security theater, not secure protocol design.

---

From: Zhong Yu <[email-masked]>
Date: Thu, 14 Nov 2013 11:13:49 -0600

On Wed, Nov 13, 2013 at 9:24 PM, Roberto Peon <[email-masked]> wrote:
> .. and if it bothers them, they'd use HTTP/1.1 for web stuff, or are already
> doing so.
>

If that's the case, WebSocket is also "undeployable" since it tunnels
though port 80 as well.

>> continue using the awful CSS sprites trick when their target server is still
>> HTTP/1.1 based.
>> > encryption. Noone is thus forced to do anything: they're not forced to spend
>> > more CPU, etc., unless they believe the benefit outweighs the cost.
>> >

---

From: Patrick McManus <[email-masked]>
Date: Thu, 14 Nov 2013 12:34:19 -0500

> If that's the case, WebSocket is also "undeployable" since it tunnels
that's right. The failure rate of cleartext websockets is much higher than
SSL wss:// websockets. (the failure rate is almost twice as large in
firefox). That's a significant part of the driver here. Websockets made a
mistake by even specifying cleartext. I was there and I've learned that
lesson.

cleartext just doesn't work as, roberto keeps saying.

The only question in my mind is whether or not to require a real
PKI-as-we-know-it authenticated cert. That has tradeoffs - but at least we
expect it would operate.

---

From: Zhong Yu <[email-masked]>
Date: Thu, 14 Nov 2013 11:46:38 -0600

> mistake by even specifying cleartext. I was there and I've learned that

Would it have been a bigger mistake if WebSocket only works on secure
channel? Would that encourage or discourage the deployment of
WebSocket? I think it would definitely have been a deterrent.

In the current scheme, the service provide can try ws:// first. It
might work very satisfactorily (e.g. if most users connect from home
computers). If it does not, the service provider can upgrade to wss://
without too much hassle.

> cleartext just doesn't work as, roberto keeps saying.

Aren't websocket frames masked with random bits?

---

From: Zhong Yu <[email-masked]>
Date: Thu, 14 Nov 2013 12:00:25 -0600

> because developers pick the browser that makes their life easier.

And web servers also need to have an option to operate HTTP/2.0 on
plain TCP to make dev's life easier. It's difficult to see why
browsers/servers would risk to alienate developers. So most browsers
and servers would end up with the capability of talking HTTP/2.0 over
TCP.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Thu, 14 Nov 2013 10:01:42 -0800

Unreliable deployability over port 80 in the open web is well known. See
web devs talking about how to deploy WebSockets:
https://speakerdeck.com/3rdeden/websuckets?slide=42. See Google's
websockets experiment:
http://www.ietf.org/mail-archive/web/tls/current/msg05593.html. I could
pull up more examples, but you probably get the picture by now. No major
service that operates on the open web *currently* deploys WebSockets over
port 80.

If you need reliable deployment over the open web, then port 80 cleartext
is not acceptable. Period. But if you're OK with double-digit failure rates
(maybe that'll go down to single digit in some future world where HTTP/2
has much wider deployment), then it's fine to deploy HTTP/2 for your
service over port 80 cleartext. But large services generally aren't going
to do this, because such high failure rates leads to lots of lost business.

Private networks are a completely different matter of course.

---

From: Roberto Peon <[email-masked]>
Date: Thu, 14 Nov 2013 10:02:18 -0800

Yes, it basically is not reliably deployable over port 80. Websocket-secure
is deployable. At the last conference of web developers that I attended, it
was highly recommended that WS: not be used and instead to use WSS:.

-=R
On Nov 14, 2013 7:13 AM, "Zhong Yu" <[email-masked]> wrote:

> already
> still

---

From: William Chan (陈智昌) <[email-masked]>
Date: Thu, 14 Nov 2013 10:05:11 -0800

> and servers would end up with the capability of talking HTTP/2.0 over
Just to be clear, I'm a browser vendor speaking here, representing my own
personal views, but those generally align with the Chromium project. And
no, we don't have plans to support HTTP/2.0 in the clear. Firefox
developers like Pat have said similar things. So you're simply factually
wrong in your assertion about browsers.

---

From: Tao Effect <[email-masked]>
Date: Thu, 14 Nov 2013 13:07:17 -0500

> How does that make *less* use of encryption a better outcome? 

It seems like you might have replied as you read through the email. I answered this fairly clearly at the end of the email, I think.

Once again:

1. "Fake fixes" aren't fixes.
2. A false sense of security is _worse_ than knowing you aren't secure.

So, yes, please do not impose, or entice people to use, broken encryption. That is not security. That is undermining security.

> What do others think?

I'd also like to hear what others think about Option D (after they've read that email).

Kind regards,
Greg

---

From: Zhong Yu <[email-masked]>
Date: Thu, 14 Nov 2013 12:11:49 -0600

> was highly recommended that WS: not be used and instead to use WSS:.

Agreed. However it didn't need a decree from above. People can
converge to WSS based on profit, not based on law.

If WebSocket was mandated to be on HTTPS channel only, it would have
seen a lot less enthusiasm and implementations.

Even if you think WS is totally useless, what is the harm that it can
possibly cause by including it? What's the drive to forbid it?

---

From: William Chan (陈智昌) <[email-masked]>
Date: Thu, 14 Nov 2013 10:11:58 -0800

I think this is a great question. I confess not to be super familiar with
the printing space, which is why Michael's repeated comments in this
working group have been very useful. I would say that my teammates and I
have not considered this issue very much, and my default inclination is to
tell IPP folks to stick with HTTP/1.X if they only want to support
cleartext. If they want HTTP/2, then they should solve the blockers to
adopting a secure transport. I realize this is a difficult thing to say to
them, and I am open to considering other options, but my teammates and I
really do care about moving all communications over a secure transport, and
holding firm to the stance of only supporting HTTP/2 over a secure
transport is one of our best mechanisms to incentivize folks to tackle the
hard problems that block secure transport (TLS or what have you) adoption.

Cheers.

---

From: Zhong Yu <[email-masked]>
Date: Thu, 14 Nov 2013 12:14:30 -0600

On Thu, Nov 14, 2013 at 12:05 PM, William Chan (陈智昌)
<[email-masked]> wrote:
> personal views, but those generally align with the Chromium project. And no,
> we don't have plans to support HTTP/2.0 in the clear. Firefox developers
> like Pat have said similar things. So you're simply factually wrong in your
> assertion about browsers.

I was just predicting. It's a hassle to setup TLS during development.
How does google handle it internally in developing your SPDY services?

---

From: Mike Belshe <[email-masked]>
Date: Thu, 14 Nov 2013 10:22:35 -0800

Printers can just use HTTP/1.1 if they don't want to use TLS, just like
they can use HTTP/1.0 if they don't support HTTP/1.1

But plenty of printers today already support https.  Enterprises already
have needs for encrypted data to the printer.  The fact that TLS is hard to
deploy there is not a new problem nor relevant to HTTP2 - its not like we
should reduce security to printers because TLS was hard.  The owners of
those printers still have legal needs for TLS :-)

Using TLS everywhere will make it easier for these folks because the
tooling will get better.

Mike

---

From: Mike Belshe <[email-masked]>
Date: Thu, 14 Nov 2013 10:25:25 -0800

On Thu, Nov 14, 2013 at 10:07 AM, Tao Effect <[email-masked]> wrote:

> It seems like you might have replied as you read through the email. I
> answered this fairly clearly at the end of the email, I think.
>
> Once again:
>
> So, yes, please do not impose, or entice people to use, broken encryption.
> That is not security. That is undermining security.
>

Nobody is proposing broken encryption.  If you think that TLS is broken
encryption, then by your own logic you would remove TLS from browsers
entirely - not just from HTTP/2.

Mike

> >> Who's going to pay for these certs that nobody actually needs (because
> of authentication methods that don't need CAs), and why is this unnecessary
> and annoying financial burden being placed on anyone who wants to run a
> world-facing HTTP/2.0 server?
> >
> > As many have pointed out, certs are free from some vendors today. Many
> expect this situation to get better, not worse, over time.
> >
> > That’s not to say we’re tied to the current model of public key
> infrastructure; many have been proposing improvements to it, or completely
> replacements for it. Although that’s not within our charter, we can
> consider referencing such work as part of HTTP.
> >
> >
> >> What happens if a monopoly appears (imagine your worst nightmare, a
> monopoly of monopolies: Symantec+Verizon+ATT+AOL Time Warner), and all of a
> sudden starts to either:
> >>
> >> 2. Lobby their way through the legislative bodies of the world to force
> us to use their certs Because Terrorism™ ?
> >>
> >> Yeah, that's a bit of a loony scenario, but it's actually possible
> thanks to the silly idea of Certificate Authorities.
> >
> >> Is it possible that a danger exists whereby some people (certain
> nuisance-type small business) might end up kicked off the net because HTTP
> 1.0 has "successfully" been migrated over to HTTP/2.0 and the Internet
> Identity Verification Bureaucracy (slogan: "May I see your papers plz?!?")
> cannot seem to find the application they sent in last month?
> >>
> > That seems like a straw man. No one is proposing that HTTP/1.1 will stop
> working or being implemented, and no implementer has an incentive to stop
> support it; doing so would be suicide in a very competitive market.
> >
> >
> >> Will adopting a protocol (TLS) that is known to provide inadequate
> security put a roadblock on the path to implementing real security in web
> browsers?
> >>
> >> I'm rather concerned that, having successfully upgraded their browsers
> to the brand-spanking shiny new HTTP/2.0 goodness, people will have little
> enthusiasm for dismantling the basis of the authentication system that TLS
> uses (Certificate Authorities).
> >>
> >> Objections raised by the nerds in tinfoil hats will be brushed aside
> with the words such as, "adequate". After all, why bother addressing these
> technicalities when we all see so many users smiling at all the shining
> lock icons all over the net?
> >>
> >> Symantec/VeriSign's executives will also be smiling, even wider smiles,
> because they get to literally print money as if they were suddenly the
> Federal Reserve. "Oh, you want a key? Here you go, that'll be $20, come
> back same time next year to renew your security subscription!"
> >>
> >> This is essentially fraud. They are selling a "product" that takes
> approximately zero effort to create, and they get to charge annual fees for
> it while promising security that does not actually exist. Meanwhile, the
> cold creep of the surveillance state settles down upon the quiet town…
> >
> >> The intent expressed on this list by Mark and the browser vendors seems
> quite noble, but anytime the security issue is brought up, all I've seen is
> it being pushed aside to "another working group".
> >>
> >> There exist many proposals for how to fix this situation. The ones that
> I think will work all involve getting rid of the CAs. That, properly
> implemented, would do the trick.
> >>
> >> But I haven't heard from any browser vendor, or any IETF Greybeard,
> that putting the CAs on the chopping block is part of the plan.
> >>
> >> That does not mean I'm against businesses being able to monitor company
> traffic (with consent and knowledge of their employees, etc.). Said
> alternative proposals can be (and some are) able to do such administrivia.
> We don't need CA to do that, however.
> >
> > Please realise this is part of a MUCH larger discussion; Stephen should
> be posting the next steps for the perpass BoF soon, and there are still
> discussions about what to do echoing around the IETF and other places. I
> haven’t heard anyone say that this is the LAST step in improving security;
> just a strong sense that we needed to start.
> >
> >
> >> This is not a problem for this WG to solve. Don't give TLS any novel
> treatment until it is fixed. Leave the security details to Security
> Details, and when it's fixed, work together with them on how to use it with
> HTTP/2.0.
> >

---

From: Zhong Yu <[email-masked]>
Date: Thu, 14 Nov 2013 12:37:12 -0600

What about web interfaces on home devices, like routers. They could
benefit from HTTP/2.0, but not so much from TLS.

On Thu, Nov 14, 2013 at 12:22 PM, Mike Belshe <[email-masked]> wrote:
> Printers can just use HTTP/1.1 if they don't want to use TLS, just like they
> can use HTTP/1.0 if they don't support HTTP/1.1
>
> Using TLS everywhere will make it easier for these folks because the tooling
> will get better.
>
> Mike
>
>
>
> On Thu, Nov 14, 2013 at 10:11 AM, William Chan (陈智昌) <[email-masked]>
> wrote:
>>
>> the printing space, which is why Michael's repeated comments in this working
>> group have been very useful. I would say that my teammates and I have not
>> considered this issue very much, and my default inclination is to tell IPP
>> folks to stick with HTTP/1.X if they only want to support cleartext. If they
>> want HTTP/2, then they should solve the blockers to adopting a secure
>> transport. I realize this is a difficult thing to say to them, and I am open
>> to considering other options, but my teammates and I really do care about
>> moving all communications over a secure transport, and holding firm to the
>> stance of only supporting HTTP/2 over a secure transport is one of our best
>> mechanisms to incentivize folks to tackle the hard problems that block
>> secure transport (TLS or what have you) adoption.
>>
>> Cheers.
>>

---

From: Bruce Perens <[email-masked]>
Date: Thu, 14 Nov 2013 10:41:41 -0800

On 11/14/2013 10:01 AM, William Chan
(陈智昌) wrote:

If you need reliable deployment over the open web, then
port 80 cleartext is not acceptable. Period.

Because to traverse various "transparent proxies", firewalls, etc.,
it is necessary to make the websocket traffic appear to be something
else.

So, we know that there are many mis-implementations, etc.

But there is also the desire of network operators and corporate IT
departments to manipulate web traffic, and maybe that's their right.
Especially for such innocent things as caching.

It's unfortunate that we have been reduced to solving the problem by
implementing better ways to deliberately subvert some corporate
firewall in the name of a user who might be violating his own
company's policies.

Thanks

Bruce

---

From: Tao Effect <[email-masked]>
Date: Thu, 14 Nov 2013 13:43:23 -0500

On Nov 14, 2013, at 1:25 PM, Mike Belshe <[email-masked]> wrote:
> 
> Nobody is proposing broken encryption.

I believe that's exactly what's being proposed.

> If you think that TLS is broken encryption, then by your own logic you would remove TLS from browsers entirely - not just from HTTP/2.

Not TLS itself, but yes, I have stated multiple times that its authentication system needs to be removed from browsers entirely.

- Greg

On Nov 14, 2013, at 1:25 PM, Mike Belshe <[email-masked]> wrote:

> Nobody is proposing broken encryption.  If you think that TLS is broken encryption, then by your own logic you would remove TLS from browsers entirely - not just from HTTP/2.
> 
> Mike
> 
> 
> 
>  
> 
> > What do others think?
>

---

From: Nicholas Hurley <[email-masked]>
Date: Thu, 14 Nov 2013 10:44:54 -0800

> benefit from HTTP/2.0, but not so much from TLS.

Why not? Do you really like the idea of anyone who happens to be on your
network being easily able to see your management password for your home
router? Perhaps you have a friend with a particularly malicious sense of
humor who might want to break your network. Or a wardriver who broke your
WEP encryption (which I still see plenty of in the wild). Or, for that
matter, your kids, who may be old enough to be wondering how to get around
those parental controls on your fancy new router? (Yeah, I pulled out the
"think of the children!" card - not my finest moment, but it's a valid
concern in some cases.)

---

From: Bruce Perens <[email-masked]>
Date: Thu, 14 Nov 2013 10:52:11 -0800

On 11/14/2013 10:44 AM, Nicholas Hurley
wrote:

Do you really like the idea of anyone who happens to be
on your network being easily able to see your management
password for your home router?

Of course not. But I expect the implementor of my home router to
provide security intelligently by requiring HTTPS for management
functions. Not by using the shotgun style and requiring HTTPS
indiscriminately.

Using HTTPS on traffic where it is not necessary is essentially
chaffing the network, and preventing me, the network owner, from
being able to find hostile encrypted traffic among that chaff.

Thanks

Bruce

---

From: Julian Reschke <[email-masked]>
Date: Thu, 14 Nov 2013 19:52:23 +0100

On 2013-11-14 19:44, Nicholas Hurley wrote:
> On Thu, Nov 14, 2013 at 10:37 AM, Zhong Yu <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> humor who might want to break your network. Or a wardriver who broke
> your WEP encryption (which I still see plenty of in the wild). Or, for
> that matter, your kids, who may be old enough to be wondering how to get
> around those parental controls on your fancy new router? (Yeah, I pulled
> out the "think of the children!" card - not my finest moment, but it's a
> valid concern in some cases.)

So how does my home router get a certificate? In particular, if I need 
to configure it first to connect to the internet?

Best regards, Julian

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 14 Nov 2013 18:57:38 +0000

> 2. A false sense of security is _worse_ than knowing you aren't

Protocols do not give any "sense of security" neither true nor
false so attempting to argue from that basis is a fallacy IMO.

If an example helps, some of the very earliest browsers used to
generate session keys very badly - no matter how secure the protocol
had been it'd have made no difference. And afaik there's no way to
give a "sense of security" that'd capture that.

The whole "false sense of security" argument is basically bogus
in this context, it could perhaps be meaningful in a UI developer
discussion, but not here, no matter how good it sounds.

S.

---

From: Bruce Perens <[email-masked]>
Date: Thu, 14 Nov 2013 11:07:45 -0800

On 11/14/2013 10:57 AM, Stephen Farrell
wrote:

That turns out not to be the case for this specific example of
https, because the use of https has been presented to the user as a
security mechanism, with all sorts of visual identification - not
just the presence of the string "https", but lock icons, colors,
etc. The user has also been taught to some extent that non-https
URLs are lacking in security.

---

From: Michael Sweet <[email-masked]>
Date: Thu, 14 Nov 2013 14:13:58 -0500

Mike,

On Nov 14, 2013, at 1:22 PM, Mike Belshe <[email-masked]> wrote:
> Printers can just use HTTP/1.1 if they don't want to use TLS, just like they can use HTTP/1.0 if they don't support HTTP/1.1

No, actually, they can't use HTTP/1.0 if they do IPP.  IPP mandates a minimum of HTTP/1.1 (for chunking, among other reasons).

Aside from some of the cloud/infrastructure extensions we (the Printer Working Group) are working on now, we are also dealing with deployment issues for IPP over USB.  The current mapping over USB uses HTTP/1.1 over bulk in/out endpoints, which means 1 interface for each "connection".  Since most of the SoCs used by printer vendors support 3 or 4 interfaces maximum for every protocol/function a device supports, this can be a major constraint.

Both of these IPP extensions will benefit from HTTP/2.0.  The cloud/infrastructure extensions obviously will make use of TLS and authentication, but doing TLS over USB is both unnecessary and a complete non-starter.

> But plenty of printers today already support https.  Enterprises already have needs for encrypted data to the printer.  The fact that TLS is hard to deploy there is not a new problem nor relevant to HTTP2 - its not like we should reduce security to printers because TLS was hard.  The owners of those printers still have legal needs for TLS :-)

Of course, and I am not suggesting that we don't want TLS.  But I *am* suggesting that TLS is not the answer to every possible security problem.

> Using TLS everywhere will make it easier for these folks because the tooling will get better.

Strictly speaking, the issue is not with TLS but with how certificates are managed, verified, etc.  TLS, done wrong, is just as insecure and out in the open as clear text.  And based on the comments on this list, TLS is being done wrong today, deliberately.

Let's be honest about what TLS offers HTTP, and come up with solutions that apply equally to HTTP/1.x and HTTP/2.0.  And let's retain http:// support in HTTP/2.0 to keep our security and deployment options open.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: James M Snell <[email-masked]>
Date: Thu, 14 Nov 2013 11:20:19 -0800

On Thu, Nov 14, 2013 at 11:13 AM, Michael Sweet <[email-masked]> wrote:
> No, actually, they can't use HTTP/1.0 if they do IPP.  IPP mandates a
> minimum of HTTP/1.1 (for chunking, among other reasons).
>

I personally find this "Printers can just use HTTP/1.1" attitude to be
extremely arrogant. Forcing the use of TLS adds absolutely nothing to
the base function of HTTP/2 and there is no part of HTTP/2
functionality that depends on anything TLS provides.

- James

---

From: Nicholas Hurley <[email-masked]>
Date: Thu, 14 Nov 2013 11:22:17 -0800

On Thu, Nov 14, 2013 at 10:52 AM, Julian Reschke <[email-masked]>wrote:

> So how does my home router get a certificate? In particular, if I need to
> configure it first to connect to the internet?
>
> Best regards, Julian
>

Off the top of my head, here's a couple ways (by no means an exhaustive
list, and by no means are these guaranteed to be the best options):

1. Comes with one from the vendor. The program CD (or USB stick or
whatever) used to do configuration can be specially configured to know
about the otherwise invalid cert being used.
2. First-time setup happens over an unencrypted HTTP/1.1 channel (which is
probably ok, as chances are you're going to be plugged directly into the
router at this point, and as you said - you're likely not connected to the
internet) which then generates a cert and has you install it in your
browser, allowing you to use the secure channel in the future.

All that said, I'm not a UX designer or anything like that, so I'm sure
there would be some rough edges around these workflows, but I'm confident
that we (and UX designers) are smart enough to solve those kinds of issues.

---

From: Zhong Yu <[email-masked]>
Date: Thu, 14 Nov 2013 13:43:59 -0600

> "think of the children!" card - not my finest moment, but it's a valid

It'll be too fun to contemplate attack factors from close family
members. There are so many security holes in your house if your
resourceful child is an adversary. The router could even be replaced
without you knowing it.

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Thu, 14 Nov 2013 20:44:49 +0100

> mistake by even specifying cleartext. I was there and I've learned that

Yep, sure, people deployed all kinds of firewalls to forbid protocols they
didn't trust. Here comes a web developer that says "you dummies, just push
your untrusted protocol on port 80 in the browser I know the security guys
let this pass".

And the result gets blocked. Big surprise.

And http/2 will get blocked too if it uses tls to workaround security
blocks (not that https is not *that* close to being blocked now that
people have used it right and left to bypass security restrictions; the
one good thing about MITM TLS is that it kills such protocol abuses).

I'm astounded anyone is even surprised firewall operators fight
"enhancements" consisting in blowing holes in firewalls. I'm astounded
anyone thinks being sneakier will endear it to those operators. Is the
workgroup charter to improve the http protocol (a safe protocol that is
widely allowed because of its simplicity, lack of side-effects, and
inspectbility) or is its sole aim to fight security equipments in all
possible ways by creating a blackhole monster? Because sometimes I really
wonder…

-- 
Nicolas Mailhot

---

From: Roberto Peon <[email-masked]>
Date: Thu, 14 Nov 2013 11:58:43 -0800

Which devs?

Most developers that I know will choose "reliable" over "easy to debug" any
day of the week. It is not pleasant dealing with heisenbugs. It is better
to not have to debug.

In locales where one knows that http2 can work effectively in the clear,
e.g. corporate LANs, one will be able to do so.

-=R

---

From: Bruce Perens <[email-masked]>
Date: Thu, 14 Nov 2013 11:57:45 -0800

Zhong Yu <[email-masked]> wrote:
>It'll be too fun to contemplate attack factors from close family members.

They aren't the risk, it's all the apps on their iOS and windows systems, which my family members install but have no concept of what they can do. Those devices have cameras, microphones, GPS.

---

From: Gili <[email-masked]>
Date: Thu, 14 Nov 2013 15:10:18 -0500

+1

Gili

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 14 Nov 2013 21:16:39 +0100

> browser, allowing you to use the secure channel in the future.

This cert will have to be self-signed or signed by another one already in the
device. And in order to avoid the browser's error you'll have to install this
signing cert into your browser. Then anyone stealing this cert (assuming it
was generated, if it's shipped it's worse) can sign rogue certs for whatever
domains that will happily be accepted by your browser. You also have the
issue of validity date which generally is not right for such devices.

> that we (and UX designers) are smart enough to solve those kinds of issues.

Yes, just like some other users are smart enough to abuse what smart people
design, this is a never ending loop.

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 14 Nov 2013 21:21:59 +0100

[ trimming the CC list a little bit ]

On Thu, Nov 14, 2013 at 11:57:45AM -0800, Bruce Perens wrote:
> They aren't the risk, it's all the apps on their iOS and windows systems,
> which my family members install but have no concept of what they can do.
> Those devices have cameras, microphones, GPS.

Yes I explain that all the time to coworkers. I have a neighbour whose
Galaxy Tab something regularly tries to retrieve payload from malware
sites via my WiFi access and it provides open ports with HTTP servers
running on them! Most likely I can capture videos and sounds but I don't
know how. It would help me identify the victim at least, because due
to the beauty of WiFi you don't even know where the attacker is :-)

Willy

---

From: Roberto Peon <[email-masked]>
Date: Thu, 14 Nov 2013 12:28:08 -0800

A physical point to point connection would work well...
-=R

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 14 Nov 2013 21:31:20 +0100

> wrong in your assertion about browsers.

Which basically means that the choice of protocols used over the internet
for many things among which browsing will be dictated by two browser teams.

That's a dangerous game to play. It reminds me the old era of "this site was
designed for MSIE4, if it doesn't display correctly, upgrade your browser".

That position doesn't solve the expected raise of the now common issue of
"This connection is untrusted... What Should I Do ? ... I understand the
Risks / Add Exception."

Willy

---

From: Gili <[email-masked]>
Date: Thu, 14 Nov 2013 15:36:03 -0500

It sounds to me like you live in some ivory tower. Most developers suck 
(the average developer is not as smart as you). I've seen plenty of 
cases where debugging code was left in production systems and never 
taken out.

As far as I'm concerned, most developers would pick "easy to debug" over 
"reliable" any day of the week, and I also think saying TLS is required 
for reliability is unfair. There are plenty of "reliable" services out 
there with security holes. That doesn't make them any less "reliable". 
You will never *ever* reach 100% secure, which is why I view security as 
a goal which exists alongside but separate from reliability.

Gili

On 14/11/2013 2:58 PM, Roberto Peon wrote:
>
> Which devs?
>
> Most developers that I know will choose "reliable" over "easy to 
> debug" any day of the week. It is not pleasant dealing with 
> heisenbugs. It is better to not have to debug.
>
> In locales where one knows that http2 can work effectively in the 
> clear, e.g. corporate LANs, one will be able to do so.
>
> -=R
> On Nov 14, 2013 8:02 AM, "Zhong Yu" <[email-masked] 
> > On Thu, Nov 14, 2013 at 1:21 AM, Willy Tarreau <[email-masked] 
> <mailto:[email-masked]>> wrote:

---

From: Roberto Peon <[email-masked]>
Date: Thu, 14 Nov 2013 12:36:26 -0800

Again, while some browsers may not implement http2 as plaintext, that
doesn't mean that a printer wouldn't be able to do it in the clear on an
intranet.

If http2 gets blocked, so be it. I can do nothing about that, and I am
thoroughly unwilling to deal with the deployment and debugging nightmare if
anything less than 100% encryption all the time.

If you need a MITM to feel or be safe, then it is absolutely clear that you
will deploy one. Having thought about and worried about the problem and
even proposed a draft about it (exproxy), even then I absolutely support
browser vendors saying they will not deploy plaintext http2 over the
internet for web traffic. It is not deployable no matter how much you may
wish it to be. This is engineering, pure, plain, and simple.

-=R
On Nov 14, 2013 9:44 AM, "Nicolas Mailhot" <[email-masked]>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 14 Nov 2013 21:37:24 +0100

> A physical point to point connection would work well...

How do you "physically" connect your ipad with your home router?

---

From: Roberto Peon <[email-masked]>
Date: Thu, 14 Nov 2013 12:41:47 -0800

Well, in such cases you may be screwed and should use a device that has
such, else you have an insurmountable trust root problem.

For this particular case, however, you could take a picture of a barcode
equivalent that provided the cert.

Meat-space is important for these things one way or another...
-=R

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Thu, 14 Nov 2013 21:50:55 +0100

> A physical point to point connection would work well...

A physical link does not provide a software protocol by itself

-- 
Nicolas Mailhot

---

From: Roberto Peon <[email-masked]>
Date: Thu, 14 Nov 2013 12:50:58 -0800

That has to be one of the funniest things I've heard in a long time!

No, sorry, I did actually deal with developers and real deployments. Large
numbers of them, actually.

Let me rephrase this.

Developers WILL choose a solution that is 99.99% reliable with a clear and
understandable failure mode over a solution that is broken 10-20% of the
time in unpredictable and unfixable ways.

Or are debating this and saying that developers will choose to deploy
something broken that they can't fix?

-=R
On Nov 14, 2013 10:37 AM, "Gili" <[email-masked]> wrote:

> (the average developer is not as smart as you). I've seen plenty of cases
> where debugging code was left in production systems and never taken out.
>
> "reliable" any day of the week, and I also think saying TLS is required for
> reliability is unfair. There are plenty of "reliable" services out there
> with security holes. That doesn't make them any less "reliable". You will
> never *ever* reach 100% secure, which is why I view security as a goal
> which exists alongside but separate from reliability.
>
> Gili
>
> Most developers that I know will choose "reliable" over "easy to debug"
> any day of the week. It is not pleasant dealing with heisenbugs. It is
> better to not have to debug.
>

---

From: Roberto Peon <[email-masked]>
Date: Thu, 14 Nov 2013 12:57:15 -0800

.. And?
-=R
On Nov 14, 2013 10:51 AM, "Nicolas Mailhot" <[email-masked]>

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 14 Nov 2013 22:03:05 +0100

> something broken that they can't fix?

No but that's generally very complicated in architectures which deal with
many interacting components being developped in parallel. The specs change
all the time as problems are faced. They want something reliable and which
looks close to what the prod looks like. Except that they start by using
private names for their servers and do ugly hacks to rewrite the hard-coded
names in HTML outputs (I've even seen an apache module running "sed" for
that purpose, I didn't know it existed). They also quickly have to deal
with multiple versions in parallel for each component and need to be able
to quickly change an address or port in their config to test if the
regression comes from their code or from the other team's. All this stuff
generally works with hard-coded IP addresses everywhere because the delays
to fill the form to get the internal services to update a DNS entry is one
week while editing win/drivers/system/etc/hosts is immediate but creates
more bugs by having different behaviours depending on the developer's
machine the test is run on (we're exactly in the reliability issue you're
talking about). At the end of the day you have a 20 IP address and 40 ports
assigned to the various components, and only 3-4 of them are used all the
day and the other ones experience a slow death with outdated code and
configs. All these IP and ports are unmanageable with HTTPS and you see
hacks everywhere to rewrite the https://mysite.com/ to
http://192.168.34.167:17890/ to make this work on their development servers.

I had to work in such an environment, it's a hell, you pay people troubleshoot
connectivity issues more often than testing their real code. Things go smooth
after the code is released however because specs don't change that much anymore
and the components can be kept as-is.

Willy

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 15 Nov 2013 10:12:30 +1300

> such, else you have an insurmountable trust root problem.

You do realise that a huge population in India and Africa are using 
networks that consist solely of wireless AP, cellphone or tablet, right?
Electricity supply in many areas is not reliable enough to even run an 
old fashioned PC.

You just cut off how many people? oh well,

Looking forward, the high-tech countries are already rolling out similar 
sorts of networks. Japan for example is rolling out 
HTTP-over-LED_lightbulb and vehicle manufacturers are rolling out 
vehicle-vehicle wireless communication (via proxies!). Now try locating 
the TLS certificate of the lightbulb nearest you when you get of the 
train ... so that you can simply connect to it.

Whats the population of east asia? oh well,

Then there is that media whipping-post about trends in mobile devices 
replacing other technology.

Cut off them and you have lost a majority of the entire population. Both 
Internet-of-Users and Internet-of-Things with no security.

So, how fast were you going to replace/upgrade every single Internet 
connected device on the planet to support cabled connection with HTTP/2?

non-TLS forms of PKI seem to be working far better in those above 
systems for simultaneous performance and security than HTTPS/TLS can 
offer at its best. The TLS system has edges. Long overdue time to admit 
they are there and work towards supporting the next best thing in HTTP/2 
(or is it really going to be an old thing that got sidelined because TLS 
CA model was "easy" ?).

Amos

---

From: Roberto Peon <[email-masked]>
Date: Thu, 14 Nov 2013 13:27:12 -0800

This is going sideways.

You cut out the suggestion about alternate input, e.g. barcode.

There are two nearly orthogonal issues here.
1) security/authentication
2) protocol

It has been said over and over that http2 is specced and will be specced to
allow plaintext on intranets.

Doing so is not a great idea for device configuration of devices where
security matters.

The security issue is separate.

You need a trust chain for authentication.
The best trust chain involves meat-space interaction with the device and
involves no third party and has nothing at all to do with the protocol that
otherwise would be spoken.

-=R
On Nov 14, 2013 11:14 AM, "Amos Jeffries" <[email-masked]> wrote:

> Electricity supply in many areas is not reliable enough to even run an old
> fashioned PC.
>
> sorts of networks. Japan for example is rolling out HTTP-over-LED_lightbulb
> and vehicle manufacturers are rolling out vehicle-vehicle wireless
> communication (via proxies!). Now try locating the TLS certificate of the
> lightbulb nearest you when you get of the train ... so that you can simply
> connect to it.
>
> non-TLS forms of PKI seem to be working far better in those above systems
> for simultaneous performance and security than HTTPS/TLS can offer at its
> best. The TLS system has edges. Long overdue time to admit they are there
> and work towards supporting the next best thing in HTTP/2 (or is it really
> going to be an old thing that got sidelined because TLS CA model was "easy"
> ?).
>
> Amos
>
>
>

---

From: James M Snell <[email-masked]>
Date: Thu, 14 Nov 2013 13:37:36 -0800

Ok great, so HTTP/2 will allow plaintext.  Fantastic. The next
question is: If I have a plaintext HTTP/2 server on my intranet, will
I be able to use Chrome to access that server using HTTP/2?

---

From: Roberto Peon <[email-masked]>
Date: Thu, 14 Nov 2013 13:48:16 -0800

No idea here.
-=R
On Nov 14, 2013 11:37 AM, "James M Snell" <[email-masked]> wrote:

> old
> HTTP-over-LED_lightbulb
> systems

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 14 Nov 2013 22:51:09 +0100

> I be able to use Chrome to access that server using HTTP/2?

No, William has said he doesn't want. So you'll probably have to use another
browser (eg: IE). Maybe it will make MS port IE to Linux, after all they had
a Solaris version 15 years ago and even an OSX one I believe :-) People pick
what works best for them, very few have a religion in this area. That's what
made the success of Firefox and Chrome.

Willy

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Fri, 15 Nov 2013 07:01:22 +0100

> .. And?

And egg meet chicken you need the proocol to make the connexion work, but
you're building a protocol that requires this connexion before working

-- 
Nicolas Mailhot

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Fri, 15 Nov 2013 07:10:44 +0100

Le Jeu 14 novembre 2013 21:36, Roberto Peon a écrit :

> If you need a MITM to feel or be safe, then it is absolutely clear that
> you will deploy one.

I only need a MITM to feel or be safe if browsers insist their mission is
to surrender control of my computers to random web sites and insist on
torpedoing any control system I may wish to deploy on my network to
protect my users (my users, not theirs, because *I* have legal obligations
towards them, not random web sites on the other side of earth of browser
developers)

And I didn't need MITM in http 1.1 that this workgroup charter said it is
tasked to replace, before people decided to embark on wild crusades
against "pervasive surveillance" when every public data fact so far
indicates this "pervasive surveillance" occurs at endpoints and no
protocol change will have any effect on it.

>Having thought about and worried about the problem and
> even proposed a draft about it (exproxy),

And that was much appreciated thank you

-- 
Nicolas Mailhot

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Fri, 15 Nov 2013 07:57:35 +0100

Le Ven 15 novembre 2013 07:01, Nicolas Mailhot a écrit :
> And egg meet chicken you need the protocol to make the connexion work, but

(unless of course I misunderstood and instead of using the physical link
to import a trusted cert in the device you want to use it to import
whatever's in the device in your browser cert store. Making any connected
device factory in China a giant CA able to inject any cert it wants in
millions of browsers. And I thought existing CA security was bad, do you
think the Chinese factory will even bother with a physical lock on its
mastering robots?)

-- 
Nicolas Mailhot

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 15 Nov 2013 15:03:47 +0800

This is getting really off-topic for the list; see previous e-mail.

It’s fine to bring new information to the list, and with discussing the issues. It’s even OK to use this list as a way to try to change the minds of the browser vendors about what their products will support, as long as it is brief and not repetitive. 

We need to focus discussion on what words, if any, will appear in the HTTP spec regarding this issue. 

Regards,

---

From: Zhong Yu <[email-masked]>
Date: Fri, 15 Nov 2013 09:30:22 -0600

Mentioning a specific nationality haphazardly is distractive and
counter-productive for this discussion.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 Nov 2013 12:24:49 +1100

Indeed.

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Mon, 18 Nov 2013 11:56:36 +0100

>> counter-productive for this discussion.

Apologies. Though there's no shame in being the world's electronic factory.

-- 
Nicolas Mailhot