[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-commits] [torspec/master] Turn questions into declarations in dir-spec.txt
commit 4d6c1a8894c6e08ea781e77b17abe0275e072ca2
Author: Nick Mathewson <nickm@xxxxxxxxxxxxxx>
Date: Wed May 16 11:07:25 2012 -0400
Turn questions into declarations in dir-spec.txt
---
dir-spec.txt | 22 +++++++++-------------
1 files changed, 9 insertions(+), 13 deletions(-)
diff --git a/dir-spec.txt b/dir-spec.txt
index 7fbed8e..d9e4157 100644
--- a/dir-spec.txt
+++ b/dir-spec.txt
@@ -1089,13 +1089,6 @@
The "onion-key" element as specified in 2.1.
- [Should we mention that clients don't learn identity keys anymore
- with this approach? Clients only need identity keys for their
- entry guards, and in that case they learn the identity key from
- the TLS handshake. But clients couldn't check identity keys of
- non-entry nodes with the microdescriptor approach anymore, even if
- they wanted. -KL]
-
"family" names NL
[At most once]
@@ -1109,12 +1102,15 @@
The exit-policy summary as specified in 3.3 and 3.5.2. A missing
"p" line is equivalent to "p reject 1-65535".
- [Should we note the downside of this approach that clients never
- learn exact exit policies now? Clients can only guess whether a
- relay accepts their request, try the BEGIN request, and might get
- end-reason-exit-policy if they guessed wrong, in which case
- they'll have to try elsewhere. Or is this too much design
- discussion for a spec? -KL]
+ [With microdescriptors, clients don't learn exact exit policies:
+ clients can only guess whether a relay accepts their request, try the
+ BEGIN request, and might get end-reason-exit-policy if they guessed
+ wrong, in which case they'll have to try elsewhere.]
+
+ (Note that with microdescriptors, clients do not learn the identity of
+ their routers: they only learn a hash of the identity key. This is all
+ they need to confirm the actual identity key when doing a TLS handshake,
+ and all they need to put the identity key digest in their cREATE cells.)
3.3. Vote and consensus status documents
_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits