Nicolas Gailly transcribed 59K bytes:
Hi,
Here's a new version of the proposal with some minor fixes discussed
with teor last time.
0.4:
- changed *included* to *appended*
- 3.2: end of paragraph, a valid consensus document contains a
majority
of CoSi signatures.
- Acknowledgments include teor and Tom Ritter.
As always, critics / feedbacks / thoughts are more than welcome :)
Thanks !
Nicolas
Ps: Our team and I are going to be at PETS this year, so if you don't
have time now to
read the whole thing, but you are still willing to know about CoSi and
how it could improve
Tor security, I/we will be happy to talk with some of you there also.
Hello all,
At PETS this afternoon, Nicolas Gailly, Philipp Jovanovic, Ismail
Khoffi,
Georg Koppen, Nick Mathewson, and I met to discuss the collective
signing
proposal. I'm just going to breifly summarise the discussion here.
One of the major concerns voiced was that, if we made it mandatory that
a
collective signature on a consensus be verifiable (for some N number of
signers, where N might be all of them but it's not important) for a
client to
accept and use a consensus, then attacks upon the witnesses (or any
disruption
to the witness signing system) will cause clients to no longer be able
to
bootstrap. Conversely, if we made it so that it only emitted some
warning
when the collective signature could not be verified, then (likely) no
users
would see this warning (or even if they did, they'd treat it in the
same
manner as a TLS certificate warning and simply click through it).
There is also concern that, with enforcing collective signatures, that
the Tor
network has a larger attack surface w.r.t. (D)DoSing: an adversary
could DoS 5
of the 9 DirAuths *or* they could DoS whatever necessary percentage of
the
witness servers. Additionally, an adversary who controls some portion
of the
witness servers may DoS other witnesses in order to amplify the
relative
proportion of the collective signature which they control.
There was some discussion over whether to integrate this into core tor,
or
rather to just use Nicolas' CoSi Golang tool in a separate process.
Everyone
agreed that rewriting something from Go to C is suboptimal.
One idea was if we used CoSi, but rather than "don't trust/use a
consensus if
it doesn't have a good CoSi" we could use it as a mechanism for clients
to
report (to some system somewhere? perhaps part of the prop#267
consensus
transparency logs?) when CoSis don't verify successfully.
Another idea was to use CoSi to sign the metadata file which Firefox's
updater
uses to learn where to fetch updates so that a client would know that
the same
Tor Browser updates were being served to other different vantage
points.
Todo list:
1. It's not super necessary, but more analysis of the bandwidth
overhead for
running this protocol would be nice, i.e. network-wide overhead,
not just
the overhead for a single witness.
2. It would be nice to have some RFC-like description so that
alternate
implementations could be created, e.g. include encodings, state
machines,
message formats. (We strive to maintain our specifications with
the
delusion that there are secretly hundreds of other tor
implementations in
every existing language, and that any of them should be compatible
if they
follow the specification.)
3. Update the proposal to mention that each DirAuth would have their
own
tree, thus the consensus document in the end would have somewhere
between
5 and 9 CoSi signatures.
4. There's a typo in §5.2: s/witnesse's/witnesses'/
Thanks, everyone, for the great discussion!
Best regards,
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev