Tor-dev mailinglist proposal

Hi. What are your thoughts on having an anonymity distro depend on Hidden Service descriptors for timesyncing purposes?

The only weakness identified is that if a Hidden service forges its descriptor timestamp deliberately, it could perform a time replay attack within an 18 hour window. How serious is this?

The Proposal we are considering is:

Use of Hidden Service descriptors to obtain more accurate time:

There are some problems with using Directory Authority consensus data, the only one IMO is the fuzzy window of three hours which makes it harder to set a realistic time.

My proposal is to have sdwdate query the DHT for specific Hidden Service descriptors from the HSDir Authorities without actually connecting to them and calculate a more finegrained time to set. Here is why i think its a good idea:

Descriptors contain a timestamp field which shows the time they are generated.Time reported is number of microseconds since 1970.
Descriptors are signed by the HS and cannot be spoofed by the HSDirAuth.
Descriptors are refreshed hourly. [1]
A "malicious" HS that want to fool our time check has to go out of its way and forge the timestamp in its descriptor. If they are doing this by just running with a wrong clock, they will make themselves inaccessible.
The damage is much limited (only and 18 hour window not 7 days) before HSDir Authorities reject these forgeries. [2]
There does exist stable, available and friendly HS besides the TPO one that was taken down. The only addresses that will be used are ones in the "pal" pool. These will be Whistleblowing and Freedom friendly sites. Some suggestions: Wikileaks, RiseUp (each service they provide has a unique HS address assigned), TheNewyorker's SecureDrop service and probably more.
The way to go about this is to fetch descriptors without connecting.
The timestamps will be compared for to get an accurate reading.

A high time resolution is possible, we can pinpoint within that one hour range the probable time because each server was started at a different time than the other so it uploads its descriptor at asyncronously.

With 1400 HSAuth Dirs on the network, I don’t think there will be much of a load problem.

[1] Trawling Tor Hidden Service – Mapping the DHT | Donncha Ó Cearbhaill
[2] torspec - Tor's protocol specifications

Not tor-dev, tor-talk. tor-dev is only for discussions related to development of Tor core or other projects of their own, TBB and stuff. tor-talk is for community discussions.

More comments later.

I didn’t know this. please feel free to post this on the correct channels and refer me to them. I will sign up and respond in the ensuing discussion.

Probably best to first post to x and then to y? (x/y is either/or tor-talk / tails-dev) With a delay in between? Perhaps feedback from tor-talk can help write an even better proposal for tails-dev?

Generally, the proposal assumes to much from the reader. Imagine to be a reader like Steven J. Murdoch. Just a random example. Ask yourself, where would he stumble? He probably has immense knowledge about hidden service internals and more, but has otherwise he may not have looked closely at Tails or Whonix development, might have never closely look into tordate, etc. Not sure if that’s the case, but you get the point. Of course, you can’t really have even the slightest clue how it is to be someone else. But humans have a good understanding for “what I know, what X does not know”. So attempting an approximation is helpful.

I am trying to prevent the discussion being about the side issues.

  • What consequences using an ~18 hours old Tor consensus has is a separate question, I think. Whether this is really really bad or totally doesn’t matter, is totally irrelevant for getting time from hs descr. Having a second time opinion from hs descr may be useful independently of everything else.
  • Readers on tor-talk, even though are high profile people, do not necessarily have ever heard about sdwdate. I think mixing in sdwdate will derive / focus the discussion on the wrong thing.
  • Setting time from Hidden Service descriptors is not necessarily related to anonymity distributions. Someone could find it useful while not being interested in anonymity at all.

Possible sources for confusion… I mean, I know what you mean, by the tor-talk reader will not know:

  • current proposal - | - what they might think
  • “our time check” - Their what? Their what time check?
  • (only and 18 hour window not 7 days) - What? What 7 days?
  • “pal” pool - ?

I guess it’s best to omit sources for confusion.

I am really worried that people would not know what we are talking about.

Use your mod power and feel free to edit it for improvements.

-remove the sources
-define what we mean with anondate.

-I really don’t know how we can ask for an opinion on our design from people who may not be familiar with it.
-I think its better if its simplified as two simple questions in an IRC discussion than having a proposal that may be misunderstood and incorrectly evaluated.

