Re: Moving forward on improving HTTP's security

On Thu, Nov 14, 2013 at 10:07 AM, Tao Effect <contact@taoeffect.com> wrote:

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

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?
>
> 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/
> >
> >
> >
> >
>
>