<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/