[148179] in cryptography@c2.net mail archive
Re: [Cryptography] Moving forward on improving HTTP's security
daemon@ATHENA.MIT.EDU (Greg)
Thu Nov 14 14:45:08 2013
X-Original-To: cryptography@metzdowd.com
From: Greg <greg@kinostudios.com>
In-Reply-To: <74F57D36-8036-449F-A13B-63EF46A157A8@gmail.com>
Date: Thu, 14 Nov 2013 00:46:09 -0500
To: John Kelsey <crypto.jmk@gmail.com>
Cc: Cryptography <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============3254249381630844655==
Content-Type: multipart/signed; boundary="Apple-Mail=_EEA11271-5572-4303-9D29-01B6F4FA7C85"; protocol="application/pgp-signature"; micalg=pgp-sha512
--Apple-Mail=_EEA11271-5572-4303-9D29-01B6F4FA7C85
Content-Type: multipart/alternative;
boundary="Apple-Mail=_1C0EFDCE-BB7B-4A4F-B50C-29EF5FB1DFA4"
--Apple-Mail=_1C0EFDCE-BB7B-4A4F-B50C-29EF5FB1DFA4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
On Nov 13, 2013, at 7:05 PM, John Kelsey <crypto.jmk@gmail.com> wrote:
>=20
> So your solution is what? Continue sending data in the clear? =20
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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
On Nov 13, 2013, at 10:04 PM, Mark Nottingham <mnot@mnot.net> wrote
> Thanks, and don=92t beat yourself too badly =97 we=92re all guilty of =
this in some way. The current conversation is=85 challenging, in that we =
all have strong feelings about it.=20
>=20
> 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=99
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=99 ?
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.
--Apple-Mail=_1C0EFDCE-BB7B-4A4F-B50C-29EF5FB1DFA4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=windows-1252
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><div>On Nov 13, 2013, at 7:05 PM, John Kelsey <<a =
href=3D"mailto:crypto.jmk@gmail.com">crypto.jmk@gmail.com</a>> =
wrote:<blockquote type=3D"cite">So your solution is what? Continue =
sending data in the clear? =
<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote type=3D"cite">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?</blockquote></div><div><br></div><div>Is it OK if I just =
copy/paste my response from the IETF list here? I think it answers your =
question.</div><div><br></div><div>Below the row of equals signs, is an =
email that was the other list. You can also read it at this archived =
link: <a =
href=3D"http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0721.h=
tml">http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0721.html=
</a></div><div><br></div><div>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</div><div><br></div><d=
iv>On Nov 13, 2013, at 10:04 PM, Mark Nottingham <<a =
href=3D"mailto:mnot@mnot.net">mnot@mnot.net</a>> =
wrote</div><div><blockquote type=3D"cite">Thanks, and don=92t beat =
yourself too badly =97 we=92re all guilty of this in some way. The =
current conversation is=85 challenging, in that we all have strong =
feelings about it. <br><br>Great to have you =
contributing.</blockquote><div><br></div>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". ^_^<br><br></div><div>Again, apologies for criticizing =
the proposal without providing any explanation. I finished reading the =
RFC and have written down my observations and objections =
below:</div><div><br></div><b>1. $$$</b><div><br></div><div>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?</div><div><br></div><div><b>2. $$$ + The =
Terrorist Lurking Just Behind the =
Corner=99</b></div><div><br></div><div>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:</div><div><br></div><div>1. Gobble up the browser vendors and/or =
put them on their payroll; or,</div><div>2. Lobby their way through the =
legislative bodies of the world to force us to use their certs Because =
Terrorism=99 ?</div><div><br></div><div>Yeah, that's a bit of a loony =
scenario, but it's actually possible thanks to the silly idea of =
Certificate Authorities.</div><div><br></div><div><b>3. Annoying Small =
Businesses</b></div><div><br></div><div>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?</div><div><br></div><div>Yet =
another loony-toons scenario brought to you by: Certificate =
Authorities.</div><div><br></div><div>(I know, I know, "Not our problem, =
leave it to the TLS guys to fix later". I address this =
below.)</div><div><br></div><div><b>4. Cultivating Apathy and Enabling =
Fascists</b></div><div><br></div><div>Will adopting a protocol (TLS) =
that <i><u>is known to provide inadequate security</u></i> put =
a roadblock on the path to implementing <u>real</u> security =
in web browsers?</div><div><br></div><div>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).</div><div><br></div><div>Instead, it might go =
something like this:</div><div><br></div><div>"Yeah! Go us! We made the =
web encrypted! We're... <i>Encryption =
Heroes!!</i>"</div><div><br></div><div>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?</div><div><br></div><div>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!"</div><div><br></div><div>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...</div><div><br></div><div><b>5. Conclusion and RFC =
#>9000</b></div><div><br></div><div>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".</div><div><br></div><div>OK, that's perfectly =
fine, but let them do their work, and leave the security decisions to =
them.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Therefore, I =
propose a fourth alternative (to the three existing =
ones).</div><div><br></div><div><b>Option D: Do =
nothing.</b></div><div><br></div><div>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.</div><div><br></div><div>Lao Tze would =
approve.</div><div><br></div><div><b>The pros of this =
approach:</b></div><div><br></div><div>1. The problem remains like a =
painful thorn in everyone's backside, gnawing at our collective =
subconscious.</div><div><br></div><div>That's exactly as it should be. =
"Fake fixes" aren't fixes.</div><div><br></div><div><b>The cons of this =
approach:</b></div><div><br></div><div>1. The problem remains like a =
painful thorn in everyone's backside, gnawing at our collective =
subconscious.</div><div><br></div><div>That's exactly as it should be. =
"Fake fixes" aren't fixes.</div><div><br></div><div>Thanks for =
considering.</div><div><br></div><div>- =
Greg</div><div><br></div><div><div =
apple-content-edited=3D"true">--<br>Please do not email me anything that =
you are not comfortable also sharing with the =
NSA.</div></div></body></html>=
--Apple-Mail=_1C0EFDCE-BB7B-4A4F-B50C-29EF5FB1DFA4--
--Apple-Mail=_EEA11271-5572-4303-9D29-01B6F4FA7C85
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQEcBAEBCgAGBQJShGOlAAoJEKFrDougX6FkJwEIAKiQPj3/X9LCKX+L9JSTO79Y
cNR4Pr7Q3mFsLa/8XaUGTMQt5oPEM8v7+JnfV6SPGURfDl1zMNlKKisVoGwBdebR
KGl8VBcTtaHmJqZZg54AwGDrkDpt3PCq9WAce7JxJ79deEOXwhqLMsPU7CtB06sO
3jAZ0NO7eR+CIwVpGrmdkkTiM9blO7s5luY6HQnKUp4gU56hydwhp5MVmT8p0mwG
OnKcYR0NCaAvz1ydN4U0A/sZuuYFq/mhBXe4Dn05OOG1tF4FjLOXeAwjmFlRHgUk
ASDatAWa9SAv9iXAC91qLxZVkZu47us6wCBMVlLYfMG8aGQKdvfxoBpbpqX1ZJ0=
=U3FW
-----END PGP SIGNATURE-----
--Apple-Mail=_EEA11271-5572-4303-9D29-01B6F4FA7C85--
--===============3254249381630844655==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============3254249381630844655==--
