-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rejo Zenger <r...@zenger.nl>:
> [2] OK. Not entirely true, maybe. It may be possible to include those > key in some listing of the directory authorities marking them as bad > nodes. This is a manual process. There should be a possibility to automate this process. Something like... 1. HS owner realizes that his HS key has been stolen (but he still has his copy) 2. HS owner creates the "revocation message" for the onion address, signs it with his key and submits it to the DHT the same way a HS descriptor is uploaded 3. This revocation message, once received and confirmed that it belongs to the owner of the specified onion address, cannot be cancelled or undone. The address is marked as "bad" forever. Alternatively, to avoid cloggering the network, it could be marked as "bad" only for a certain amount of time (a year?) and during the validity period, the owner should reissue a new revocation message, or else it will expire 4. All relays with HSDir flag should keep in their DHT (the ones with hidden service descriptors) also these revocation messages 5. When client tries to download a HS descriptor from a HSDir relay, it will receive the descriptor, but it will also receive the revocation message Now it all depends on the client: 1. Client too old to understand revocation message will ignore the message and connect anyway 2. Client with a default configuration will verify the signature of the HS revocation message and if valid, will refuse to build circuit to HS introduction point (and log this information) 3. Client with a special configuration flag set (IgnoreHSRevocations or something like that) could log the revocation message, but build circuit anyway, at the client owner risk Any flaws in my idea? I see two: 1. What if Tor on HSDir relays is too old? They won't process this message properly. Maybe we should have a new flag for revocation message directory relays and use it instead? 2. What if someone tries to fill the DHT with malicious revocation messages? But it can also happen with normal HS descriptors... - -- Oskar Wendel, o.wen...@wp.pl.remove.this Pubkey: https://pgp.mit.edu/pks/lookup?search=0x6690CC52318DB84C Fingerprint: C8C4 B75C BB72 36FB 94B4 925C 6690 CC52 318D B84C -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJWoANIAAoJEGaQzFIxjbhMX0YH/R30viK1OFRsC5NSSF40jOHG UKItJdGKZupuARcoYwe2DoQloCxiLINPhPigjzRpY6YGzUfYw9+yu9V82MK7CDbj FXnORHfDJjj3qereao1K98aYCrOji+11sAC/aeuuwqxqdHfzSqY0WCqwq4MCMsex lLWghummxQ9qs96EIadUWOszQAWPnfNojNp+ylrFU4sRC364AMCxMyvrM8xG0zpu XUUPtAfo9LEagRKcxpa+zmSvIVOd3f3X+SBIrkBRqdfm7bOizPHigPkFwhPUBoe5 9WiONqm3NBZO6Tfi+4elsNIOkUR99N4SgpLChNRRpnpc6LmIo7aKvXNhUYA3a8w= =UBxQ -----END PGP SIGNATURE----- -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk