[tor-talk] trusting .onion services

[Oskar Wendel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Oskar Wendel <o.wendel at wp.pl>:

I already see some flaws in my solution, so forgive me for answering 
myself.

> 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

I think it should be done by Tor after putting a directive in torrc below 
HiddenServiceDir. Something like:

HiddenServiceDir /some/dir
HiddenServiceRevoke 1

> 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

Better idea would be to publish it exactly as HS descriptors are 
published. I don't know the validity period of a HS descriptor, but it 
should be periodically refreshed as long as Tor is running (just like HS 
descriptors are - are they?)

Of course only one Tor instance would be sufficient to revoke all HS 
descriptors, published by the attacker who stole the key.

Of course, the attacker could post his own revocation message, but he 
would only do everyone the favor by doing so.

> 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

Maybe it would be better to check client version (does it send its version 
when asking for HS descriptor?) and in case the client is too old and a 
valid revocation message exists, refuse sending this HS descriptor.

> 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)

The signature should always be valid, as it is checked by the HSDir relay, 
but the client should do its check anyway (because HSDir relay could be 
malicious).

> 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

Of course logging with the usual "[scrubbed].onion" text.

> 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?

Bad idea, as all clients would then need a separate circuit to the 
revocation directory just to check the revocation message and it would 
slow down connecting to all hidden services.

What do you all think?

- -- 
Oskar Wendel, o.wendel at 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-----

iQEcBAEBAgAGBQJWoApcAAoJEGaQzFIxjbhMb/sH/08/J4znYNQtvGkt7HqMaopJ
5Yl7lFTHMa+dI2Z1zsdvbdquJ6Vu4IVPnb5Ze9ak2FKnz1l29FOp1YcfsVAGD0WE
M7RmrYVsUA8apYz87oPdzX1jyO8PKi7gPv/B0OFW01V894DAEHZP3RuEkIdYUnwi
gKLl5taafE8xQwI7sFXtyY3vwpT8sWrrvYqeL/+bPVCTgaG68ZU/62FYTgRyduzo
PSyyeEV7ahgvlU6wyBnOd81jSkpqXTf9pmTaVoC5VhVwOJAfCfENef+Eb1FJGNI0
4cgeFiTJG8J/U9CtLjdTtfHJjWrHlYMn1mDTHsx72gpaqU/ASuHyaEUtn78sMWc=
=ztKe
-----END PGP SIGNATURE-----