December 2017 - tor-commits - lists.torproject.org

[torspec/master] prop#249: Add note on padding being randomness or zeroes.
by isis＠torproject.org 14 Dec '17

14 Dec '17

commit 03a9d4f13431f6f09b3d8c26c6b01dcbaf9685ae Author: Isis Lovecruft <isis(a)torproject.org> Date: Wed Dec 13 23:50:29 2017 +0000 prop#249: Add note on padding being randomness or zeroes. --- proposals/249-large-create-cells.txt | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/proposals/249-large-create-cells.txt b/proposals/249-large-create-cells.txt index b7505c6..b1967f3 100644 --- a/proposals/249-large-create-cells.txt +++ b/proposals/249-large-create-cells.txt @@ -46,11 +46,11 @@ Status: Open }; The 'ignored' fields, which extend to the end of the variable-length - cells, are reserved. Initiators MAY set them to any length, but MUST - fill them with zero-valued bytes. Responders MUST ignore them, - regardless of what they contain. When a CREATE2V cell is generated - in response to a set of EXTEND2 cells, these fields are set by the - relay that receives the EXTEND2 cells. + cells, are reserved. Initiators MAY set them to any length, and MUST + fill them with either zero-valued bytes or pseudo-random bytes. + Responders MUST ignore them, regardless of what they contain. When a + CREATE2V cell is generated in response to a set of EXTEND2 cells, these + fields are set by the relay that receives the EXTEND2 cells. (The purpose of the 'ignored' fields here is future-proofing and padding.)

1 0

[torspec/master] Add Ticket: field for prop#140.
by isis＠torproject.org 14 Dec '17

14 Dec '17

commit ca22bb0f496f8984234aa1d2061f271d018bae7d Author: Isis Lovecruft <isis(a)torproject.org> Date: Wed Dec 13 23:49:33 2017 +0000 Add Ticket: field for prop#140. --- proposals/140-consensus-diffs.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/proposals/140-consensus-diffs.txt b/proposals/140-consensus-diffs.txt index 7793f84..c50aba0 100644 --- a/proposals/140-consensus-diffs.txt +++ b/proposals/140-consensus-diffs.txt @@ -4,6 +4,7 @@ Author: Peter Palfrader Created: 13-Jun-2008 Implemented-In: 0.3.1.1-alpha Status: Closed +Ticket: https://bugs.torproject.org/13339 0. History

1 0

[torspec/master] prop#249: Add recommendation on equal number of cells in each direction.
by isis＠torproject.org 14 Dec '17

14 Dec '17

commit 21e79aec731e068c0ba92c50f5fa5d3f5132b003 Author: Isis Lovecruft <isis(a)torproject.org> Date: Wed Dec 13 23:51:21 2017 +0000 prop#249: Add recommendation on equal number of cells in each direction. --- proposals/249-large-create-cells.txt | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/proposals/249-large-create-cells.txt b/proposals/249-large-create-cells.txt index b1967f3..c08b596 100644 --- a/proposals/249-large-create-cells.txt +++ b/proposals/249-large-create-cells.txt @@ -77,6 +77,14 @@ Status: Open If any intervening cells are received, the receiver SHOULD destroy the circuit. + Protocols which make use of CREATE(D)2V cells SHOULD send an equal number + of cells in either direction, to avoid trivially disclosing information + about the direction of the circuit: for example a relay might use the + fact that it saw five EXTEND2 cells in one direction and three in the + other to easily determine whether it is the middle relay on the onion + service-side or the middle relay on the client-side of a rendezvous + circuit. + 4. Interacting with RELAY_EARLY cells The first EXTEND2 cell in a batch must arrive in a RELAY_EARLY cell.

1 0

[torspec/master] Typo fixes in prop#249, prop#276, and prop#279.
by isis＠torproject.org 14 Dec '17

14 Dec '17

