<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA256<br>
<br>
<br>
<br>
On 03/06/2016 05:21 AM, nusenu wrote:<br>
<span style="white-space: pre;">> Moritz wrote:<br>
>> Maybe this is better taken to tor-relays.<br>
> Ok.<br>
><br>
> url to the tor-dev thread:<br>
>
<a class="moz-txt-link-freetext" href="https://lists.torproject.org/pipermail/tor-dev/2016-March/010473.html">https://lists.torproject.org/pipermail/tor-dev/2016-March/010473.html</a><br>
><br>
> Brian didn't say anything about planed deployment locations,
but if<br>
> _all_ relays are within a single /16 network you might skip
MyFamily<br>
> altogether, but I assume they are not.</span><br>
To help better explain this to folks on this mailing list, this
started as a discussion of how to play nicely with the network. To
be a bit less coy, I work for a Linux vendor (CoreOS). Some of our
users run small groups of servers (1-10) many also run clusters of
1000 machines or more. When folks deploy machines, the goal is to
keep the configurations as minimal & static as possible so as to
avoid treating each config as a unicorn. When I deploy a cluster of
machines for a workload they're generally split between Google
Compute Engine, Amazon Web Services, and physical machines split
across a number of different datacenters.<br>
<br>
I was originally inquiring as to how to best inform the network that
these machines are all related so as to be able to<br>
<br>
1) expand the network with a number of hosts<br>
2) Avoid the appearance of a sybil attack<br>
3) Simplify the configuration so that /more/ operators could
duplicate the work<br>
<br>
This originally focused around the use of the Families. At the same
time, I'm coming to the community to give both an anecdote of how we
(and our users) deploy software as well as make sure we're providing
the maximum benefit for the network.<br>
<span style="white-space: pre;">>> In my case machines have a
lifecycle. They come and they<br>
>> go<br>
> out of curiosity:<br>
> What percentage of them do you expect to be online
concurrently?<br>
> (starting when)<br>
> Are planing to rekey when "coming back" or resume with the
former?<br>
></span><br>
This is generally up to operators. In my case, machines generally
*never* "come back." This is to say that I treat all machines as
untrusted (the caveat to this is below) and I treat the provisioning
process as vital to ensuring a minimally tampered state.<br>
<span style="white-space: pre;">>> On 03/05/2016 10:31 PM,
Brian "redbeard" Harrington wrote:<br>
>>> "Lets say you are about to deploy 100 relays within
the next week." -<br>
>>> Take this an order of magnitude greater and we're on
the right track<br>
>>> with the correct scale. It is a regular occurrence
for our users to<br>
>>> deploy 500 to 5000 nodes at a time.<br>
> This is why I said "and maybe set yourself an upper boundary
as to how<br>
> big you want to grow"<br>
><br>
> A single entity deploying 5000 relays isn't very sane at the
current<br>
> network size I guess,<br>
> but instead of speaking of relay counts using CW
fraction/exit/guard<br>
> probability as upper boundaries makes more sense. <10%
might be a worthy<br>
> upper boundary for exit/guard probability.<br>
><br>
> The biggest (known) exit operator is currently at 7-8% exit
probability.<br>
><br>
> teor wrote:<br>
>> And there's likely some limit on MyFamily or on
descriptor size that would stop<br>
>> you listing 1000 fingerprints.<br>
> That is actually another good use-case for replacing the
current<br>
> MyFamily design with something that scales better with family
size like<br>
> Mike's proposed design (#5565), but we did not see declared
families<br>
> that big so far. It was no problem in practice.<br>
><br>
>
<a class="moz-txt-link-freetext" href="https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n364">https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n364</a><br>
>> Server descriptors may not exceed 20,000 bytes in length;
[...] If they do, the<br>
>> authorities SHOULD reject them.<br>
><br>
> So the max family size would be something around 400 relays?<br>
><br>
> (20000 - 1250) / 42 = 446<br>
><br>
> (1250 bytes was the size of a non-exit sample descriptor
without family)<br>
><br>
><br>
>> generating 1000 relay keys and coordinating that key<br>
>> distribution dance across the same number of nodes (more
than likely in<br>
>> highly distributed environments) seems to bring more
questions than it<br>
>> answers (securing the keys for those nodes, securely
distributing them,<br>
>> etc)<br>
> What problems do you expect when generating and transferring
1000 relay<br>
> keys? (besides the descriptor limit)<br>
> ... but before trying to solve any problems it is probably
best to<br>
> answer the question whether a single entities should run
>5% CW fraction<br>
> at all.<br>
><br>
></span><br>
In my normal use case (e.g. non Tor processes) secret keys are never
transferred to a host. This means that (in the case of PKCS#7 &
PKCS#11) key distribution is handled more via CSR rather than
traditional "distribution" (copying of files). In fact, members of
our team are in the process of attempting to ratify this for some
large scale distributed computing projects
(<a class="moz-txt-link-freetext" href="https://github.com/kubernetes/kubernetes/pull/20439">https://github.com/kubernetes/kubernetes/pull/20439</a>).<br>
<br>
This doesn't answer the question of "it is probably best to answer
the question whether a single entities should run >5% CW fraction
at all." I humbly agree that a single entity should probably *not*
operate that much of the network but the reality of the situation is
that when operators have the *abilit**y* to run that much of the
network, they may. The easiest way to challenge this is to expand
the size of the network making it harder to reach that 5% mark. As
an operating system vendor minimizing the deployment process of
this, it could make this easier.<br>
<span style="white-space: pre;">><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
>> There are about 7000 relays in<br>
>> total, with over 1000 of them (almost 40% of the
capacity) at only three<br>
>> ASes.<br>
> Top 3 ASes currently account for 32% cw fraction.<br>
>
<a class="moz-txt-link-freetext" href="https://compass.torproject.org/#?exit_filter=all_relays&links&sort=cw&sort_reverse=true&country=&top=3&by_as">https://compass.torproject.org/#?exit_filter=all_relays&links&sort=cw&sort_reverse=true&country=&top=3&by_as</a><br>
><br>
><br>
> but the top 1000 relays account for >72% cw fraction<br>
><br>
>
<a class="moz-txt-link-freetext" href="https://compass.torproject.org/#?exit_filter=all_relays&links&sort=cw&sort_reverse=true&country=&top=1000&by_as=false">https://compass.torproject.org/#?exit_filter=all_relays&links&sort=cw&sort_reverse=true&country=&top=1000&by_as=false</a><br>
><br>
></span><br>
The final piece of this is that we are currently building
attestation of running Linux containers using the TPM. While these
are being attested by individual signers today, obviously the long
term goal would be to help the current signers of the Tor binaries
use this process in addition to signed tarballs which would then
give a mechanism for full cross distro runtime attestation in a
reproducible way. Walk before running though. Let's make sure this
can nicely play with the network.<br>
<br>
- --redbeard<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2<br>
<br>
iQIcBAEBCAAGBQJW3HlOAAoJEJM/VAg9bfVm1uEP/2+5pa2LPb6fs0Q6HHUcitlb<br>
thom2mghdconlIiCAcFt6uCJ1Soc0RNzbo3Wbqhj0MdtmrSs48BMPlCiY5//4JdQ<br>
h21E1FADM196XhLOUdGol/IVs1L4T2ZHO9okAoGyg6ncXWxPARCTqh4mVlCFXeYV<br>
pTDI/Nu1ur3/XBLePR8oZAGUalHGyswjYR7BwfMoht4g+5vHDByoppSKqBW7lGuL<br>
+VeFnGz1wQ7z8Wae35QRy8XmbaU5iTgk8wiOD1pt+oKayv7mHaYrAK7U+qDFuAa9<br>
hki6jPLYgwa7rYkoUPe6wCqiOnPJG4ynKDb/ANWkgdjtNK03JfMis1Nr/0dY/wv/<br>
VF+CM0SdqUsOkjAAZFInVu7C/qJ5jTPuKTiUTIv/w3KQ7rKv3OnmSYOZPbk22scS<br>
I/TkGCHSzXj9SgcyYRC1o33PBUGKPl3T/cDvaXM3qdctVG1abrIHXD+iNGGTwF4P<br>
5h0mieJq1ZI7qWnYar5/KzU+bnPqJRx1br2XAs9Cit1uwGjRlzmco+LkOsSkYk/D<br>
JnEROC+2KGubyZIbgBEin6ekeId+JZlV/ncNLhosop1iJEnmkmb50w5TKWAykxZQ<br>
/xA6xl2PIHvU89lKpfU062OV0OdOAyWqEwGRDR7ygwtKM2SKPY8aqJUdwJKgoiKT<br>
QYkf2AS+cUBp14RLqtuU<br>
=NOru<br>
-----END PGP SIGNATURE-----<br>
<br>
</body>
</html>