diff options
| -rw-r--r-- | proposals/205-local-dnscache.txt | 7 | ||||
| -rw-r--r-- | proposals/216-ntor-handshake.txt | 4 |
2 files changed, 5 insertions, 6 deletions
diff --git a/proposals/205-local-dnscache.txt b/proposals/205-local-dnscache.txt index 624e793..d0a0107 100644 --- a/proposals/205-local-dnscache.txt +++ b/proposals/205-local-dnscache.txt @@ -28,8 +28,9 @@ Status: Closed cache. This lets us implement exit policies and exit enclaves -- if we remember that www.mit.edu is 18.9.22.169 the first time we see it, then we can avoid making future requests for www.mit.edu - via any node that blocks net 18. Also, if there happened to be a - Tor node at 18.9.22.169, we could use that node as an exit enclave. + via any node whose exit policy refuses net 18. Also, if there + happened to be a Tor node at 18.9.22.169, we could use that node as + an exit enclave. But there are security issues with DNS caches. A malicious exit node or DNS server can lie. And unlike other traffic, where the @@ -94,7 +95,7 @@ Status: Closed controller, the configuration file, trackhostexits maps, virtual-address maps, DNS replies, and so on. - With this design, the DNS cache will not be part of the address + With this proposed design, the DNS cache will not be part of the address map. That means that entries in the address map which relied on happening after the DNS cache entries can no longer work so well. These would include: diff --git a/proposals/216-ntor-handshake.txt b/proposals/216-ntor-handshake.txt index e0c4f63..f76e81c 100644 --- a/proposals/216-ntor-handshake.txt +++ b/proposals/216-ntor-handshake.txt @@ -85,7 +85,7 @@ Protocol: The server sends a CREATED cell containing: SERVER_PK: Y -- G_LENGTH bytes - AUTH: H(auth_input, t_mac) -- H_LENGTH byets + AUTH: H(auth_input, t_mac) -- H_LENGTH bytes The client then checks Y is in G^* [see NOTE below], and computes @@ -211,5 +211,3 @@ Test vectors for HKDF-SHA256: b4dc21d69363e2895321c06184879d94b18f0784 11be70b767c7fc40679a9440a0c95ea83a23efbf - - |