commit 686aaf110551c6d586f069e3ae6f8be6820bce8d Author: Isis Lovecruft <isis(a)torproject.org> Date: Wed Dec 13 23:52:15 2017 +0000 Typo fixes in prop#249, prop#276, and prop#279. --- proposals/249-large-create-cells.txt | 2 +- proposals/276-lower-bw-granularity.txt | 2 +- proposals/279-naming-layer-api.txt | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/proposals/249-large-create-cells.txt b/proposals/249-large-create-cells.txt index c08b596..54516be 100644 --- a/proposals/249-large-create-cells.txt +++ b/proposals/249-large-create-cells.txt @@ -146,7 +146,7 @@ Status: Open before it's needed, we can use the new handshake types whenever both of the involved relays support this proposal. - Clients MUST NOT sent fragmented EXTEND2 cells to relays that don't + Clients MUST NOT send fragmented EXTEND2 cells to relays that don't support them, since this would cause them to close the circuit. Relays MAY send CREATE2V and CREATED2V cells to relays that don't diff --git a/proposals/276-lower-bw-granularity.txt b/proposals/276-lower-bw-granularity.txt index bca544b..021aed8 100644 --- a/proposals/276-lower-bw-granularity.txt +++ b/proposals/276-lower-bw-granularity.txt @@ -69,6 +69,6 @@ Target: 0.3.1.x-alpha results? Is there any reason to think this amount of smoothing would not - be save? + be safe? Would a time-aware smoothing mechanism work better? diff --git a/proposals/279-naming-layer-api.txt b/proposals/279-naming-layer-api.txt index 9f8c104..13cbcbc 100644 --- a/proposals/279-naming-layer-api.txt +++ b/proposals/279-naming-layer-api.txt @@ -53,7 +53,7 @@ Status: Draft idnxcnkne4qt76tg.onion vwakviie2ienjx6t.onion - When Proposal 224 get deployed, onion addresses will become even + When Proposal 224 gets deployed, onion addresses will become even bigger: 53 base32 characters. That's: llamanymityx4fi3l6x2gyzmtmgxjyqyorj9qsb5r543izcwymle.onion

1 0

[torspec/master] prop#249: Add note about interaction with OOM manager.
by isis＠torproject.org 14 Dec '17

14 Dec '17

commit bbb7f092a0c0bcf821c30dfc01493d0887c926ae Author: Isis Lovecruft <isis(a)torproject.org> Date: Thu Dec 14 00:08:30 2017 +0000 prop#249: Add note about interaction with OOM manager. --- proposals/249-large-create-cells.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/proposals/249-large-create-cells.txt b/proposals/249-large-create-cells.txt index 887001a..cbdc436 100644 --- a/proposals/249-large-create-cells.txt +++ b/proposals/249-large-create-cells.txt @@ -165,6 +165,9 @@ Status: Open the buffers allocated for this data need to be counted against the total data usage of the circuit. + Further, circuits which receive and buffer CREATE(D)2V cells MUST store + the time the first buffer chunk was allocated, and use it to inform the + OOM manager w.r.t. the amount of data used and its staleness. Appendix A. A rejected idea for migration

1 0

[torspec/master] prop#249: Add example of how to avoid exhausting RELAY_EARLY cells.
by isis＠torproject.org 14 Dec '17

14 Dec '17

commit d3f18989ce583a348d3e525e8abee314f18fe91e Author: Isis Lovecruft <isis(a)torproject.org> Date: Wed Dec 13 23:56:25 2017 +0000 prop#249: Add example of how to avoid exhausting RELAY_EARLY cells. --- proposals/249-large-create-cells.txt | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/proposals/249-large-create-cells.txt b/proposals/249-large-create-cells.txt index 54516be..887001a 100644 --- a/proposals/249-large-create-cells.txt +++ b/proposals/249-large-create-cells.txt @@ -88,7 +88,12 @@ Status: Open 4. Interacting with RELAY_EARLY cells The first EXTEND2 cell in a batch must arrive in a RELAY_EARLY cell. - The others MAY arrive in RELAY_EARLY cells. + The others MAY arrive in RELAY_EARLY cells. For many handshakes, for + the possible lengths of many types of circuits, sending all EXTEND2 cells + inside RELAY_EARLY cells will not be possible. For example, for a + fragmented EXTEND2 cell with parts A B C D E, A is the only fragment that + MUST be sent within a RELAY_EARLY. For parts B C D E, these are merely + sent as EXTEND2{CREATE2V} cells. Note that this change leaks the size of the handshake being used to intermediate relays. We should analyze this and see whether it matters.

