Re: Moving forward on improving HTTP's security

On Nov 13, 2013, at 10:04 PM, Mark Nottingham <mnot@mnot.net> wrote
> 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.

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

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

On Nov 13, 2013, at 10:04 PM, Mark Nottingham <mnot@mnot.net> wrote:

> 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,
> 
> 
> On 14 Nov 2013, at 10:58 am, Tao Effect <contact@taoeffect.com> wrote:
> 
>> 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
>> 
>> --
>> Please do not email me anything that you are not comfortable also sharing with the NSA.
>> 
>> On Nov 13, 2013, at 9:10 PM, Tao Effect <contact@taoeffect.com> wrote:
>> 
>>> On Nov 13, 2013, at 8:56 PM, Frédéric Kayser <f.kayser@free.fr> 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
>>> 
>>> --
>>> Please do not email me anything that you are not comfortable also sharing with the NSA.
>>> 
>>>> 
>>>> 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:
>>>> 
>>>>> On Wed, Nov 13, 2013 at 12:01 PM, William Chan (陈智昌) <willchan@chromium.org> wrote:
>>>>> 
>>>>> * 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?
>>>>> 
>>>>> 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.
>>>>> 
>>>>> * 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 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.
>>>> 
>>> 
>> 
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
>