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

[isis agora lovecruft]

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?

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.


Best regards,
-- 
 ♥Ⓐ 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/20171209/ed8bd10f/attachment-0001.sig>