Re: Moving forward on improving HTTP's security

On Nov 14, 2013, at 12:41 AM, Mark Nottingham <mnot@mnot.net> wrote:
> 
> 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

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

On Nov 14, 2013, at 12:41 AM, Mark Nottingham <mnot@mnot.net> wrote:

> Hi Greg,
> 
> A few quick responses from my standpoint inline; I imagine others will step up with more details.
> 
> 
> On 14 Nov 2013, at 1:27 pm, Tao Effect <contact@taoeffect.com> wrote:
>> 
>> 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?
> 
> 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.
> 
> 
>> 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.
> 
> How does that make *less* use of encryption a better outcome? 
> 
> 
>> 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.)
> 
> 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.
> 
> 
>> 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…
> 
> This problem has a lot of visibility. Again, I don’t see how less use of encryption helps solve it.
> 
> 
>> 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.
> 
> 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.
> 
> 
>> 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.
> 
> There was VERY strong consensus that this is not acceptable in Vancouver. What do others think?
> 
> Cheers,
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
> 
>