Discussion Meeting for Prop#249 "Large CREATE cells"
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-ce... 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
On 9 Dec 2017, at 11:29, isis agora lovecruft <isis@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-ce...
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
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@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-ce...
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@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
On Fri, Dec 8, 2017 at 7:29 PM, isis agora lovecruft <isis@torproject.org> wrote:
Open Questions/Concerns ~~~~~~~~~~~~~~~~~~~~~~~
Let me add a few more: A. How does this interact with our OOM handler? B. Is it really the right choice to allow no intervening cells between the EXTEND fragments? (I say yes, but I'm not sure.) C. This proposal was written before we had subprotocol versions. How many new subprotocol versions, of which types, should we allocate for this?
isis agora lovecruft transcribed 5.3K bytes:
Hello all,
What: A proposal discussion meeting for prop#249 "Allow CREATE cells with >505 bytes of handshake data". [0]
Hey, Meetbot notes are available. [0] Nick and Tim took summary notes of discussion items on the pad [1] which I'll be incorporating into a revised draft of the proposal. Thanks to everyone who participated! [0]: http://meetbot.debian.net/tor-meeting/2017/tor-meeting.2017-12-13-22.03.html [1]: https://pad.riseup.net/p/r.1c4c37baa9251fdfca5a1e1bd5c01f45 -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://fyb.patternsinthevoid.net/isis.txt
participants (3)
-
isis agora lovecruft -
Nick Mathewson -
teor