[Cryptography] Moving forward on improving HTTP's security

Greg greg at kinostudios.com
Thu Nov 14 00:46:09 EST 2013


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20131114/f31a24d1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20131114/f31a24d1/attachment.pgp>


More information about the cryptography mailing list