1 0

[torspec/master] prop#249: Add myself as an author so I get blamed for anything dumb.
by isis＠torproject.org 14 Dec '17

14 Dec '17

commit 5fe5456988900b01eb86bd03b1224b4f5cd018fe Author: Isis Lovecruft <isis(a)torproject.org> Date: Thu Dec 14 01:24:17 2017 +0000 prop#249: Add myself as an author so I get blamed for anything dumb. --- proposals/249-large-create-cells.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/proposals/249-large-create-cells.txt b/proposals/249-large-create-cells.txt index d4b2e2c..3e687de 100644 --- a/proposals/249-large-create-cells.txt +++ b/proposals/249-large-create-cells.txt @@ -1,7 +1,8 @@ Filename: 249-large-create-cells.txt Title: Allow CREATE cells with >505 bytes of handshake data -Authors: Nick Mathewson +Authors: Nick Mathewson, Isis Lovecruft Created: 23 July 15 +Updated: 13 December 2017 Status: Open 1. Summary

1 0

[torspec/master] prop#249: Add section on new consensus parameters.
by isis＠torproject.org 14 Dec '17

14 Dec '17

commit c119bd7800b1489aa178da7c5c2b1dfdc323ff27 Author: Isis Lovecruft <isis(a)torproject.org> Date: Thu Dec 14 01:23:52 2017 +0000 prop#249: Add section on new consensus parameters. --- proposals/249-large-create-cells.txt | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/proposals/249-large-create-cells.txt b/proposals/249-large-create-cells.txt index 068ec90..d4b2e2c 100644 --- a/proposals/249-large-create-cells.txt +++ b/proposals/249-large-create-cells.txt @@ -230,6 +230,14 @@ Status: Open required-client-protocols […] Link=4-5 Relay=2-3 Handshake=1-2 required-relay-protocols […] Link=3-5 Relay=1-3 Handshake=1-2 +6.2. New Consensus Parameters + + We introduce the following new consensus parameters: + + Create2VMaximumData SP int + The maximum amount of "hlen" data, in bytes, which may carried in + either direction within a set of CREATE(D)2V cells. (default: 10240) + 7. Resource management issues This feature requires relays and clients to buffer EXTEND2 cell

1 0

[torspec/master] prop#249: Add link specifiers and a section on new subprotocol numbers.
by isis＠torproject.org 14 Dec '17

14 Dec '17

