23:11:08 <isis> #startmeeting prop#245 prop#282 23:11:08 <MeetBot> Meeting started Tue Feb 20 23:11:08 2018 UTC. The chair is isis. Information about MeetBot at http://wiki.debian.org/MeetBot. 23:11:08 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic. 23:11:40 <isis> okay, to start someone who is not the author should summarise their understanding of each proposal 23:11:55 <nickm> I think that's not me :) 23:12:25 <nickm> Unless I count as a different person with the passage of time... 23:12:40 <teor4> I'll do prop#245 23:13:21 <teor4> Tor used to use its own circuit authentication protocol 23:13:29 <isis> nickm: according to Anthropic Decison Theory, you do, but maybe someone other, other different person for now :) 23:13:46 <isis> *some other, other 23:14:03 <teor4> It was named "TAP" (the Tor Authentication Protocol) by the author of a paper that pointed out that is was broken and slow 23:14:56 <teor4> All supported version of Tor now use ntor (the "new" tor authentication protocol), which is faster and more secure 23:15:45 <teor4> But the version 2 hidden service protocol still uses TAP in some places, because it was hard-coded into the protocol data structures 23:16:20 <teor4> In particular, v2 onion service descriptors contain TAP keys, so client intro uses TAP for the last hop 23:16:49 <teor4> and the v2 INTRODUCE cell contains a TAP key, so service rendezvous circuits use TAP for the last hop 23:16:50 <teor4> fin 23:17:18 <teor4> Oh, I think the proposal is to deprecate v2 onion services and remove TAP entirely 23:17:59 <nickm> not exactly, tbh 23:18:09 <isis> teor4: thanks! 23:18:19 <nickm> It assumes that we will deprecate v2 onion services, and uses that assumption to explain how to remove TAP entirely 23:19:35 <isis> (i'll save the summary of prop#282 for later) 23:20:02 <isis> it sounds like we can do step 1 of prop#245 now, e.g. in 0.3.4.x 23:20:39 <teor4> #action update the target releases in prop#245 23:20:46 <isis> without breaking anything, under the assumption that plenty of previous versions will be around for a while 23:21:05 <isis> #link https://gitweb.torproject.org/torspec.git/tree/proposals/245-tap-out.txt 23:21:27 <isis> #link https://gitweb.torproject.org/torspec.git/tree/proposals/282-remove-named-from-consensus.txt 23:21:32 <nickm> after step 1, we'll have to wait till ... 2020 or so until we can do the other steps anyway 23:21:37 <nickm> (2020 is when 0.2.9 hits EOL) 23:22:13 <nickm> #action revise prop#245 to make it clear that optional-tap is a good on its own, even if we don't do complete removal. 23:22:39 <teor4> because it makes descriptors smaller? 23:22:54 <nickm> and it makes the minimal implementation of a tor relay smaller 23:22:56 <isis> i was expecting underwater space station-esque sea labs in 2020, instead i got 0.2.9 deprecation 23:24:03 <teor4> last time we talked about upgrading from TAP to ntor, we decided it was a bug and fixed it 23:24:03 <nickm> I wonder if we should remove the parts of prop245 that refer to opportunistically upgrading connections to ntor. We had support for that, but removed it because it was a fingerprinting opportunity 23:24:22 <nickm> teor4: sorry, decided what was a bug? 23:24:33 <teor4> you explained it better than I did 23:24:44 <isis> i don't quite get the fingerprinting opportunity? 23:24:50 <teor4> automatically upgrading from TAP to ntor 23:25:09 <isis> oh, i see 23:25:18 <teor4> isis: I run a relay that flips in and out of the consensus every hour, and use it as a rend point 23:25:22 <nickm> I think we could do it safely, but only if we do it on a switch-based thing... 23:25:30 <nickm> oh. 23:25:34 <nickm> there's that attack too 23:26:15 <teor4> which becomes more serious if we make clients use stale consensuses for loner 23:26:18 <teor4> *longer 23:26:45 <nickm> so shall we just remove those parts from the proposal? 23:26:47 <nickm> might be smart... 23:26:49 <teor4> yes 23:27:13 <isis> oh, that is a rather serious attack, since each time you do it you can further partition anonymity sets 23:27:36 <isis> #action remove §4 23:27:55 <teor4> yes, ~21 partitions for a unique client, or ~5 for a unique consensus 23:29:02 <isis> and then as nickm mentioned, we can't do anything about step 2 until 2020, so it sounds like we're in agreement what to do for step 1, and nothing can be done further for now 23:29:20 <isis> so we're done talking about prop#245? any other concerns? 23:29:46 <nickm> concern 1: how do we even test this? :) 23:30:01 <nickm> We should at least add a testing section, so that we can verify that it actually works before 2020 23:30:16 <nickm> because if we find out then that we have a bug, we won't be able to go back in time and fix it 23:30:22 <teor4> step 1 is worded badly, we need to update the parsing algorithm on clients, too 23:30:31 <nickm> yes 23:30:50 <isis> the test network? everything there should be ≥0.3.2.9 23:31:04 <nickm> but we'll need a way to generate mds and consensuses without onion-keys 23:31:04 <teor4> #action revise step 1 to upgrade the parsing algorithm on clients as well 23:31:15 <nickm> otherwise we won't be able to test there 23:31:20 <nickm> #action write a section about testing. 23:31:21 <teor4> chutney and a consensus parameter 23:31:40 <teor4> which means we need to implement the whole thing, but only turn on parts of it 23:32:04 <nickm> sound about right 23:32:27 <teor4> and then add chutney networks for each stage 23:32:30 <isis> so a compile time `#ifdef USE_TAP`? 23:33:00 <nickm> not sure 23:33:03 <isis> or just a config option? 23:33:14 <teor4> consensus parameter? 23:33:35 <nickm> maybe an authority option to accept tap-less descriptors, and a consensus parameter to tell relays they have to have them? 23:33:51 <nickm> or 23:34:03 <teor4> oh yes, race conditions 23:34:09 <nickm> maybe an authority option to accept tap-less descriptors, and a testing-only config option to turn them off on relays 23:35:13 <teor4> if we made it a consensus parameter, we could turn off TAP across the whole network once 0.2.9 is obsolete 23:35:26 <isis> the authority option would be fine for chutney, but make it harder to test in the testnet 23:35:28 <teor4> which would be nice 23:36:18 <nickm> btw, there are ... weirder alternative to this proposal we could do. 23:36:52 <nickm> like replacing the TAP keys with something very compressible, and not actually an RSA key 23:37:22 <nickm> but that's probably too clever 23:37:53 <isis> what benefit would we get from that versus just omitting the onion-key body? 23:38:24 <teor4> it would be faster? 23:38:29 <isis> to catch buggy implementations that try to use the compressible thing as an RSA key? 23:38:30 <nickm> no 23:38:40 <nickm> it wouldn't break existing clients 23:38:52 <nickm> or rather, it would only break them as they used TAP 23:39:49 <nickm> (anyway, this would be hard, since we enforce e=65537, so we can't just do e=0 in the keys.) 23:40:31 <isis> i feel like it might be better to break on parsing, than on trying to use "onion-key this-is-not-an-rsa-key" as an RSA key? 23:40:53 <nickm> the idea would be not to break on it -- only to pick a key that would produce an undecryptable output 23:41:08 <nickm> still, this is probably a bad idea 23:41:11 <isis> do we require that all implementations have e=65537? 23:41:14 <nickm> yes 23:41:19 <isis> hmm 23:41:27 <isis> not sure about this idea 23:41:41 <nickm> I am pretty sure it's a bad one. Let's forget about it and move to the next proposal? :) 23:41:49 <isis> ok :) 23:41:59 <isis> so, to summarise prop#282: 23:42:19 <teor4> that's pretty much it 23:42:35 <nickm> there needs to be a transition period with a consensus method, but yeah. 23:42:48 <isis> yep 23:43:00 <isis> new consensus method, no more flags 23:43:07 <isis> boom done 23:43:09 <nickm> no more special handling for them, that is 23:43:30 <isis> like "just ignore them if you see them" was my interpretation 23:43:38 <nickm> oh 23:43:43 <nickm> I meant, "treat them like any other flag" 23:43:49 <nickm> right now they get special-cased rulse 23:43:51 <nickm> *rules 23:44:02 <teor4> Good task for someone who wants to learn more about consensus methods 23:44:12 <nickm> ignoring them during voting would also be a special-case, since by default all flags are handled the same 23:44:20 <nickm> including ones that an authority doesn't recognize 23:45:05 <isis> and this would just handle them as if they were unrecognised? 23:45:20 <nickm> right 23:45:39 <isis> ok, that sounds simple 23:46:08 <nickm> see dirspec line 2638 for the current behavior 23:46:13 <teor4> but we still keep the code in Tor, so we can support consensus methods 14-2x 23:46:22 <nickm> until we can finally throw them out 23:46:39 <teor4> is that something we should discuss now? 23:47:02 <isis> #action after changes to prop#245, make a "Ticket:" field and put it in "State: Accepted" with a note that we're doing step 1 in 0.3.4 23:47:09 <teor4> we have about 10 spare methods we support but will likely never use 23:47:13 <nickm> I don't think we currently have a plan of when exactly to remove old consensus methods. 23:47:27 <nickm> we should probably have such a plan, just so we don't have to re-discuss it every time it comes up. 23:48:01 <teor4> it seems to me that once we deprecate 0.2.5, we should remove the methods that 0.2.9 and up all support 23:48:27 <nickm> So the policy would be "all consensus methods that our oldest LTS supports should be supported"? 23:48:32 <nickm> that's fine with me 23:48:39 <nickm> or rather 23:48:40 <nickm> no 23:48:44 <nickm> that's not what you meant 23:49:12 <nickm> how about "all methods older then the highest method supported by our oldest LTS should be deprecated?" 23:49:17 <nickm> is that closer to what you meant? 23:49:19 <teor4> yes 23:49:29 <nickm> ok. 23:49:47 <nickm> #action write a proposal to declare our consensus method deprecation plan. 23:49:54 <teor4> let's be more specific: the earliest stable release of our LTS. 23:50:08 <nickm> of our oldest supported LTS 23:50:12 <teor4> because we added methods in multiple 029 alphas 23:50:21 <nickm> what's the rationale here? 23:50:31 <teor4> getting rid of old code 23:50:38 <nickm> I can understand the argument "you should be able to run an authority on latest stable LTS" 23:50:58 <teor4> that works for me 23:51:15 <teor4> but we only promise that public authorities should be able to run the latest two releases 23:51:17 <nickm> I don't see why we should make it possible to run an authority on e.g. 0.2.9.8 23:51:26 <teor4> you are correct 23:52:19 <nickm> so in theory now under this policy we could kill off everything before 18 23:52:40 <nickm> and once 025 is deprecated, we'd kill off everything before 25 23:53:05 <isis> that sounds great 23:53:17 <teor4> nickm: is there some reason we should keep a few older methods around, in case the newest one breaks? 23:53:50 <nickm> I think that's a reason for why we should support a few authority versions... 23:54:20 <teor4> fair enough 23:54:35 <nickm> The primary reason to keep older consensus methods around is to give authorities time to upgrade 23:56:10 <isis> so we should keep the consensus methods of the latest three releases? 23:56:57 <teor4> I think our LTS policy guarantees that we will have at least 3 supported releases: LTS, oldstable, and stable 23:57:46 <nickm> yeah. in practice, there will sometimes be multiple oldstable or multiple LTS, though, like there are now 23:58:00 <teor4> authorities are generally spread across alpha, stable, and oldstable 23:58:22 <teor4> and occasionally some are on oldoldstable, but our deprecation policy seems to be moving them on promptly 23:58:46 <nickm> so method 25 is supported in 029 23:58:52 <nickm> method 26 is supported in 031 23:59:03 <nickm> method 28 is the latest 23:59:12 <nickm> I'd be fine killing off everything before 25 23:59:32 <teor4> 27 & 28 are in 033 23:59:44 <teor4> and we plan at least one method for 034 00:00:48 <nickm> it would be sad if we said "no more authorities on 031". Probably also a little sad if we said "no more authorities on 029" 00:01:30 <nickm> since the benefit here is just code removal and spec simplification, though, I think it's okay for us to go slow 00:01:32 <teor4> ok, let's make a ticket for removing 14-24 00:01:51 <teor4> that's a lot of code 00:01:57 <nickm> #action make a proposal for removing old consensus methods in general 00:02:25 <nickm> #action make a ticket for removing methods up through 24ish 00:02:30 <isis> that's going to be awesome, that'll kill so much code 00:03:01 <isis> #action add the ticket to the "Ticket:" field! (this is now required :) 00:03:27 <isis> or, i guess, it is once the proposal is accepted :) 00:03:59 <isis> what is the next LTS going to be? 00:04:16 <nickm> unclear. probably "whatever debian is going to ship" 00:04:24 <isis> joy 00:05:59 <isis> okay, so just to reiterate: the plan for the new proposal is to deprecate all consensus methods older than what the latest LTS, oldstable, stable, and alpha require? 00:06:30 <nickm> yeah, which should be the same as just deprecating everything older than what the latest LTS requires. 00:06:35 <nickm> I'll write up a quick proposal now 00:06:40 <isis> and later we might change that to "oldstable, stable, and alpha" 00:06:54 <isis> cool 00:07:09 <nickm> yeah but TBH I think that main benefit of having a policy here will be that we don't need to have this discussion every 6 months :) 00:07:22 <isis> okay, any more concerns with prop#282? 00:07:42 <isis> nickm: yeah, we seem to have "can we deprecate X yet" discussions a lot 00:08:29 <teor4> the release deprecation policy works 00:09:22 <nickm> yeah 00:09:34 <nickm> I bet this will work nicely too 00:09:54 <isis> #action put prop#282 in "Status: Accepted" and give it a "Ticket:" field 00:10:25 <isis> cool 00:10:30 <isis> okay 00:10:37 <isis> i am going to call endmeeting 00:10:43 <nickm> yay 00:10:44 <isis> going once 00:10:44 <nickm> thanks again! 00:10:47 <isis> going twice 00:10:54 <isis> thanks both of you! 00:11:01 <isis> #endmeeting