[tor-dev] Proposal 286: Controller APIs for hibernation access on mobile

[Michael Rogers]

On 05/12/17 22:18, teor wrote:
> 
>> On 6 Dec 2017, at 05:12, Michael Rogers <michael at briarproject.org> wrote:
>>
>> If the service needs to fetch a consensus and microdescs before it can
>> respond to a rendezvous cell, the delay could be far longer than the
>> difference in latency between a mobile phone and a laptop. So my point
>> is that the client will be able to tell that the service was woken from
>> idle by the rendezvous cell, which might have implications for the
>> service's anonymity.
>>
>> For example, it lets the client know that the service isn't running on
>> the same device as another service the client recently connected to,
>> otherwise the device wouldn't have been idle. Maybe that's unavoidable,
>> or not worth avoiding, but I just wanted to flag the issue.
> 
> We try to avoid attacks like this.
> Or, if we can't, we try to minimise their effect.
> 
> But when multiple onion services or clients share a tor instance, they also
> share the state of the consensus, directory documents, and guards.
> 
> Our best answer is probably: "don't share a tor instance if you want
> unlinkable onion services".
> 
> Or: "don't IDLE if you want unlinkable onion services".
> (Also, never lose your network connection.)

Sounds reasonable. Maybe something to this effect could be added to the
proposal, so app developers know what to expect in terms of linkability?

Could a long delay between receiving a rendezvous cell and responding
cause any other issues? For example, is there a high probability of the
client timing out before the service has fetched enough directory info
to be able to respond? If so, maybe it's worthwhile for the service to
be more proactive about keeping its directory info fresh?

>> Maybe I've misunderstood the proposal, but I thought the intent was that
>> Tor wouldn't fetch anything in IDLE mode, and wouldn't automatically
>> change from IDLE to IDLE_UPDATING - it would need a SLEEPWALK signal to
>> tell it to change to IDLE_UPDATING, and then it would automatically
>> change back to IDLE when it was done.
> 
> LIVE fetches directory documents so it always has a live consensus.
> IDLE fetches directory documents just often enough to stay online.
> SLEEP fetches nothing.

OK, so I guess the use case for SLEEPWALK is telling Tor to fetch a live
consensus and microdescs when it otherwise wouldn't have done - i.e. it
allows the controller to manage the freshness of the directory info?

But I'm really just guessing here. Nick, can you clarify?

>> Rather than the controller picking an interval, would it be better for
>> Tor to specify (maybe in its response to the IDLE signal) when it next
>> needs to be woken?
> 
> Or, "the latest time it can be woken to have directory documents with
> property X", where X is some combination of:
> * a live consensus
> * a reasonably live consensus
> * enough non-expired descriptors to build circuits

Yup, I think that makes sense - it achieves [what I guess is] the
purpose of SLEEPWALK while keeping knowledge about *why* Tor needs to be
woken at that time encapsulated within Tor, which is an improvement.

>>> So if IDLE doesn't meet your needs, it would help us to know why. If
>>> there's enough demand for it, it may be better to add a "WARM" state,
>>> where Tor checks for directory documents whenever a consensus
>>> expires, and otherwise acts like IDLE.
>>
>> Within the scope of this proposal that sounds like a good solution. But
>> if we're looking ahead to changes that allow the device to sleep without
>> shutting down Tor or disabling its network connectivity, then the
>> controller will need to be responsible for managing sleeps and wakeups,
>> which fits better with [my guess as to the intent of] the SLEEPWALK
>> mechanism than a WARM state.
> 
> We do need a use case here :-)
> 
> And yes, I agree that the controller should be able to manage wakeups.

OK, I have two use cases. They go beyond the scope of this proposal
because they're also concerned with CPU wakeups, but I'm not sure we can
really design the controller API without considering CPU wakeups at all.

The first use case is saving power by putting the device to sleep, while
keeping a hidden service available.

"Sleep" on Android is similar to suspend on Linux (for recent Android
kernels it's identical). User-space code is paused and the kernel only
responds to a limited set of interrupts, including network activity and
alarms.

Entering this state without disabling Tor's network connectivity causes
it to panic when the device wakes up - its libevent timers don't fire
during sleep, so it thinks the clock has jumped. Just suppressing that
panic reaction doesn't seem like a good idea. It would be better if we
could warn Tor that the device is about to sleep, so it should stop
building circuits and making connections, and should expect the clock to
jump. This was my original motivation for asking for an "idle mode".

If Tor tells the controller when it needs to be woken then the
controller can schedule an alarm.

The second use case is similar to the first, except the controller has
less flexibility about scheduling alarms because the device is in "doze
mode". This is a new power-saving mode on Android 6 that imposes extra
restrictions beyond normal sleep, such as ignoring wake locks, shutting
off network access and postponing alarms. If the user adds the app to a
whitelist then it can hold wake locks and use the network, but it's
still limited to scheduling alarms once every 15 minutes.

(This is totally braindead, by the way - if you want to do one second of
work every 14 minutes, your only choice is to hold a wake lock that
keeps the device awake the whole time, whereas before the new "power
saving" restrictions you could have scheduled an alarm and let the
device sleep. But such is Android.)

So for this use case, the controller can't wake Tor more than once every
15 minutes. If we're only waking Tor to fetch directory info and publish
HS descriptors, that's probably fine. But other ideas we considered,
like waking Tor once per minute so it can keep behaving more or less
normally, won't work in doze mode.

In both scenarios (sleep and doze), if there's any network activity
before the next alarm, the controller can grab a wake lock to keep the
device awake while Tor handles the network activity. There are two ways
we could achieve that: Tor could inform the controller about the network
activity, or Tor could connect to the network through a localhost proxy
provided by the controller, which would manage the wake locks transparently.

Cheers,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x9FC527CC.asc
Type: application/pgp-keys
Size: 4660 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20171206/55387650/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20171206/55387650/attachment.sig>