Re: Moving forward on improving HTTP's security

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