Re: Moving forward on improving HTTP's security

Please Mike, tell us what you _really_ think :P

On Wed, Nov 13, 2013 at 12:41 PM, Mike Belshe <mike@belshe.com> wrote:

> <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 <mike@belshe.com> wrote:
>
>>
>>
>>
>> On Wed, Nov 13, 2013 at 12:01 PM, William Chan (陈智昌) <
>> willchan@chromium.org> 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.
>>
>
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?


>
>>
>>
>>> * 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.
>>
>
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.


>> Mike
>>
>>
>>
>>
>>
>>
>>>
>>>
>>> On Wed, Nov 13, 2013 at 10:14 AM, Mike Belshe <mike@belshe.com> wrote:
>>>
>>>> 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 <contact@taoeffect.com>wrote:
>>>>
>>>>> On Nov 13, 2013, at 12:31 PM, Tim Bray <tbray@textuality.com> wrote:
>>>>>
>>>>> Let’s not let the perfect be the enemy of the good.
>>>>>
>>>>> 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
>>>>>
>>>>> --
>>>>> Please do not email me anything that you are not comfortable also
>>>>> sharing with the NSA.
>>>>>
>>>>> On Nov 13, 2013, at 12:31 PM, Tim Bray <tbray@textuality.com> wrote:
>>>>>
>>>>> On Wed, Nov 13, 2013 at 9:22 AM, James M Snell <jasnell@gmail.com>wrote:
>>>>>
>>>>>> 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.
>>>>>>
>>>>>
>>>>> 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 <mnot@mnot.net>
>>>>>> wrote:
>>>>>> [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 suitable
>>>>>> requirements to encourage interoperability; suggestions for text are
>>>>>> welcome.
>>>>>> >
>>>>>>
>>>>>> 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 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.
>>>>>> >
>>>>>>
>>>>>> 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
>>>>>>
>>>>>> > 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.
>>>>>> >
>>>>>> >
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>