Our priority is to confirm this approach is workable and find out if its possible to fetch descriptors without connecting to a HS. Also tbh I’m not worried about the replay attack because we will use trusted sources.

Suggesting it to tails-dev later is good for them too, but I’m not going to be wanting to spend too much effort to convince them. They’ve done great work but sometimes I think that some concepts are not well understood even by them. Its a complicated subject.

Posted a better copy to the list.

https://lists.torproject.org/pipermail/tor-talk/2014-September/034724.html

It’s difficult, indeed. The question needs to be broken down to a generalized point. Nevertheless, it’s much worth it. Got lots of good advice during Whonix development that way.

IRC gets often more causal, less thought through, researched answers right from the stream of consciousness one a person. Also another fraction of community reads it (they overlap, yes) and due to online / offline times, fewer have a chance to answer. For some stuff, IRC is nice. For other stuff, mailing list is better.

Suggesting it to tails-dev later is good for them too, but I'm not going to be wanting to spend too much effort to convince them.
Well, if you manage them to say "wow that's an awesome idea, we haven't thought off, we do it some time", then you likely also very deeply convinced me and made me excited to implement it soon.
Its a complicated subject.
That's for sure. More reason having more people understand and judge it's sane.

No answer yet, but maybe in a few days.

If there will be no answers anywhere - which is rather unlikely, tails-dev will likely answer (Whonix Forum) - then it might help to implement the “read time from Tor consenus” as well as the “extract time information from hidden service descriptors” code in a standalone, separate github project. Does not have to include the time snychronization daemon. Just the parsing code. And then ask tor-talk again what they think about that approach and that code. Sometimes code makes it clearer what it’s about.

