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