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