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,
--
♥Ⓐ isis agora lovecruft
_________________________________________________________
OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35
Current Keys: https://fyb.patternsinthevoid.net/isis.txt
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev