22:03:06 #startmeeting 22:03:06 Meeting started Wed Dec 13 22:03:06 2017 UTC. The chair is isis. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:03:06 Useful Commands: #action #agreed #help #info #idea #link #topic. 22:03:14 whooo 22:03:28 here's the pad https://pad.riseup.net/p/bYpKp32VlXW8 22:05:13 okay, so i summarised the proposal in the email https://lists.torproject.org/pipermail/tor-dev/2017-December/012665.html 22:05:25 so i think we can skip that part 22:05:45 no objection here 22:06:21 the first topic is whether we think we should attempt to obfuscate the directions for rendezvous circuits, to the non-rend nodes 22:06:43 directions? 22:07:20 So normally relays know which side of the circuit is outgoing, and which is incoming 22:07:29 Because they handled an extend on it 22:07:29 teor's question about padding to a certain multiple of cells 22:07:31 Right. That's always true in fact 22:07:50 the side which told them to create the circuit is the inward side 22:08:03 But not for client to onion service handshakes, because of how the rend point joins the ends of two circuitsa 22:08:21 ah 22:08:33 So, for example, if you're a middle, and you see 5 cells go one way, and 3 come back 22:08:51 And you compare that to your own idea of the direction of the circuit 22:09:03 so the idea is that some node N in on a rend circuit and doesn't know whether it's a midpoint for a client or a midpoint for a service? 22:09:14 Yes 22:09:31 A middle or perhaps a guard (guards have other ways of guessing) 22:09:46 I'm thinking that they can probably tell anyway from other timing info, but it might be good to have support for this kind of padding. 22:10:05 I'm not sure that this actually improves security 22:10:07 what do others think? 22:10:58 they can still probably discover these things, but it seems maybe bad to just hand them the info via the handshakes 22:11:29 for right now, i think our handshakes coincidentally hav ethe same number of cells in each direction, but not the same number of bytes 22:11:35 *proposed handshakes 22:11:35 nickm: I hear that there's a paper coming out about middle node attacks, but it requires machine learning and is hard to do at network speed: https://onionpop.github.io/ 22:12:47 so maybe we should recommend that handshakes have equal cells in both directions, and be done with it? 22:12:51 that would be okay with me 22:12:52 Yes 22:13:00 +1 22:13:12 ok, that was easy 22:13:15 we don't have to enforce it in the protocol level if someday we need to not do so. 22:14:05 i'll put it in the spec? as a "SHOULD" in prop#249 22:14:11 yeah 22:14:19 what's next? 22:14:22 ok, next 22:14:22 next question: Did I get the RELAY_EARLY thing wrong? 22:14:32 I think you misunderstand the relay_early design here 22:14:44 i'm not sure, i always get very confused about relay_early 22:14:47 look at section 4 22:14:50 https://gitweb.torproject.org/torspec.git/tree/proposals/249-large-create-cells.txt#n80 22:14:57 "The first EXTEND2 cell in a batch must arrive in a RELAY_EARLY cell. 22:14:58 The others MAY arrive in RELAY_EARLY cells." 22:15:27 This leaks information, yes. But it doesn't put an upper limit on handshake size 22:15:32 aha, so it's permitted to use one RELAY_EARLY per hop? 22:15:50 Realistically, I think we leak handshake size anyway, because we're not going to delay parts of the handshake 22:15:55 Right. So if you have to send 5 fragments A B C D E, only A has to be in a relay_early cell 22:15:59 with other EXTEND2 cells in between 22:15:59 right 22:16:48 so no problem yet, cool 22:16:51 Well, that makes things earier 22:16:56 *easier 22:16:59 yup :) 22:17:13 do we have anything that might use more than 8 hops yet? 22:17:30 isis: failed client intros 22:17:36 like a bridge (with a bridgeguard) going to a rendezvous? 22:17:55 failed client intros re-extend to the next intro point 22:17:55 nothing remotely reasonable... 22:18:09 hmm 22:18:10 and for the rendezvous case, the two halves of the connection count separately 22:18:13 So if your circuit is 3 hops, and you add 6 intros, that's 9 22:18:26 right, but then you should stop and use a new circuit :) 22:18:36 oh, it just keeps re-extending, that's super funky 22:18:52 nickm: which is probably wise, just in case the first intro is nasty 22:19:09 isis: try keeping stats on that :-) 22:19:29 ok, well, at least it's not going to be an issue with larger handshakes :) 22:20:12 Even in the vanguard / bridge guard case, I think we're ok (bridge, bridge guard added by bridge, middle, middle, middle, rend) 22:20:19 nickm: yay, thanks for noting things down on the pad! 22:20:32 you're welcome! 22:20:42 all: Please correct the pad if I note anything wrong or incompletely 22:21:05 next question: how will this interact with our OOM handler? 22:21:45 (i have never looked at the OOM handler) 22:22:07 let's do isis's questions before mine? 22:22:11 I think they're more fundamental 22:22:15 ok sure 22:22:56 i think my question #1 about bytes is already anwered? 22:23:05 Yes. Cells implies bytes. 22:23:17 oh, the cells are variable length 22:23:23 you don't have to pad them 22:23:31 you don't have to, but we could 22:23:41 ** Resolution: Say that handshakes SHOULD have the same number of bytes in each direction. 22:23:50 err, that's not what we said before 22:23:58 I know :-) 22:24:12 oh 22:24:16 do you mean that fwd==back? 22:24:29 or that handshake type A always sends X bytes fwd and Y bytes back? 22:24:38 I think that second one should be a requirement at least 22:24:57 there should be no variable-length handshakes IMO 22:25:16 for prop#270, i think there's 1792 bytes in one direction (plus some overhead for cell header stuff) and 2048 (plus overhead) in the server -> client direction 22:25:51 and i was wondering if we should pad both to 2048 for any reason (and require/recommend other handshakes to do so as well) 22:25:54 perhaps we should have a consensus parameter saying that create2v cells SHOULD always be padded to some length? 22:27:13 That would give us some nice hiding properties from outside the encryption 22:27:18 or we could say that CREATE(D)2V cells should always be padded to a multiple of some length 22:27:58 also, does anything prevent a client from sending a RELAY_EARLY> [~500 bytes] and then a bunch of EXTEND2 [~0 bytes] forever and ever? 22:28:13 I think that's your question 5 22:28:22 I think the answer for that should be: 22:28:29 oh right 22:28:31 "Let's have a consensus parameter for that" 22:30:06 what if we just got rid of the variable length padding and said "cells, if they aren't the maximum number of bytes, must be padded with zeros" 22:30:21 hm 22:30:36 I'm thinking that the padding rule and the maxmimum rule could be different here 22:30:57 not sure though 22:31:18 is the point to allow someday, if we don't care, to save a couple hundred bytes? 22:31:33 (just trying to think about ease of parser implementations) 22:31:35 yeah 22:32:17 and variable length packet-y thingies have a tendency to cause vulns in other protocols and packet parser things 22:32:31 that's true :/ 22:32:33 well, our protocol already has them 22:32:43 true 22:33:30 for example where? 22:33:33 having hlen field in these cells _does_ increase the likelihood of an attack where somebody sets hlen to greater than the length of the cell 22:33:52 Samdney: VERSION cells are variable-length; so, I believe, are several others used during the handshake 22:34:01 CERTS 22:34:09 the protocol specifies that all cells with 'command' >= 128 are variable-length, IIRC 22:35:02 to continue my earlier thought about the hlen attack, though: 22:35:20 tor cell parsers should really be machine-generated, I think we've decided 22:36:22 i've never used trunnel… how difficult would it be if i just write this up with a consensus parameter for Create2VMaxTotalLength and Create2VMultipleLength to change that later? 22:36:35 trivial 22:36:43 ok cool 22:36:59 (you'd probably impose that before the trunnel parsing though) 22:37:42 * nickm has to disappear in ~22 min 22:37:45 then we can just have consensus parameters for now, and if we decide to change it they can become hardcoded 22:38:09 do we want randomised padding? 22:38:38 i remember i think teor had concerns about this in other cells 22:38:40 I don't think so-- not if we believe that TLS is secure 22:38:46 for these i'm not sure it matters 22:38:57 teor, your thoughts here? 22:39:48 I don't think it matters, and it's more of a pain to extend the format later 22:39:50 since you'll be able to see some structure to the lattice coefficients being sent back and forth anyway (e.g. they all decode to ints in ZZ/12889) 22:40:16 sure but assuming a weakness in aes-ctr, "all 0s" would be easier to exploit than that. 22:40:49 (I started asking because of the spec, not because of any specific security concerns) 22:40:56 but I don't think this is something we can deal with currently, so I agree it doesn't matter 22:41:10 ack 22:41:24 okay, let's delay that one 22:41:31 It might make sense to randomize the codas of relay cells; but less so for one-hop cells 22:41:53 q3 is about a UDP transport type thing? 22:41:58 yes 22:42:19 like we're extremely putting another hard requirement on TCP ordering the fragmented cells 22:42:29 if so I suggest we also table that-- building Tor on UDP would require so much rearchitecting and redesign that I think we shouldn't really plan for it 22:42:46 or, we shouldn't try to future-proof our current designs against it 22:42:47 We already require ordering for the link handshakes etc. 22:42:55 ack 22:43:15 ~/win 2 22:43:31 ( :( sorry) 22:43:34 np 22:43:42 sorry for logging your /win on meetbot! 22:44:07 whoever has to come up with a design for UDP someday is going to hate me, please forgive me, future hacker 22:44:17 aw, they'll hate all of us 22:44:18 (now everyone knows I may hav more than 1 win!) 22:44:21 it'll be fine 22:44:28 sysrqb: and this one isn't #2! 22:44:32 sysrqb: *gasp* 22:44:40 :) 22:44:43 uh oh :( 22:44:52 :) 22:45:05 * sysrqb goes back to lurking 22:45:09 next q? 22:45:18 versions! 22:45:18 okay, do we want a more protocol-level way to do handshake composability? 22:45:26 (slash versioning) 22:45:33 i'm thinking no? 22:45:52 that is, if we wanted to, we could define a handshake type that encapsulated two handshakes and combined their results with this anyway... 22:46:04 This seems like an invitation to conduct protocol downgrade attacks 22:46:12 but it seems to me that's the kind of bad mix-and-match that happened with pre-1.3 TLS, and that it leads to The Wrong Kind Of Fun 22:46:27 yeah, let's scrap it 22:46:33 so nothing in this proposal prevents us from having that Kind Of Fun down the road... 22:46:37 but let's not build it in now 22:46:57 we'll just continue number stuff like "ECDH+SIDH is handshake type 42" 22:47:20 nickm: you make it sound so much like Dwarf Fortress Fun :) 22:47:32 that's kind of what I had in mind 22:47:46 on to nickm's questions? 22:47:50 Yes 22:48:02 ok 22:48:23 nickm: can you explain the gap between the proposal and the OOM handler? 22:48:28 first one is the oom handler -- I think that we need to remember when we started gettting a handshake, so that we can count it against circuit data that way too 22:48:41 the oom handler uses two pieces of info, basically: allocation and staleness 22:48:49 and we need to make sure that we explicitly capture both here 22:48:57 no big deal, just something that we need to specify 22:49:11 if we use buf_t to rebuild the CREATE2V cell body, we get this info for free 22:49:34 do we believe that? 22:49:44 so the idea is that, otherwise, a bad client/relay would force someone to hold onto the first 3/4ths of a handshake a bunch of times and OOM them 22:50:13 right 22:50:22 right 22:50:31 with buf_t, is there a field somewhere for storing the time the buffer's first chunk was allocated? 22:51:03 isis: it's the inserted_time field in the chunk_t structure in buf_t 22:51:46 aha, okay 22:52:26 so that would potentially be a nice thing to expose at the CREATE(D)2V level, what time the first chunk was inserted 22:52:49 that sounds easy, but we should probably specify it 22:53:04 *you're right that we should 22:53:34 i agree with no cells between CREATE(D)2V fragments 22:53:36 next q is about the very simple fragmentation logic 22:53:37 yup 22:53:49 i wanted to avoid all the fragmentation problems 22:53:57 unless there's some sort of reasoning for a fast-start-like thing 22:54:13 oh gosh, let's not 22:54:27 or if we need one, let's do it as a separate proposal some day in the distant future after I've retired :) 22:54:42 but it sounds potentially problematic to be buffering what might be a larger handshake than we're used to while also handling other cells 22:55:09 yeah 22:55:15 like a quick way to have Fun 22:55:17 :) 22:55:20 or to buffer multiple handshakes at once 22:55:49 oh hmm 22:56:11 gotta go in 4 min 22:56:26 i think all the handshake should go into the same cells though, like ECDH+RLWE all smashed together however the handshake defines it 22:56:33 ok 22:56:35 nearly done 22:56:39 protocol versions 22:56:47 wrt subprotocols: I think we can get away with one new link version for create*2v, and one new relay version for fragmented extends 22:57:01 i think we only need a new type of "Relay 3" ? 22:57:23 we'll need some way to know if we're talking to somebody who supports create2v, i think 22:57:32 oh, new link version 22:57:51 as for the handshakes, I don't knwo whether to call handshake types suprotocols or not 22:57:53 do we have subprotocol numbers for handshakes? 22:57:54 maybve 22:57:56 *maybe 22:58:00 we don't , but we could start 22:58:19 hmm, we might want to start? 23:00:08 previously, handshake types corresponded 1:1 with key types 23:00:08 I think you're right 23:00:08 there's like a zillion micro-optimisations going on in PQ crypto all the time, and we might want some later 23:00:08 but it would cost us a new wire format 23:00:08 ok, gotta run make dinner 23:00:08 ok, thanks nickm! 23:00:08 thanks for running this! thanks for coming! 23:00:08 thanks teor and Samdney! 23:00:08 please feel free to continue w/o me 23:00:08 teor: Samdney: any additional thoughts/concerns/ideas? 23:00:18 if not, i will endmeeting 23:00:25 not from my side :) 23:00:36 I think we answered all my questions 23:00:44 cool 23:00:48 #endmeeting