unsubscribe On Fri, Jul 22, 2016 at 10:00 PM, <tor-dev-request@lists.torproject.org> wrote:

Send tor-dev mailing list submissions to tor-dev@lists.torproject.org

To subscribe or unsubscribe via the World Wide Web, visit https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev or, via email, send a message with subject or body 'help' to tor-dev-request@lists.torproject.org

You can reach the person managing the list at tor-dev-owner@lists.torproject.org

When replying, please edit your Subject line so it is more specific than "Re: Contents of tor-dev digest..."

Today's Topics:

1. Re: Tor with collective signatures (isis agora lovecruft) 2. Further sandboxing Tor Browser (aka Tor + Firejail redux). (Yawning Angel)

----------------------------------------------------------------------

Message: 1 Date: Thu, 21 Jul 2016 15:05:07 +0000 From: isis agora lovecruft <isis@torproject.org> To: tor-dev@lists.torproject.org Cc: Philipp Jovanovic <philipp.jovanovic@epfl.ch> Subject: Re: [tor-dev] Tor with collective signatures Message-ID: <20160721150507.GE8911@patternsinthevoid.net> Content-Type: text/plain; charset="utf-8"

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