diff options
| -rw-r--r-- | proposals/340-packed-and-fragmented.md | 45 | ||||
| -rw-r--r-- | spec/cert-spec.md | 2 | ||||
| -rw-r--r-- | spec/param-spec.md | 37 | ||||
| -rw-r--r-- | spec/rend-spec/encrypting-user-data.md | 7 | ||||
| -rw-r--r-- | spec/rend-spec/introduction-protocol.md | 4 |
5 files changed, 91 insertions, 4 deletions
diff --git a/proposals/340-packed-and-fragmented.md b/proposals/340-packed-and-fragmented.md index 2407f99..cd98cfd 100644 --- a/proposals/340-packed-and-fragmented.md +++ b/proposals/340-packed-and-fragmented.md @@ -269,8 +269,23 @@ conflux bundle. ### An exception for `DATA`. -Data messages may not be fragmented. (There is never a reason to do -this.) +Data messages may not be fragmented. When packing data into a cell containing +other messages is desired, the application can instead construct a DATA message +of an appropriate size to fit into the remaining space. + +While relaxing this could simplify the implementation of opportunistic packing +somewhat (by allowing code that constructs `DATA` messages not to have to know +about packing or fragmentation), doing so would have several downsides. + +First, on the receiver side a naive implementation that receives the first cell +of a fragmented `DATA` message would not be able to pass the data in that +fragment on to the application until the remaining cells of that message are +received. An optimized implementation might choose to do so, but that +complexity seems worse than the complexity we'd be avoiding by allowing `DATA` +fragmentation in the first place. + +Second, as with any sort of flexibility permitted to implementations, allowing +flexibility here adds opportunities for fingerprinting and covert channels. ### Extending message-length maxima @@ -286,6 +301,32 @@ Any increase in maximum length for any other message type requires a new EXTEND2 messages to be 2000 bytes long, we need to add a new proposal saying so, and reserving a new subprotocol version.) +### `SENDME` window accounting + +`SENDME` windows count relay *cells* rather than relay *messages*. + +A cell counts towards the circuit's `SENDME` window if it contains any part of +any message that would normally count towards `SENDME` windows (currently only +`DATA`). + +A cell counts towards the `SENDME` window of every stream that it contains +part of a message for, whose command counts towards `SENDME` windows. + +Examples: + +* A cell containing a `SENDME` message and a `RESOLVE` message currently + wouldn't count towards any windows, since neither of those commands currently + counts towards windows. +* A cell containing a `SENDME` message and a `DATA` message would count towards + the circuit window and the `DATA` message's stream's window. +* A cell containing two `DATA` messages, for different streams, would count + towards the circuit-level window and both stream-level windows. +* A cell containing two `DATA` messages for the *same* stream counts + *once* towards the circuit-level and stream-level windows. +* If `DATAGRAM` messages (proposal 339) are implemented, and count towards + windows, then every cell containing a fragment of a `DATAGRAM` message counts + towards windows. + # Appendix: Example cells Here is an example of the simplest case: one message, sent in one relay cell: diff --git a/spec/cert-spec.md b/spec/cert-spec.md index 873c258..98aeffa 100644 --- a/spec/cert-spec.md +++ b/spec/cert-spec.md @@ -57,7 +57,7 @@ These representation for this certificate is: | - `ExtType` | 1 | [Type of extension](#list-ext-types)| | - `ExtFlags` | 1 | Control interpretation of extension | | - `ExtData` | `ExtLen` | Encoded extension body | -| SIGNATURE | 64 | Signature of all previous fields | +| `SIGNATURE` | 64 | Signature of all previous fields | The `VERSION` field holds the value `[01]`. diff --git a/spec/param-spec.md b/spec/param-spec.md index cd0af5e..daa70f9 100644 --- a/spec/param-spec.md +++ b/spec/param-spec.md @@ -340,6 +340,43 @@ First appeared: 0.4.2.1-alpha. <a id="param-spec.txt-9"></a> +## Vanguard parameters {#vanguards} + +```text + "vanguards-enabled" -- The type of vanguards to use by default when + building onion service circuits + 0: No vanguards. + 1: Lite vanguards. + 2: Full vanguards. +``` + +```text + "vanguards-hs-service" -- If higher than vanguards-enabled, and we are + running an onion service, we use this level for all our onion service + circuits + 0: No vanguards. + 1: Lite vanguards. + 2: Full vanguards. +``` + +"guard-hs-l2-number" -- The number of guards in the L2 guardset +Min: 1. Max: INT32_MAX. Default: 4 + +"guard-hs-l2-lifetime-min" -- The minimum lifetime of L2 guards +Min: 1. Max: INT32_MAX. Default: 86400 (1 day) + +"guard-hs-l2-lifetime-max" -- The maximum lifetime of L2 guards +Min: 1. Max: INT32_MAX. Default: 1036800 (12 days) + +"guard-hs-l3-number" -- The number of guards in the L3 guardset +Min: 1. Max: INT32_MAX. Default: 8 + +"guard-hs-l3-lifetime-min" -- The minimum lifetime of L3 guards +Min: 1. Max: INT32_MAX. Default: 3600 (1 hour) + +"guard-hs-l3-lifetime-max" -- The maximum lifetime of L3 guards +Min: 1. Max: INT32_MAX. Default: 172800 (48 hours) + ## Denial-of-service parameters {#dos} Denial of Service mitigation parameters. Introduced in 0.3.3.2-alpha: diff --git a/spec/rend-spec/encrypting-user-data.md b/spec/rend-spec/encrypting-user-data.md index 460f71e..fdf1a30 100644 --- a/spec/rend-spec/encrypting-user-data.md +++ b/spec/rend-spec/encrypting-user-data.md @@ -10,3 +10,10 @@ Tor relay encryption protocol, applying encryption with these keys before other encryption, and decrypting with these keys before other decryption. The client encrypts with Kf and decrypts with Kb; the service host does the opposite. + +As mentioned +[previously](./introduction-protocol.md#INTRO-HANDSHAKE-REQS), +these keys are used the same as for +[regular relay cell encryption](../tor-spec/routing-relay-cells.md), +except that instead of using AES-128 and SHA1, +both parties use AES-256 and SHA3-256. diff --git a/spec/rend-spec/introduction-protocol.md b/spec/rend-spec/introduction-protocol.md index 43c5638..0181dd2 100644 --- a/spec/rend-spec/introduction-protocol.md +++ b/spec/rend-spec/introduction-protocol.md @@ -696,7 +696,9 @@ HANDSHAKE_INFO element (see \[JOIN_REND\]). The hidden service host now also knows the keys generated by the handshake, which it will use to encrypt and authenticate data end-to-end between the client and the server. These keys are as -computed in tor-spec.txt section 5.1.4, except that instead of using +computed with the +[ntor handshake](../tor-spec/create-created-cells.html#ntor), +except that instead of using AES-128 and SHA1 for this hop, we use AES-256 and SHA3-256. <a id="rend-spec-v3.txt-3.4"></a> |