<pragmatist> armadev: what do you think about my proposal for safeguarding against bridge stale consensus?
<armadev> ticket #?
<Sebastian> armadev: well, now that you replied I don't need my reply anymore
<Sebastian> so it's ok
<pragmatist> armadev: no I haven't opened a tciket for it but will if you like the idea.
<armadev> i don't know what you're talking about
<pragmatist> armadev: at the moment bridges can feed clients a stale consensus up to 7 days in the past. I propose that Tor fetches a consensus straight from a directory authority through a connection made asap it connects to Tor
<armadev> oh. i think that would be horrible. hundreds of thousands of users doing that could overwhelm the directory authorities.
<armadev> it's nice to have trusted amazing stable infinite points in the system
<pragmatist> armadev: I see
<armadev> 7 days is a long time
<armadev> maybe we should reduce that number
<pragmatist> armadev: yeah that was what I was going to suggest next
<Sebastian> If we do we auto-decrease the amount of storage for consdiffs
<armadev> what's the #define called?
<Sebastian> for what?
<armadev> for 7
<Sebastian> TOLERATE_MICRODESC_AGE?
<Sebastian> hrm no
<armadev> networkstatus.c:#define REASONABLY_LIVE_TIME (24*60*60)
<armadev> i'm going to go with 'one day'
<armadev> where did the number 7 come from?
<Sebastian> oh, my comment about consensus diff time thing above was dumb. it's wrong
<Sebastian> I don't know where the 7 came from. But I thought I recalled that, too.
* Matanza has quit (Remote host closed the connection)
<Sebastian> I think I thought it because #define OLD_CERT_LIFETIME (7*24*60*60)                                                                                                                                                                 
<armadev> right. but that's a cert
<Sebastian> right
<armadev> also i think i have a ticket open about a bug in that cert lifetime thing ;)
<Sebastian> but after a few years I thought it was for consensus, not cert ;)
<Sebastian> heh
<armadev> sebastian: putting a 'not yours' sign on top of the pony does not count as delivering it
<Sebastian> armadev: hm?
<Sebastian> I closed the pony as fixed tho
* Matanza (~Matanza@1QLAAAFFO.tor-irc.dnsbl.oftc.net) has joined #tor-dev
<armadev> hum hm. yes. fair enough. you may have your pony. thank you. :)
<Sebastian> heh
* stash (~savage@1QLAAAFFQ.tor-irc.dnsbl.oftc.net) has joined #tor-dev
<armadev> pragmatist: ?
<pragmatist> armadev: sorry what were you saying?
<pragmatist> I agree one day tops is a healthy limit
<pragmatist> for consensus health
<Sebastian> pragmatist: the question is, where does the "one week" number come from
<pragmatist> from TAILS documentation
<pragmatist> their page on secure time syncing mentions this as a side issue
<pragmatist> that consensus up to 7 days old could be fed to clients using a bridge
<pragmatist> would you like a link?
<Sebastian> huh. Everyone knows the one week thing. Where do they know it from... Because now that I think about it, in the past we always knew we had 1 day to fix our "the dirauths can't vote together" stuff before the network would collapse
<pragmatist> epistemology. How do we know what we know :P
<pragmatist> Sebastian: so the cutoff is just 1 day then?
<Sebastian> and sure, I'd like a link. And I'd like to talk to the tails people where their number comes from, and if it is true it's a Tor bug and if it is wrong then it's a Tails website bug
* stewart (~stewart@ppp221-38.static.internode.on.net) has joined #tor-dev
<pragmatist> https://tails.boum.org/contribute/design/Time_syncing/
<pragmatist> "If using a bridge: your bridge can replay an old (one week old max.) consensus, which is used until HTP has fixed the time; not good, but probably a compromise we can make. If your bridge also can set up a SSL MitM attack against the HTP connections (e.g. the attacker also controls a SSL CA shipped by Debian), it can trick you into using this old consensus for max. one week, which is much worse.
<pragmatist> "
<Sebastian> oh
<Sebastian> this is neither a Tor bug nor a tails website bug
<Sebastian> you're just confused a bit
<Sebastian> (I think. Or I am wrong)
<Sebastian> The idea here is that *if* an attacker can control your computer's time, it can feed you a consensus up to a week old
<Sebastian> and you'll believe it
* jeffbl (~Thunderbi@69-196-171-46.dsl.teksavvy.com) has joined #tor-dev
<pragmatist> Are they saying: if the time is being fetched from a non trusted source then right?
<Sebastian> consensuses older than that won't work because onion keys will be rotated
<Sebastian> which leads me to think, what if the onion keys won't be rotated on the relays which you put into the consensus once, years ago
<Sebastian> pragmatist: yes
<pragmatist> thanks for explaining
<armadev> ah. yes, the 7 days thing is the onion key rotation period.
<armadev> #define MIN_ONION_KEY_LIFETIME (7*24*60*60)
<pragmatist> armadev: I thought some more about an alternative for setting time. It might be much easier than needing an entire specification to implement it. TAILS used to have something called 'Tordate' before the HTP sync impementation they have now. I used to which set time according to the valid range given by the consensus data, which was pretty big: 3 hours. My idea works the same way except the current time according to the Dir Server,
<pragmatist>  is timestamped into the documents, giving torrified distros a safe trusted source to set their clock.
<armadev> please define 'Dir Server'?
<pragmatist> dir server : Directory Authority
<Sebastian> You shouldn't place that much trust in dirauths
<Sebastian> You're trusting me to provide accurate time. Only in a few weeks will I start having an internet-independent time source for my dirauth
<pragmatist> Sebastian: Yeah I know but its the best we got. Much better than non authenticated NTP servers
* GhostAV (~GhostAV@0001f216.user.oftc.net) has joined #tor-dev
<pragmatist> I read Linus Nordberg's proposal for decentralizing that trust even partially to limit the impact of the Directory authorities being popped.
<pragmatist> its another issue but still
<Sebastian> One of the other concerns is that it's silly to require that the dirauths act like regular relays and speak the normal Tor protocol
<pragmatist> Would my suggestion need it to be so?
<Sebastian> Yes, I think
<pragmatist> If the consensus document contain an extra filed called "current time" that would be enough for this purpose it would be enough IMHO. All that is needed is to write a simple bash script to parse this info and use it accordingly
<pragmatist> *field
<Sebastian> the consensus has that field already
<pragmatist> but does it give something more specific than a range of three hours ?
<Sebastian> valid-after 2014-09-14 00:00:00
<Sebastian> fresh-until 2014-09-14 01:00:00
<Sebastian> valid-until 2014-09-14 03:00:00
<Sebastian> no
<Sebastian> that's what it says
<pragmatist> what is your opinion on having something more specific in there?
<Sebastian> that doesn't work. You need to learn more about how Tor works. We should move to #tor. This is not a development discussion
* GhostAV_ has quit (Ping timeout: 480 seconds)
<pragmatist> alright thanks again. I really read the dir-spec but clearly I don't seem to know much :/
<Sebastian> I'm waiting for you in #tor
<pragmatist> k I'm in

