[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-commits] [torspec/master] Add proposal 320 for removing TAP finally
commit f160516451b5d9b51386064dc55e1a6387cc7bb6
Author: Nick Mathewson <nickm@xxxxxxxxxxxxxx>
Date: Mon May 11 16:11:11 2020 -0400
Add proposal 320 for removing TAP finally
---
proposals/000-index.txt | 2 +
proposals/320-tap-out-again.md | 122 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 124 insertions(+)
diff --git a/proposals/000-index.txt b/proposals/000-index.txt
index fb2fc56..3374a26 100644
--- a/proposals/000-index.txt
+++ b/proposals/000-index.txt
@@ -240,6 +240,7 @@ Proposals by number:
317 Improve security aspects of DNS name resolution [OPEN]
318 Limit protover values to 0-63 [OPEN]
319 RELAY_FRAGMENT cells [OPEN]
+320 Removing TAP usage from v2 onion services [OPEN]
Proposals by status:
@@ -285,6 +286,7 @@ Proposals by status:
317 Improve security aspects of DNS name resolution
318 Limit protover values to 0-63
319 RELAY_FRAGMENT cells
+ 320 Removing TAP usage from v2 onion services
ACCEPTED:
188 Bridge Guards and other anti-enumeration defenses
249 Allow CREATE cells with >505 bytes of handshake data
diff --git a/proposals/320-tap-out-again.md b/proposals/320-tap-out-again.md
new file mode 100644
index 0000000..5e404f8
--- /dev/null
+++ b/proposals/320-tap-out-again.md
@@ -0,0 +1,122 @@
+```
+Filename: 320-tap-out-again.md
+Title: Removing TAP usage from v2 onion services
+Author: Nick Mathewson
+Created: 11 May 2020
+Status: Open
+```
+
+(This proposal is part of the Walking Onions spec project. It updates
+proposal 245.)
+
+# Removing TAP from v2 onion services
+
+Though v2 onion services akre obsolescent and their cryptographic
+parameters are disturbing, we do not want to drop support for them
+as part of the Walking Onions migration. If we did so, then we
+would force some users to choose between Walking Onions and v2 onion
+services, which we do not want to do.
+
+Instead, we describe here a phased plan to replace TAP in v2 onion
+services with ntor. This change improves the forward secrecy of
+_some_ of the session keys used with v2 onion services, but does not
+improve their authentication, which is strongly tied to truncated
+SHA1 hashes of RSA1024 keys.
+
+Implementing this change is more complex than similar changes
+elsewhere in the Tor protocol, since we do not want clients or
+services to leak whether they have support for this proposal, until
+support is widespread enough that revealing it is no longer a
+privacy risk.
+
+## Ntor keys, link specifiers, and SNIPs in v2 descriptors.
+
+We define these entries that may appear in v2 onion service
+descriptors, once per introduction point.
+
+ "identity-ed25519"
+ "ntor-onion-key"
+
+ [at most once each per intro point.]
+
+ These values are in the same format as and follow the same
+ rules as their equivalents in router descriptors.
+
+ "link-specifiers"
+
+ [at most once per introduction point]
+
+ This value is the same as the link specifiers in a v3 onion
+ service descriptor, and follows the same rules.
+
+Services should not include any of these fields unless a new network
+parameter, "hsv2-intro-updated" is set to 1. Clients should not parse
+these fields or use them unless "hsv2-use-intro-updated" is set to 1.
+
+We define a new field that can be used for hsv2 descriptors with
+walking onions:
+
+ "snip"
+ [at most once]
+
+ This value is the same as the snip field introduced to a v3
+ onion service descriptor by proposal XXX, and follows the
+ same rules.
+
+Services should not include this field unless a new network parameter,
+"hsv2-intro-snip" is set to 1. Clients should not parse this field or use it
+unless the parameter "hsv2-use-intro-snip" is set to 1.
+
+Additionally, relays SHOULD omit the following legacy intro point
+parameters when a new network parameter, "hsv2-intro-legacy" is set
+to 0: "ip-address", "onion-port", and "onion-key". Clients should
+treat them as optional when "hsv2-tolerate-no-legacy" is set to 1.
+
+## INTRODUCE cells, RENDEZVOUS cells, and ntor.
+
+We allow clients to specify the rendezvous point's ntor key in the
+INTRODUCE2 cell instead of the TAP key. To do this, the client
+simply sets KLEN to 32, and includes the ntor key for the relay.
+
+Clients should only use ntor keys in this way if the network parameter
+"hsv2-client-rend-ntor" is set to 1, and if the entry "allow-rend-ntor"
+is present in the onion service descriptr.
+
+Services should only advertise "allow-rend-ntor" in this way if the
+network parameter "hsv2-service-rend-ntor" is set to 1.
+
+## Migration steps
+
+First, we implement all of the above, but set it to be disabled by
+default. We use torrc fields to selectively enable them for testing
+purposes, to make sure they work.
+
+Once all non-LTS versions of Tor without support for this proposal are
+obsolete, we can safely enable "hsv2-client-rend-ntor",
+"hsv2-service-rend-ntor", "hsv2-intro-updated", and
+"hsv2-use-intro-updated".
+
+Once all non-LTS versions of Tor without support for walking onions
+are obsolete, we can safely enable "hsv2-intro-snip",
+"hsv2-use-intro-snip", and "hsv2-tolerate-no-legacy".
+
+Once all non-LTS versions of Tor without support for _both_ of the
+above implementations are finally obsolete, we can finally set
+"hsv2-intro-legacy" to 0.
+
+## Future work
+
+There is a final TAP-like protocol used for v2 hidden services: the
+client uses RSA1024 and DH1024 to send information about the
+rendezvous point and to start negotiating the session key to be used
+for end-to-end encryption.
+
+In theory we could get a benefit to forward secrecy by using ntor
+instead of TAP here, but we would get not corresponding benefit for
+authentication, since authentication is still ultimately tied to
+HSv2's scary RSA1024-plus-truncated-SHA1 combination.
+
+Given that, it might be just as good to allow the client to insert
+a curve25519 key in place of their DH1024 key, and use that for the
+DH handshake instead. That would be a separate proposal, though:
+this proposal is enough to allow all relays to drop TAP support.
_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits