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