***

<Sebastian> pragmatist: So, the consensus is generated once per hour
<Sebastian> it is signed by all directory authorities
<Sebastian> the slightest change to it makes it invalid
* chobe_ (~chobe@c-24-21-130-132.hsd1.or.comcast.net) has joined #tor
<Sebastian> and any single dirauth cannot make it change without the others agreeing
* jdi (~jdi@digi00666.digicube.fr) has joined #tor
<pragmatist> Sebastian: So the fresh until is a good approximation of current time within one hour?
<Sebastian> generating the consensus is a 10-minute process, so you can't do it arbitrarily often. You also don't *want* to do it too often, because people have to fetch it, and that takes bandwidth
<Sebastian> It is definitely currently valid-after or later
<Sebastian> assuming a majority of dirauths have correct clocks
<Sebastian> there are no other guarantees about anything when you receive a consensus document, especially when you consider your source to be untrustworthy
* gerforce has quit (Quit: leaving)
<pragmatist> Sebastian: what would make it untrustworthy if one only uses valid documents?
<Sebastian> you cannot verify if the document is valid if you don't know the current time
<pragmatist> I understand the fact that Dir Auths are susceptiple to targetting
<Sebastian> because maybe the document is expired
<arma> if your clock is in 2013, and i guess that and give you a consensus from the time your clock thinks it is, you'll believe it
<pragmatist> Right but if I am fetching it from the directory server itself then what is the harm. I mean if the server is lying to me the potential damage is much greater
<arma> you keep using ambiguous terminology. every bridge is a directory server, and many relays are too.
<pragmatist> Directory Authority
<pragmatist> bridges are eliminated from my trust scenario atm
<Sebastian> The directory authority cannot "lie" to you about anything other than time (at least for our current discussion)
<Sebastian> but it can lie about time.
<pragmatist> Sebastian: I had an alternative idea that uses Hidden Service descriptors for that. If you are interested please give it a quick look and tell me what you think
<pragmatist> https://lists.torproject.org/pipermail/tor-talk/2014-September/034724.html
<Sebastian> Also, to know you're talking to the directory authority, you need to speak Tor
<Sebastian> which brings us back to the other point about needing to speak Tor
<Sebastian> I don't think I need t oread it
* jdi has quit (Ping timeout: 480 seconds)
<Sebastian> because if you have no valid time, there's no Tor for you
<Sebastian> no trusted Tor at least
<Sebastian> I will read it now regardless
<pragmatist> Sebastian: It assumes a rough valid time based on consensus is used to allow Tor to even connect at all. That idea builds on that and tries to find a more accurate way to tell time after that point
* Doug has quit (Ping timeout: 480 seconds)
<Sebastian> there are no hsdir authorities
* sinfallas (~sinfallas@186-92-52-166.genericrev.cantv.net) has joined #tor
<arma> i think the right fix here is for tor to have code that tries to learn an accurate time:
<pragmatist> I meant the Hidden service servers that store descriptrs
<arma> the algorithm should be to look at the netinfo cells you see, and the consensus you get, and if you agree with them, done, and if you disagree, escalate in some way
<arma> and then tails should ask tor via the control interface what time tor thinks it is
<arma> this idea has been known for years. it lacks a developer because, i guess, nobody who understands the idea cares about tails and also can code.
<Sebastian> you're trusting relays to properly discard hs descs after 18 hours
<Sebastian> thisi s not a good design
<pragmatist> arma: yes it probably needs manpower that you don't have thats why I was trying to see if there is anyway to get around that without having someone do this
<pragmatist> Sebastian: Yeah not very robust, but thts why it relies on what we see as friendly HS exclusively
* Zarutian has quit (Quit: Zarutian)
<arma> oh god, is the idea that all tails clients would visit a hidden service which would tell them what time it is?
<pragmatist> No not the HS itself just look at the descriptor
<pragmatist> visiting the place itself would be a huge security risk
<Sebastian> arma: the idea is, the Tor network discard hs descs after 18 hours
<arma> oh. but as sebastian said, descriptors can exist for, well, as long as somebody chooses not the delete them.
<Sebastian> which is a flawed assumption if your security depends on it
* torPolipo has quit (Remote host closed the connection)
<pragmatist> arma: but doesn't every HS issue a new descriptor on an hourly basis?
* torPolipo (~torPolipo@enjolras.gtor.org) has joined #tor
<arma> or more often. sure. but hsdir relays can give out whatever they want in response to a query.
<pragmatist> oh whoops
<Sebastian> pragmatist: you rely very hard on "if I ask for a document, the reply will be the document I expect!"
<Sebastian> this is not a solid assumption
<arma> you'd do better asking a random relay, via your bridge, what time it is.
<arma> and now you're on your way to the design i described above
* feverDream has quit (Read error: Operation timed out)
* sinfallas has quit (Quit: Saliendo)
<pragmatist> Sebastian and arma: My ideas are worthless in that regard. Thanks again for taking the time to discuss these approaches in detail.
<Sebastian> no worries, security is hard. It's easy to design a system you yourself cannot break, and peer review is paramount.
<arma> why would visiting the hidden service be a huge security risk?
<Sebastian> arma: who said that?
<arma> i think it would be a huge performance bottleneck. but if hidden services scaled infinitely it would not be so bad.
<arma> <pragmatist> visiting the place itself would be a huge security risk
<Sebastian> oh
<Sebastian> I missed that line
<Sebastian> sorry I thought you were talking to me
<pragmatist> arma: I am talking from the view they have a target on their backs
<pragmatist> Say the wikileaks server for instance would be of interest to the NSA I assume
<arma> ah. but that weakness would carry over to whatever the hidden service published, too.
<arma> s/published/did, in general/

