[tor-dev] Discussion Meeting for Prop#249 "Large CREATE cells"

Tue Dec 12 20:01:34 UTC 2017

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 at torproject.org> 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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

-- 
 ♥Ⓐ isis agora lovecruft
_________________________________________________________
OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35
Current Keys: https://fyb.patternsinthevoid.net/isis.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1240 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20171212/7bed57c5/attachment.sig>