Hi! Next time I should do the poll for the meeting time earlier ahead of time, my apologies. It looks like everyone who wishes to can attend Wednesday, 13 December at 22:00-23:00 UTC. In local times, this is: - Wednesday, 13 December 14:00-15:00 PST - Wednesday, 13 December 17:00-18:00 EST - Wednesday, 13 December 00:00-01:00 CET - Thursday, 14 December 09:00-10:00 AUST teor transcribed 6.8K bytes: > > > On 9 Dec 2017, at 11:29, isis agora lovecruft <isis@xxxxxxxxxxxxxx> wrote: > > > > Hello all, > > > > What: A proposal discussion meeting for prop#249 "Allow CREATE cells with > >> 505 bytes of handshake data". [0] > > > > Who: This proposal is likely of interest to those hoping to integrate newer, > > non-ECC-based, circuit-layer handshakes into the Tor protocol. > > > > When: Next week, on Monday or Tuesday (or Wednesday, for some timezones). > > If you'd like to attend, please vote on a time here: > > https://doodle.com/poll/v924cbt2at3rzvc9 > > > > Where: irc.oftc.net #tor-meeting > > > > [0]: https://gitweb.torproject.org/torspec.git/tree/proposals/249-large-create-cells.txt > > > > Meeting Preparation Materials > > ============================= > > > > The following is meant for attendees to refresh before the meeting. Please > > feel free to respond with further summary and/or open questions/concerns. > > > > Proposal Summary > > ~~~~~~~~~~~~~~~~ > > The proposal outlines two new cell types, CREATE2V and CREATED2V, which are > > variable-length and (like their CREATE2/CREATED2 counterparts) are sent > > encapsulated in EXTEND2 cells. Due to their variable-length, however, if a > > CREATE(D)2V cell's HDATA is larger than the standard allotment of 505 bytes, > > these new cells are fragmented across multiple EXTEND2 cells. > > > > Open Questions/Concerns > > ~~~~~~~~~~~~~~~~~~~~~~~ > > > > 1. Since CREATE2V cells are used for handshakes, and several newer, > > post-quantum primitives have asymmetric payloads for the client versus > > server directions, should we require that the CREATE(D)2V padding be used > > to equalise the number of bytes sent in each direction? > > Should we pad to a certain multiple of cells, to hide which handshake is being > used? > > I think this matters in the onion service case, because it allows > non-rendezvous points to work out the orientation of the client to service > circuit using the handshake. But relays can already do this probabilistically, > using cell response latency. > > But otherwise, I can't see how it matters unless we are trying to hide the > type of handshake: circuit orientation is known by each hop, because they > each know the direction they sent and received EXTENDs in. > > > 2. Should we randomise the bytes in the padding? (Currently, as proposed, > > we require all-zero padding.) > > > > 3. Should we do anything more future-proofed w.r.t. the future possibility > > of using an alternate (non-stateful, e.g. not TCP) transport? > > (Currently, the proposal relies heavily upon the transport-layer to > > provide delivery guarantee and, perhaps more important, ordering.) > > > > 4. Shoule we, for hybrid handshakes (handshakes which use multiple separate > > primitives to derive shared secrets, e.g. ECDH+RLWE or ECDH+SIDH, by > > conducting each handshake separately and composing their respective > > resulting shared secrets), design some mechanism where, if a party only > > supports say the ECDH portion of the hybrid handshake and not the RLWE > > part, then they proceed with the portion they understand? For example, a > > client sends their portion of a ECDH+RLWE handshake to a relay which only > > understands ECDH, so the relay responds with only ECDH and they continue. > > This is mostly a difference in subprotocol versioning for handshakes, > > that is, an ECDH+RLWE handshake, rather than being "handshake type 5" or > > whatever, would be "handshake type 2 AND/OR handshake type 5". > > > > 5. As written, the proposal doesn't specify a maximum (or minimum) size of > > handshake data. However, the max is somewhat limited by the number of > > allowed RELAY_EARLY cells; maximum handshake data is then limited to > > 462+(7*492)=3906 bytes. > > More precisely, assuming all handshakes are the same size, and counting > hops using the number of relays, maximum outbound handshake data is: > * unlimited for the first hop > * limited to 8 cells for the second hop in a two-hop circuit > (bandwidth scanners use two-hop circuits) > * limited to 8/2 = 4 cells for the second and subsequent hops in a > three-hop circuit > * limited to 8/(3,4) = 2 cells for the second and subsequent hops in a four > or five-hop circuit (4 hops can happen with circuit cannibalisation, and > 4 hops is the minimum for onion service client intro or service rend, and > some vanguard circuits. 5-8 hops can happen with onion service client intro > extends) > * limited to 8/(5,6,7,8) = 1 cell for the second and subsequent hops in a six-hop > (or greater) circuit (onion service client intro extends) > > There is no limit on inbound handshake client data. > > Can we invert the client/server directions in any of these handshakes? > (I imagine we can't, if the server declares public key material.) > > Do vanguards every require 5 hops? > Does this proposal mean that we have to limit the number of client intro > extends on the same circuit? > Should we increase the number of RELAY_EARLY cells sent on legacy circuits > to hide these larger handshake sizes? > > T > > > _______________________________________________ > tor-dev mailing list > tor-dev@xxxxxxxxxxxxxxxxxxxx > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://fyb.patternsinthevoid.net/isis.txt
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev