<div dir="ltr"><br><div><div><div><div class="gmail_extra"><div><div dir="ltr"><div class="gmail_quote">On Wed, Jul 23, 2014 at 12:00 PM, <span dir="ltr"><<a href="mailto:cryptography-request@metzdowd.com" target="_blank">cryptography-request@metzdowd.com</a>></span> wrote:<br>
<br></div><div class="gmail_quote"><snip><br></div><div class="gmail_quote"><br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Send cryptography mailing list submissions to<br>
<a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a><br>
Date: Wed, 23 Jul 2014 05:32:39 -0700<br>
From: John Denker <<a href="mailto:jsd@av8n.com">jsd@av8n.com</a>><br>
To: <a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a><br>
Subject: Re: [Cryptography] hard to trust all those root CAs<br>
Message-ID: <<a href="mailto:53CFAB67.2050406@av8n.com">53CFAB67.2050406@av8n.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
On 07/22/2014 04:59 PM, Russ Nelson wrote:<br>
><br>
> Crypto without a threat model is like cookies without milk. Keep<br>
> saying it until it becomes second nature to specify the threat model.<br>
<br>
The moderators wisely insist on brevity. However, we<br>
have to give up something in return. You don't get to<br>
snip out the threat model and then complain that no<br>
threat model was specified.<br>
<br>
I hate to belabor the obvious, but on 07/19/2014 02:03<br>
PM, the OP in this thread did mention MITM attacks and<br>
did cite data on forged certificates in the wild.<br>
<br>
If you want the next level of detail, it is known that<br>
the NSA acts as a MITM at the /hardware/ layer: they<br>
intercept and tamper with shipments after they leave<br>
the manufacturer and before they reach the end-user.<br>
They can insert back doors in everything from consumer-<br>
grade stuff like cable modems, to corporate firewalls,<br>
to carrier-grade backbone routers. This meddle-in-the-<br>
middle approach saves them the trouble of suborning a<br>
whole bunch of manufacturers directly; all they need<br>
to do is suborn a handful of shipping companies. This<br>
is documented in the Snowden files; no tin-foil hat is<br>
required.<br></blockquote><div><br><div><div>I could see a business around this: NSA-proof shipping company, using Apple's model, put out an NSL notice each month:<br><br></div><ul><li>For January, we have not received any Nation Security Letters this month.</li>
<li>On the month you receive one, you stop putting such notices out, and sell the now-useless business.</li></ul></div>This doesn't stop the receiving country from inserting such devices, but would help regain some trust overseas about NSA bugged devices that ship from the USA.<br>
</div><div><br clear="all"><div>- Justin</div><div class="gmail_quote"><a value="+15042081158" style="color:rgb(17,85,204)"><br></a></div><div class="gmail_quote">PS: Sorry about quoting the digest<br></div><a value="+15042081158" style="color:rgb(17,85,204)"><br>
</a><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
If the Chinese PLA Third Department is not installing<br>
their own back doors, I'd be shocked. If they weren't<br>
doing it a year ago, they must have read the Snowden<br>
files as a how-to manual. For equipment made in China,<br>
they can demand direct cooperation from the manufacturers.<br>
<br>
Couple that with a rogue CA. Now you're drowning in<br>
milk.<br>
<br>
Note that back doors are notoriously hard to secure.<br>
A third party gets to choose the NSA back door, or<br>
the Third Department back door, or some generic stack-<br>
overflow bug, or whatever.<br>
<br>
A question for each person on this list: Are you sure<br>
that all of your communications with your banker, doctor,<br>
lawyer, mistresses, etc. move over networks that are<br>
immune to MITM attacks? If so, please raise your hand.<br>
<br>
On 07/22/2014 03:07 PM, Jerry Leichter wrote:<br>
> I forget the name, but there was a plugin that would warn you of<br>
> unexpected changes in location of the CA.<br>
<br>
It can't be a very successful solution, if people refer<br>
to it in the past tense, and can't remember the name.<br>
<br>
Note the contrast: As currently deployed:<br>
SSL relies on authority, with no pinning or notary.<br>
SSH relies on pinning, with no authority or notary.<br>
PGP relies on web-of-trust, which usually boils down<br>
to little more than a labor-intensive form of pinning.<br>
<br>
As discussed on 09/27/2013 09:43 AM, I reckon a heterotic<br>
approach would greatly increase security in all three cases.<br>
I use the term "pinning" to refer to local approaches,<br>
and "notary" to refer to network-based online approaches.<br>
<br>
AFAICT no "perfect" solution is possible. If somebody<br>
wants to make a Truman Show / Matrix fake universe for<br>
you to live in, they can do so -- in principle. However,<br>
I reckon that good crypto engineering can make this much<br>
more expensive to do, and much easier to detect.<br>
<br>
Evidently there are no widely-deployed solutions;<br>
otherwise we wouldn't be seeing forged certificates<br>
in the wild. Is there anything on the horizon?<br>
If not, why not?<br>
<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.14 (GNU/Linux)<br>
Comment: Using GnuPG with Thunderbird - <a href="http://www.enigmail.net/" target="_blank">http://www.enigmail.net/</a><br>
<br>
iQIVAwUBU8+rYPO9SFghczXtAQJ/<div id=":1yx" class="">xRAAn1DVw6rNhsGwom5Evg4FWuhJHpn/q9aa<br>
4hmh20tCFba9erXtXeEzGmAdGXvNpy/u7dRk46FclQPrVJciLg3uTsaHLijOFWng<br>
YA3vg1H5HbTmDvTo+gDG/AWiO3Ix6WCkFWn7AsJowue7mmzfFKpcb9/VSAw9Zo+0<br>
C/dddCj0xrwKSkOkNCHo08bB461AQe++Iq5PsPVNeVabnB64FWuB0SuJBigKxRNz<br>
KN3C4xwE9ruQ/dGYhJA9NbGAQCg1iE3VY6DQHG00vdih0dyIbtDdLlxjvJeJhfvW<br>
2Z3SBd4snglbo2LxmtQeS3KeDDdJf8aWHW3duOEWE5MXRsM3SkS73WGdE2ib7yOA<br>
1Ex8QqozAeYwm+MW1FpjR8z2/XhCMDZebn1iy+a8SVP1ScEbbl4OKxJs7IDlIK9y<br>
yxfHXClJXAYe5U9CjU92oVnBfkgtJasSPsjwPcY++ZRcSpmTUNLZejL69elgHGCq<br>
qMVJGIuVEpeGGZmgWG14yES1fTrI7KwR7HsnvBYf2gFgI5G94BQ5dC+BmCkIJZKt<br>
/qMPQFqEQdIClk1u53jgNODXWA7Ft3h/o1k4e9lSs7FO98RRBS+ixzSqBBCQdxBq<br>
5D94WpF4jd5Gs+eeVI6uJfX8zTPAj5fy5hHbtu0nU1tiyth+WuSWlXqw3JuASuaw<br>
MWSE8IgB5yE=<br>
=Ih1m<br>
-----END PGP SIGNATURE-----<br></div></blockquote><br><br><br><br><br><br><br><br><br><br><br><br><br></div></div></div><br></div></div></div></div></div>