commit 7af62db0b06aac937b8f349bd667ad20a9776f79 Author: Isis Lovecruft <isis(a)torproject.org> Date: Thu Dec 14 00:51:52 2017 +0000 prop#249: Add link specifiers and a section on new subprotocol numbers. --- proposals/249-large-create-cells.txt | 63 ++++++++++++++++++++++++++++++++++-- 1 file changed, 61 insertions(+), 2 deletions(-) diff --git a/proposals/249-large-create-cells.txt b/proposals/249-large-create-cells.txt index cbdc436..072cffa 100644 --- a/proposals/249-large-create-cells.txt +++ b/proposals/249-large-create-cells.txt @@ -110,8 +110,12 @@ Status: Open EXTEND2 { nspec = 2; - { node ID for Y, taking 22 bytes. } - { node address for Y, taking 8 bytes } + lstype = [0x01 || 0x02]; (IPv4 or IPv6 node address) + lslen = [0x04 || 0x16]; + lspec = { node address for Y, taking 8 bytes or 16 bytes}; + lstype = 0x03; (An ed25519 node identity) + lslen = 32; + lspen = { ed25519 node ID for Y, taking 32 bytes } htype = {whatever the handshake type is.} hlen = 2000 hdata = { the first 462 bytes of the handshake } @@ -157,6 +161,61 @@ Status: Open Relays MAY send CREATE2V and CREATED2V cells to relays that don't support them, since unrecognized cell types are ignored. +6.1. New Subprotocols and Subprotocol Versions + + This proposal introduces, following prop#264, the following new + subprotocol numbers and their uses. + +6.1.1. Relay Subprotocol + + "Relay 3" -- The OP supports all of "Relay 2", plus support for CREATE2V + and CREATED2V cells and their above specification for link-layer + authentication specifiers. + +6.1.2. Link Subprotocol + + "Link 5": The OP supports all of "Link 1-4", plus support for the new + EXTEND2 semantics. Namely, it understands that an EXTEND2 cell whose + "hlen" field is greater than 505 will be followed by further "hdata" + in fragmented EXTEND2 cells which MUST follow. It also understands + that the following combination of EXTEND2 payload specifiers + indicates that the cell is a continuation of the earlier payload + portions: + + nspec = 0; + htype = 0xffff; + hlen = 0; + +6.1.3. Handshake Subprotocol + + Additionally, we introduce a new subprotocol, "Handshake" and the + following number assignments for previously occuring instances: + + "Handshake 1" -- The OP supports the TAP handshake. + + "Handshake 2" -- The OP supports the ntor handshake. + + We also reserve the following assignments for future use: + + "Handshake 3" -- The OP supports the "hybrid+null" ntor-like handshake + from prop#269. + + "Handshake 4" -- The OP supports a(n as yet unspecified) post-quantum + secure hybrid handshake, that is, the "hybrid+null" handshake from + "Handshake 3", except with "null" part replaced with another (as yet + unspecified) protocol to be composed with the ntor-like ECDH-based + handshake. + + Further handshakes MUST be specified with "Handshake" subprotocol + numbers, and MUST NOT be specified with "Relay" subprotocol numbers. The + "Relay" subprotocol SHALL be used in the future to denote changes to + handshake protocol handling of CREATE* and EXTEND* cells, i.e. CREATE, + CREATED, CREATE_FAST, CREATED_FAST, CREATE2, CREATED2, CREATE2V, + CREATED2V, EXTEND, EXTENDED, EXTEND2, and EXTENDED2. + + Thus, "Handshake 1" is taken to be synonymous with "Relay 1", and + likewise "Handshake 2" is with "Relay 2". + 7. Resource management issues This feature requires relays and clients to buffer EXTEND2 cell

1 0

[torspec/master] prop#249: Add section on updates to required/recommended subprotocols.
by isis＠torproject.org 14 Dec '17

14 Dec '17

commit 3578da4f1fa02b145c2d55480089a49b60346eab Author: Isis Lovecruft <isis(a)torproject.org> Date: Thu Dec 14 01:23:16 2017 +0000 prop#249: Add section on updates to required/recommended subprotocols. --- proposals/249-large-create-cells.txt | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/proposals/249-large-create-cells.txt b/proposals/249-large-create-cells.txt index 83e15f8..068ec90 100644 --- a/proposals/249-large-create-cells.txt +++ b/proposals/249-large-create-cells.txt @@ -220,6 +220,16 @@ Status: Open Thus, "Handshake 1" is taken to be synonymous with "Relay 1", and likewise "Handshake 2" is with "Relay 2". +6.2. Subprotocol Recommendations + + After the subprotocol additions above, we change to recommending the + following in the consensus: + + recommended-client-protocols […] Link=5 Relay=3 Handshake=2 + recommended-relay-protocols […] Link=5 Relay=3 Handshake=2 + required-client-protocols […] Link=4-5 Relay=2-3 Handshake=1-2 + required-relay-protocols […] Link=3-5 Relay=1-3 Handshake=1-2 + 7. Resource management issues This feature requires relays and clients to buffer EXTEND2 cell

1 0