[Cryptography] Moving forward on improving HTTP's security

[Owen Shepherd]

And lose the one opportunity we get to force traffic over to TLS for more
than a decade?

Great is the enemy of good. How long is making TLS perfect going to take?
How long is it going to be before HTTP3 or similar comes about in which we
once again get an opportunity to fix it?

Let us be clear: TLS makes the spies jobs much harder. Every bit of
encryption is more calculation that they have to do, assuming they've
managed to extract the keys of the site they're attacking. While obviously
they have the ability to mint their own keys, this requires active attacks.

TLS makes things harder, and by giving people the incentive to deploy TLS
now in order to gain the benefits of HTTP2, we don't have to try and force
the deployment in time when we do finally get DANE or TACK or Certificate
Transparency deployed.

Besides, I can't think of a better way to get millions of web developers to
pressure browser vendors to implement DNSSEC DANE, which is perhaps one of
the best hopes we have for an actual trustable model.
 On 14 Nov 2013 19:45, "Greg" <greg at kinostudios.com> wrote:

> On Nov 13, 2013, at 7:05 PM, John Kelsey <crypto.jmk at gmail.com> wrote:
>
> So your solution is what?  Continue sending data in the clear?
>
>
> The basics would be to not use the CAs. Working on rest of details,
> they're mostly finished, just gotta make 'em nice 'n pretty. And some code
> would be good, too.
>
> Why not push to get TLS used everywhere, and also push for certificate
> transparency and EA certs to make it harder to do CA attacks?
>
>
> Is it OK if I just copy/paste my response from the IETF list here? I think
> it answers your question.
>
> Below the row of equals signs, is an email that was the other list. You
> can also read it at this archived link:
> http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0721.html
>
> =========================================================
>
> On Nov 13, 2013, at 10:04 PM, Mark Nottingham <mnot at 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.
>
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20131114/2395df48/attachment.html>