diff options
Diffstat (limited to 'proposals/331-res-tokens-for-anti-dos.md')
| -rw-r--r-- | proposals/331-res-tokens-for-anti-dos.md | 53 |
1 files changed, 27 insertions, 26 deletions
diff --git a/proposals/331-res-tokens-for-anti-dos.md b/proposals/331-res-tokens-for-anti-dos.md index a7293e8..448ebe4 100644 --- a/proposals/331-res-tokens-for-anti-dos.md +++ b/proposals/331-res-tokens-for-anti-dos.md @@ -56,20 +56,20 @@ Status: Draft from various types of Token Issuers and then redeem them at the onion service to gain access even when under DoS conditions. - In section [TOKEN_DESIGN], we list our requirements from an anonymous + In section [TOKEN_DESIGN](#token-design), we list our requirements from an anonymous credential scheme and provide a high-level overview of how the Res token scheme works. - In section [PROTOCOL_SPEC], we specify the token issuance and redemption protocols, + In section [PROTOCOL_SPEC](#protocol-spec), we specify the token issuance and redemption protocols, as well as the mathematical operations that need to be conducted for these to work. - In section [TOKEN_ISSUERS], we provide a few examples and guidelines for + In section [TOKEN_ISSUERS](#token-issuers), we provide a few examples and guidelines for various token issuer services that could exist. - In section [DISCUSSION], we provide more use cases for Res tokens as well as + In section [DISCUSSION](#discussion), we provide more use cases for Res tokens as well as future improvements we can conduct to the scheme. -# 3. Design [TOKEN_DESIGN] +# 3. Design \[TOKEN_DESIGN\] {#token-design} In this section we will go over the high-level design of the system, and in the next section we will delve into the lower-level details of the protocol. @@ -109,13 +109,13 @@ Status: Draft - Quick Verification: Onions are already experiencing resource starvation because of the DoS attacks so it's important that the process of - verifying a token should be as quick as possible. In section [TOKEN_PERF] + verifying a token should be as quick as possible. In section [TOKEN_PERF](#token-perf) we will go deeper into this requirement. After careful consideration of the above requirements, we have leaned towards using Blind RSA as the primitive for our tokens, since it's the fastest - scheme by far that also allows public verifiability. See also Appendix B - [BLIND_RSA_PROOF] for a security proof sketch of Blind RSA perfect unlinkability. + scheme by far that also allows public verifiability. See also [Appendix A](#blind-rsa-proof) + for a security proof sketch of Blind RSA perfect unlinkability. ## 3.3. Other security considerations @@ -128,7 +128,7 @@ Status: Draft - Metadata: We want to encode metadata/attributes in the tokens. In particular, we want to encode the destination onion service and an - expiration date. For more information see section [DEST_DIGEST]. For + expiration date. For more information see section [DEST_DIGEST](#dest-digest). For blind RSA tokens this is usually done using "partially blind signatures" but to keep it simple we instead encode the destination directly in the message to be blind-signed and the expiration date using a set of @@ -162,9 +162,9 @@ Status: Draft an adversary breaks an issuance key, she will be able to forge tokens for just a few hours before that key expires. - For more ideas on future schemes and improvements see section [FUTURE_RES]. + For more ideas on future schemes and improvements see section [FUTURE_RES](#future-res). -## 3.5. Token performance requirements [TOKEN_PERF] +## 3.5. Token performance requirements \[TOKEN_PERF\] {#token-perf} As discussed above, verification performance is extremely important in the anti-DoS use case. In this section we provide some concrete numbers on what @@ -188,14 +188,14 @@ Status: Draft For this reason we implemented a basic version of the Res token scheme in Rust and benchmarked the verification and issuance procedure [REF_RES_BENCH]. - We measured that the verification procedure from section [RES_VERIFY] takes + We measured that the verification procedure from section [RES_VERIFY](#res-verify) takes about 0.104 ms, which we believe is a reasonable verification overhead for the purposes of this proposal. - We also measured that the issuance procedure from [RES_ISSUANCE] takes about + We also measured that the issuance procedure from [RES_ISSUANCE](#res-issuance) takes about 0.614 ms. -# 4. Specification [PROTOCOL_SPEC] +# 4. Specification \[PROTOCOL_SPEC\] {#protocol-spec} +--------------+ +------------------+ | Token Issuer | | Onion Service | @@ -270,7 +270,7 @@ Status: Draft onion service in its token store. If not, it needs to acquire some and hence the token issuance protocol commences. -### 4.3.1. Client preparation [DEST_DIGEST] +### 4.3.1. Client preparation \[DEST_DIGEST\] {#dest-digest} Alice first chooses an issuer supported by the onion service depending on her preferences by looking at the consensus and her Tor configuration file for @@ -289,7 +289,7 @@ Status: Draft - 'destination' is the 32-byte ed25519 public identity key of the destination onion - 'salt' is a random 32-byte value, - 3) Alice samples a blinding factor 'r' uniformly at random from [1, N) + 3) Alice samples a blinding factor 'r' uniformly at random from \[1, N) 4) Alice computes: blinded_message = dest_digest * r^e (mod N) @@ -301,7 +301,7 @@ Status: Draft XXX Is the salt needed? Reevaluate. -### 4.3.3. Token Issuance [RES_ISSUANCE] +### 4.3.3. Token Issuance \[RES_ISSUANCE\] {#res-issuance} Alice now initiates contact with the Token Issuer and spends the resources required to get issued a token (e.g. solve a CAPTCHA or a PoW, create an @@ -348,8 +348,9 @@ Status: Draft onion service. To do so, Alice adds an extension to the encrypted portion of the INTRODUCE1 - cell by using the EXTENSIONS field (see [PROCESS_INTRO2] section in - rend-spec-v3.txt). The encrypted portion of the INTRODUCE1 cell only gets + cell by using the EXTENSIONS field (see [PROCESS_INTRO2 section in + rend-spec-v3.txt](../rend-spec/introduction-protocol.md#PROCESS_INTRO2)). + The encrypted portion of the INTRODUCE1 cell only gets read by the onion service and is ignored by the introduction point. We propose a new EXT_FIELD_TYPE value: @@ -365,7 +366,7 @@ Status: Draft SALT [32 bytes] where: - - TOKEN_VERSION is the version of the token ([0x01] for Res tokens) + - TOKEN_VERSION is the version of the token (\[0x01\] for Res tokens) - ISSUER_KEY is the public key of the chosen issuer (truncated to 4 bytes) - DEST_DIGEST is the 'dest_digest' from above - TOKEN is the 'token' from above @@ -381,7 +382,7 @@ Status: Draft XXX maybe with a bit of tweaking we can even use a 1536-bit RSA signature here... -### 4.4.2. Onion service verifies token [RES_VERIFY] +### 4.4.2. Onion service verifies token \[RES_VERIFY\] {#res-verify} Upon receiving an INTRODUCE1 cell with the above extension the service verifies the token. It does so as follows: @@ -408,7 +409,7 @@ Status: Draft considers the token valid and the rest of the onion service protocol carries out as normal. -# 5. Token issuers [TOKEN_ISSUERS] +# 5. Token issuers \[TOKEN_ISSUERS\]{#token-issuers} In this section we go over some example token issuers. While we can have official token issuers that are supported by the Tor directory authorities, @@ -472,7 +473,7 @@ Status: Draft one-show, so the onion service cannot provide a single token that will work for multiple "logins". In the future we can design multi-show credential systems that also have revocation to further facilitate this use case (see - [FUTURE_RES] for more info). + [FUTURE_RES](#future-res) for more info). # 6. User Experience @@ -506,7 +507,7 @@ Status: Draft XXX Actually analyze the above if we think there is merit to listing them -# 8. Discussion [DISCUSSION] +# 8. Discussion \[DISCUSSION\] {#discussion} ## 8.1. Using Res tokens on Exit relays @@ -525,7 +526,7 @@ Status: Draft websites and web services on the public Internet. We hope that this way we will see less websites blocking Tor. -## 8.2. Future improvements to this proposal [FUTURE_RES] +## 8.2. Future improvements to this proposal \[FUTURE_RES\] {#future-res} The Res token scheme is a pragmatic scheme that works for the space/time constraints of this use case but it's far from ideal for the greater future @@ -579,7 +580,7 @@ Status: Draft --- -# Appendix A: RSA Blinding Security Proof [BLIND_RSA_PROOF] +# Appendix A: RSA Blinding Security Proof \[BLIND_RSA_PROOF\] {#blind-rsa-proof} This proof sketch was provided by Michele Orrù: |