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