[148181] in cryptography@c2.net mail archive
Re: [Cryptography] Moving forward on improving HTTP's security
daemon@ATHENA.MIT.EDU (Owen Shepherd)
Thu Nov 14 17:42:49 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <C5DF885A-7641-4BD6-A81D-6755AD9588A1@kinostudios.com>
Date: Thu, 14 Nov 2013 22:25:04 +0000
From: Owen Shepherd <owen.shepherd@e43.eu>
To: Greg <greg@kinostudios.com>
Cc: John Kelsey <crypto.jmk@gmail.com>,
Cryptography <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============6206125014884482841==
Content-Type: multipart/alternative; boundary=047d7bf19852aa194e04eb2a8d7b
--047d7bf19852aa194e04eb2a8d7b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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@kinostudios.com> wrote:
> On Nov 13, 2013, at 7:05 PM, John Kelsey <crypto.jmk@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 cod=
e
> 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 thin=
k
> 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=E2=80=99t beat yourself too badly =E2=80=94 we=E2=80=99re=
all guilty of this in
> some way. The current conversation is=E2=80=A6 challenging, in that we al=
l 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=E2=84=A2*
>
> 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 u=
s
> to use their certs Because Terrorism=E2=84=A2 ?
>
> 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 HTT=
P
> 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 TL=
S
> 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 f=
or
> 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 wi=
th
> 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@metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
>
--047d7bf19852aa194e04eb2a8d7b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">And lose the one opportunity we get to force traffic over to=
TLS for more than a decade? </p>
<p dir=3D"ltr">Great is the enemy of good. How long is making TLS perfect g=
oing to take? How long is it going to be before HTTP3 or similar comes abou=
t in which we once again get an opportunity to fix it?</p>
<p dir=3D"ltr">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&=
#39;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 acti=
ve attacks.</p>
<p dir=3D"ltr">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 TAC=
K or Certificate=C2=A0 Transparency deployed.</p>
<p dir=3D"ltr">Besides, I can't think of a better way to get millions o=
f web developers to pressure browser vendors to implement DNSSEC DANE, whic=
h is perhaps one of the best hopes we have for an actual trustable model.<b=
r>
</p>
<div class=3D"gmail_quote">On 14 Nov 2013 19:45, "Greg" <<a hr=
ef=3D"mailto:greg@kinostudios.com">greg@kinostudios.com</a>> wrote:<br t=
ype=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style=3D"word-wrap:break-word"><div>On Nov 13, 2013, at 7:05 PM, John =
Kelsey <<a href=3D"mailto:crypto.jmk@gmail.com" target=3D"_blank">crypto=
.jmk@gmail.com</a>> wrote:<blockquote type=3D"cite">So your solution is =
what? =C2=A0Continue sending data in the clear? =C2=A0<br>
</blockquote><div><br></div><div>The basics would be to not use the CAs. Wo=
rking 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, an=
d 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 cop=
y/paste my response from the IETF list here? I think it answers your questi=
on.</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:=C2=A0<a href=3D"ht=
tp://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0721.html" target=
=3D"_blank">http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/072=
1.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><div>On Nov =
13, 2013, at 10:04 PM, Mark Nottingham <<a href=3D"mailto:mnot@mnot.net"=
target=3D"_blank">mnot@mnot.net</a>> wrote</div>
<div><blockquote type=3D"cite">Thanks, and don=E2=80=99t beat yourself too =
badly =E2=80=94 we=E2=80=99re all guilty of this in some way. The current c=
onversation is=E2=80=A6 challenging, in that we all have strong feelings ab=
out it.=C2=A0<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, an=
d I especially liked the "Tao of the=C2=A0IETF". ^_^<br><br></div=
>
<div>Again, apologies for criticizing the proposal without providing any ex=
planation. 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 (bec=
ause of authentication methods that don't need CAs), and why is this un=
necessary 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 Corne=
r=E2=84=A2</b></div><div><br></div><div>What happens if a monopoly appears =
(imagine your worst nightmare, a monopoly of monopolies: Symantec+Verizon+A=
TT+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 the=
ir payroll; or,</div><div>2. Lobby their way through the legislative bodies=
of the world to force us to use their certs Because Terrorism=E2=84=A2 ?</=
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.</d=
iv><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 In=
ternet Identity Verification Bureaucracy (slogan: "May I see your pape=
rs plz?!?") cannot seem to find the application they sent in last mont=
h?</div>
<div><br></div><div>Yet another loony-toons scenario brought to you by: Cer=
tificate Authorities.</div><div><br></div><div>(I know, I know, "Not o=
ur problem, leave it to the TLS guys to fix later". I address this bel=
ow.)</div>
<div><br></div><div><b>4. Cultivating Apathy and Enabling Fascists</b></div=
><div><br></div><div>Will adopting a protocol (TLS) that=C2=A0<i><u>is know=
n to provide inadequate security</u></i>=C2=A0put a roadblock on the path t=
o implementing=C2=A0<u>real</u>=C2=A0security in web browsers?</div>
<div><br></div><div>I'm rather concerned that, having successfully upgr=
aded their browsers to the brand-spanking shiny new HTTP/2.0 goodness, peop=
le will have little enthusiasm for dismantling the basis of the authenticat=
ion 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...=C2=
=A0<i>Encryption Heroes!!</i>"</div><div><br></div><div>Objections rai=
sed by the nerds in tinfoil hats will be brushed aside with the words such =
as, "adequate". After all, why bother addressing these technicali=
ties when we all see so many users smiling at all the shining lock icons al=
l 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 w=
ere suddenly the Federal Reserve. "Oh, you want a key? Here you go, th=
at'll be $20, come back same time next year to renew your security subs=
cription!"</div>
<div><br></div><div>This is essentially fraud. They are selling a "pro=
duct" that takes approximately zero effort to create, and they get to =
charge annual fees for it while promising security that does not actually e=
xist. 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 wo=
rk, and leave the security decisions to them.</div><div><br></div><div>Ther=
e 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 businesse=
s being able to monitor company traffic (with consent and knowledge of thei=
r employees, etc.). Said alternative proposals can be (and some are) able t=
o 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 ho=
w 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&qu=
ot; 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&qu=
ot; aren't fixes.</div><div><br></div><div>Thanks for considering.</div=
><div><br></div><div>- Greg</div><div><br></div><div><div>--<br>Please do n=
ot email me anything that you are not=C2=A0comfortable also sharing with th=
e NSA.</div>
</div></div><br>_______________________________________________<br>
The cryptography mailing list<br>
<a href=3D"mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a><=
br>
<a href=3D"http://www.metzdowd.com/mailman/listinfo/cryptography" target=3D=
"_blank">http://www.metzdowd.com/mailman/listinfo/cryptography</a><br></blo=
ckquote></div>
--047d7bf19852aa194e04eb2a8d7b--
--===============6206125014884482841==
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
--===============6206125014884482841==--