Summary of points:

  • The bridge replay attack lasting for 7 days is only possible if the system clock is being fooled.
  • Tor consensus is renewed every hour by Directory Authorities.
  • The only time that makes sense to set from in the consensus document, is the fresh until one.
  • The Hidden Service descriptor idea is not a good idea they concluded.
  • Nothing short of implementing a way for in Tor’s protocol to talk about the current time, cuts it.

How to proceed now is up to you. Maybe anondate only is not such a bad idea seeing that the range is narrowed down considerably to one hour intervals.

The Hidden Service descriptor idea had similar accuracy from what I found out because descriptor publication timestamps are rounded to the hour to avoid leaking Hidden Service clocks.

TAILS used to have something called 'Tordate' before the HTP sync impementation they have now.
"Used to" means (as per English grammar) "They did in past, but now they're not doing that anymore". - Tails still is using tordate. It's not a past thing.

Basically yes, but maybe it’s getting more complex, see:
https://mailman.boum.org/pipermail/tails-dev/2014-September/006898.html

So you provoked scrutiny, great!

- The only time that makes sense to set from in the consensus document, is the [b]fresh until[/b] one.
Why? I am failing to draw such a clear conclusion.

Consensus example:

valid-after 2014-09-14 18:00:00 fresh-until 2014-09-14 19:00:00 valid-until 2014-09-14 21:00:00

tordate / anondate: example mid range would be:

19:30:00
"Used to" means (as per English grammar) "They did in past, but now they're not doing that anymore". - Tails still is using tordate. It's not a past thing.

I thought they had completely replaced it it with the HTP approach. Guess I was mistaken then.

tordate / anondate: example mid range would be:

19:30:00

Makes sense. Its renewed every hour so the next “fresh” interval is 20:00. 19:30 would be half way. Correct.

Because we are dealing with a narrow range of just 30 mins, I think it makes sense to use on its own.

What are your thoughts on this as an implementation for anondate, can it be considered “good enough” to use on its own?

We have two nice ideas that are waiting for implementation: