Delivery-Date: Wed, 20 Jan 2016 17:30:16 -0500
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
	RCVD_IN_DNSWL_MED,T_RP_MATCHES_RCVD autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id B202B1E2FCA;
	Wed, 20 Jan 2016 17:30:14 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id F3736393E8;
	Wed, 20 Jan 2016 22:30:05 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 6C4E7393D7
 for <tor-talk@lists.torproject.org>; Wed, 20 Jan 2016 22:30:02 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at 
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Hdglr4cQNPYK for <tor-talk@lists.torproject.org>;
 Wed, 20 Jan 2016 22:30:02 +0000 (UTC)
Received: from plane.gmane.org (plane.gmane.org [80.91.229.3])
 (using TLSv1 with cipher AES256-SHA (256/256 bits))
 (Client did not present a certificate)
 by eugeni.torproject.org (Postfix) with ESMTPS id 384CF393C6
 for <tor-talk@lists.torproject.org>; Wed, 20 Jan 2016 22:30:02 +0000 (UTC)
Received: from list by plane.gmane.org with local (Exim 4.69)
 (envelope-from <gno-or-talk-2@m.gmane.org>) id 1aM1GI-0008Ga-DN
 for tor-talk@lists.torproject.org; Wed, 20 Jan 2016 23:29:58 +0100
Received: from chomsky.torservers.net ([77.247.181.162])
 by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
 id 1AlnuQ-0007hv-00
 for <tor-talk@lists.torproject.org>; Wed, 20 Jan 2016 23:29:58 +0100
Received: from o.wendel by chomsky.torservers.net with local (Gmexim 0.1
 (Debian)) id 1AlnuQ-0007hv-00
 for <tor-talk@lists.torproject.org>; Wed, 20 Jan 2016 23:29:58 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: tor-talk@lists.torproject.org
From: Oskar Wendel <o.wendel@wp.pl>
Date: Wed, 20 Jan 2016 22:29:51 +0000 (UTC)
Lines: 87
Message-ID: <n7p1ov$fib$1@ger.gmane.org>
References: <20160116212250.GA14827@ix-293.local> <n7p00n$ia8$1@ger.gmane.org>
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: chomsky.torservers.net
Subject: Re: [tor-talk] trusting .onion services
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

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

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

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

