From 285cf93e702b558e95294d9c0276eee8e7e9e616 Mon Sep 17 00:00:00 2001 From: Ian Jackson Date: Tue, 5 Mar 2024 18:27:57 +0000 Subject: Discuss the weirdness with two lots of INTRODUCE extensions --- spec/rend-spec/introduction-protocol.md | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/spec/rend-spec/introduction-protocol.md b/spec/rend-spec/introduction-protocol.md index 02ed828..5016347 100644 --- a/spec/rend-spec/introduction-protocol.md +++ b/spec/rend-spec/introduction-protocol.md @@ -463,10 +463,21 @@ will have: The same rules for multiplicity, ordering, and handling unknown types apply to the extension fields here as described \[EST_INTRO\] above. -### INTRODUCE1 Extensions +### INTRODUCE1/INTRODUCE2 Extensions The following sections details the currently supported or reserved extensions -of an `INTRODUCE1` message. +of an `INTRODUCE1`/`INTRODUCE2` message. + +Note that there are two sets of extensions in `INTRODUCE1`/`INTRODUCE2`: +one in the top-level, unencrypted portion, +and one within the plaintext of ENCRYPTED. + +The sets of extensions allowed in each part of the message are disjoint: +each extension is valid in only *one* of the two places. + +Nevertheless, for historical reasons, +both kinds of extension are listed in this section, +and the use nonoverlapping values of `EXT_FIELD_TYPE`. #### Congestion Control -- cgit v1.2.3-54-g00ecf From a2d4549a8d76bfede8ee093ab446229b69b06229 Mon Sep 17 00:00:00 2001 From: Ian Jackson Date: Tue, 5 Mar 2024 18:29:49 +0000 Subject: Remove duplicated statement about unknown extensions This sentence seems stray in this section. The information is alreayd present with the wording The same rules for multiplicity, ordering, and handling unknown types apply to the extension fields here as described \[EST_INTRO\] above. which appears earlier, for each of the two sections. --- spec/rend-spec/introduction-protocol.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/spec/rend-spec/introduction-protocol.md b/spec/rend-spec/introduction-protocol.md index 5016347..9b9c5b0 100644 --- a/spec/rend-spec/introduction-protocol.md +++ b/spec/rend-spec/introduction-protocol.md @@ -494,8 +494,6 @@ ntorv3, if the service did not list "2" in the `FlowCtrl` line in the descriptor. The client SHOULD NOT provide this field if the consensus parameter 'cc_alg' is 0. -The service MUST ignore any unknown fields. - #### Proof-of-Work (PoW) {#INTRO1_POW_EXT} This extension can be used to optionally attach a proof of work to the introduction request. -- cgit v1.2.3-54-g00ecf From 2901a68f09c9b99b9f2c4c06eaed77605a01e2d7 Mon Sep 17 00:00:00 2001 From: Ian Jackson Date: Tue, 5 Mar 2024 18:35:25 +0000 Subject: State that "Congestion Control Request" appears in ENCRYPTED I got the answer to this question from proposals/324-rtt-congestion-control.txt (This thing should have a proper identifier, not merely a descriptive phrase, but that may be controversial.) --- spec/rend-spec/introduction-protocol.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/spec/rend-spec/introduction-protocol.md b/spec/rend-spec/introduction-protocol.md index 9b9c5b0..edc9112 100644 --- a/spec/rend-spec/introduction-protocol.md +++ b/spec/rend-spec/introduction-protocol.md @@ -494,6 +494,8 @@ ntorv3, if the service did not list "2" in the `FlowCtrl` line in the descriptor. The client SHOULD NOT provide this field if the consensus parameter 'cc_alg' is 0. +This appears in the ENCRYPTED section of the INTRODUCE1/INTRODUCE2 message. + #### Proof-of-Work (PoW) {#INTRO1_POW_EXT} This extension can be used to optionally attach a proof of work to the introduction request. -- cgit v1.2.3-54-g00ecf From 99ff0862361fb78493bdab9fab8ea015a70948eb Mon Sep 17 00:00:00 2001 From: Ian Jackson Date: Tue, 5 Mar 2024 18:35:51 +0000 Subject: Move clarificatory text into rubric part. --- spec/rend-spec/introduction-protocol.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/spec/rend-spec/introduction-protocol.md b/spec/rend-spec/introduction-protocol.md index edc9112..724cb64 100644 --- a/spec/rend-spec/introduction-protocol.md +++ b/spec/rend-spec/introduction-protocol.md @@ -470,7 +470,8 @@ of an `INTRODUCE1`/`INTRODUCE2` message. Note that there are two sets of extensions in `INTRODUCE1`/`INTRODUCE2`: one in the top-level, unencrypted portion, -and one within the plaintext of ENCRYPTED. +and one within the plaintext of ENCRYPTED +(ie, after RENDEZVOUS_COOKIE and before ONION_KEY_TYPE. The sets of extensions allowed in each part of the message are disjoint: each extension is valid in only *one* of the two places. @@ -504,8 +505,7 @@ An acceptable proof will raise the priority of this introduction request accordi This is for the [proof-of-work DoS mitigation](../dos-spec/overview.md#hs-intro-pow), described in depth by the [Proof of Work for onion service introduction](../hspow-spec/index.md) specification. -If used, it needs to be encoded within the N_EXTENSIONS field of the -encrypted portion of the INTRO1/INTRO2 message. (After RENDEZVOUS_COOKIE and before ONION_KEY_TYPE) +This appears in the ENCRYPTED section of the INTRODUCE1/INTRODUCE2 message. The content is defined as follows: -- cgit v1.2.3-54-g00ecf From e3f2950c733cac1cf40ff952dcaed7e03883695b Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Wed, 6 Mar 2024 11:43:31 +0000 Subject: Fix typo --- spec/rend-spec/introduction-protocol.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/spec/rend-spec/introduction-protocol.md b/spec/rend-spec/introduction-protocol.md index 724cb64..3c30f98 100644 --- a/spec/rend-spec/introduction-protocol.md +++ b/spec/rend-spec/introduction-protocol.md @@ -478,7 +478,7 @@ each extension is valid in only *one* of the two places. Nevertheless, for historical reasons, both kinds of extension are listed in this section, -and the use nonoverlapping values of `EXT_FIELD_TYPE`. +and they use nonoverlapping values of `EXT_FIELD_TYPE`. #### Congestion Control -- cgit v1.2.3-54-g00ecf