[tor-dev] Draft proposal: Tor Consensus Transparency

[Linus Nordberg]

Ximin Luo <infinity0 at torproject.org> wrote
Sun, 06 Jul 2014 17:06:56 +0100:

| (Disclaimer, I don't know the details of how consensus documents
| work. Some assumptions I made might be wrong.)
| 
| In section 2 Motivation, you mention a partition attack. I think the
| rest of the document neglects the topic of *actually protecting
| against this*, instead focusing only on running the log. I want to
| emphasise that CT logs are only an enabler, not a guarantor, of the
| security property. The monitors are the important thing, that actually
| detect attacks. (Someone needs to be watching, otherwise all security
| measures are useless.)

Good point. What do you think about this?

   Note that while the proposed solution gives some protection against
   using a false consensus, in addition to high chance of detection,
   this is not the primary goal but more of a nice side effect.


| With X509, domain owners have the rightful control on what
| certificates say, but CAs can issue certs on their behalf. CT monitors
| protect against this, by getting data from logs and checking that the
| certificates for each domain have all been issued with the permission
| of the owner.
| 
| With the tor consensus document model, it's more vague exactly what
| the monitors should check for. To protect against a partition attack,
| you might do something like "monitors should check that the diff
| between consensus documents is small, within a small time period". But
| the precise parameters will need to be adjusted and justified, and
| this is important for robust detection of the attack.

Operators of directory authorities can look for consensuses they don't
recognise. This was my immediate thought but obviously misses out on the
benefits of decentralisation of consensus verification.

Others could indeed "check the diff". I will add text addressing that
after having looked at what is being done in the field of diffing
consensuses as part of one of the GSoC projects.

More ideas for things to look for?


| Also, are there any other threats you want to protect against?

No.


| >  A log monitor verifies that the contents of the log is consistent
| >  with the rules of the Tor network, notably that all entries are
| >  properly formed and signed Tor consensus documents.
| 
| Don't Tor clients do this already? CT gives us the ability to detect
| things that a single client cannot already detect, such as a partition
| attack on the overall network, so we should focus on that.

This validates the functionality of the log more than anything
else. Maybe this should move to "Log auditing".