commit f160516451b5d9b51386064dc55e1a6387cc7bb6 Author: Nick Mathewson nickm@torproject.org 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.