Delivery-Date: Tue, 03 Mar 2015 08:40:57 -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,RCVD_IN_DNSWL_MED,
	T_RP_MATCHES_RCVD,URIBL_BLOCKED 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 2EBAE1E0843
	for <archiver@seul.org>; Tue,  3 Mar 2015 08:40:55 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 8158D33C7A;
	Tue,  3 Mar 2015 13:40:50 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 27D9B33B26
 for <tor-talk@lists.torproject.org>; Tue,  3 Mar 2015 13:40:47 +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 Kjc1XIZRPZZT for <tor-talk@lists.torproject.org>;
 Tue,  3 Mar 2015 13:40:47 +0000 (UTC)
Received: from imap2-3.ox.privateemail.com (imap2-3.ox.privateemail.com
 [192.64.116.208])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client CN "privateemail.com",
 Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id 01D9A338AC
 for <tor-talk@lists.torproject.org>; Tue,  3 Mar 2015 13:40:46 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by mail.privateemail.com (Postfix) with ESMTP id D4BF28C007D
 for <tor-talk@lists.torproject.org>; Tue,  3 Mar 2015 08:40:43 -0500 (EST)
X-Virus-Scanned: Debian amavisd-new at imap2.ox.privateemail.com
Received: from mail.privateemail.com ([127.0.0.1])
 by localhost (imap2.ox.privateemail.com [127.0.0.1]) (amavisd-new, port 10024)
 with LMTP id JWNyobxAHBxm for <tor-talk@lists.torproject.org>;
 Tue,  3 Mar 2015 08:40:43 -0500 (EST)
Received: from [192.168.42.162] (135-23-87-110.cpe.pppoe.ca [135.23.87.110])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by mail.privateemail.com (Postfix) with ESMTPSA id 7FB828C007B
 for <tor-talk@lists.torproject.org>; Tue,  3 Mar 2015 08:40:43 -0500 (EST)
Message-ID: <54F5B9DC.9010101@adrienj.com>
Date: Tue, 03 Mar 2015 08:40:44 -0500
From: Adrien Johnson <adrienj@adrienj.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
 rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: tor-talk@lists.torproject.org
References: <54F506C7.6020202@adrienj.com>
 <CALoT2zYkwUEguD-bN+hsePTK8a+G=HRWju6s3yGtiQA5+G5Waw@mail.gmail.com>
 <54F51F38.30902@adrienj.com>
 <CAKrUFkh4fd9tkssVXiUs0g_X5vRYH2FBA4Te0nJGRtyM2Qy0dw@mail.gmail.com>
 <54F524EE.3050400@adrienj.com> <54F58AAD.5010000@donncha.is>
In-Reply-To: <54F58AAD.5010000@donncha.is>
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Subject: Re: [tor-talk] Revoking a hidden service key
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

A client receiving a revocation descriptor would want to remember not to 
trust that hidden service for as long as possible, so there's still 
going to be long-term storage somewhere in the chain. Putting it in the 
directories would mean that as many client as possible could be notified 
of the hidden service's revocation, even long after the initial 
revocation is published, in cases where the hidden service operator is 
unwilling or unable to continue to announce the revocation.

Consider that for long-validity revocations, there would actually be 
less load placed on the network than for a regular short term 
descriptor. The hidden service would not need to frequently publish a 
new descriptor about itself. Once a client knows a hidden service is 
revoked, they do not need to ask about it again. Old revocations could 
conceivably be stored to disk.

The need to revoke hidden service keys is real. It doesn't take long to 
dig up anecdotes and news reports of .onion sites that have been 
compromised, but even when detected there is no reliable way for a 
legitimate hidden service operator to notify the network his service 
cannot be trusted. Detecting if someone has stolen your hidden service 
key is easy and is hijacking your traffic is easy, you only have to look 
out for hidden service descriptors for your service that you did not 
publish, but there is currently not much that can be done with this 
information. The hidden service operator could include a notice on his 
hidden website warning of the compromise and telling users to divert to 
a different .onion address, but a user has no way of knowing if that 
warning was published by the attacker and directs to another malicious site.

On 2015-03-03 5:19 AM, Donncha O'Cearbhaill wrote:
> Alternatively the original hidden service operator could publish hidden
> service descriptors with a normal validity period which contain a
> revocation field. A HSDir which receives a descriptor containing the
> revocation could replace the (potentially malicious) HS descriptor
> stored in its cache.
>
> A client could be show an alert that the hidden service they are
> attempting to access has been compromised/revoked and should not be used
> in future. A HS operator would then keep broadcasting the revocation
> descriptor until such time that all clients are likely to have been
> notified. This kind of replacement approach would allow revocation
> without placing any more load or memory demands on the network.
>
> In practice do HS operators have a need to revoke hidden service keys?
>
> On 03/03/15 03:05, Adrien Johnson wrote:
>> An solution might be to allow hidden service revocation descriptors to
>> expire after a long time, and to be updated by the hidden service
>> operator, but only as a new revocation descriptor which has a later
>> expiration date. That way the Tor network can eventually forget about
>> revoked hidden services which are no longer used and where the operator
>> no longer feels there is a threat of impersonation.
>>
>> On 2015-03-02 9:50 PM, Max Bond wrote:
>>> It seems like the only way this scheme could work is if the directories
>>> remembered which services had issued revocations, making compromises
>>> expensive for the whole network and opening the door for
>>> denial-of-service
>>> attacks that effect hidden services as a whole.
>>>
>>> I would counter propose that you set up a Twitter account which tweets
>>> about the status of your hidden service, where you could make an
>>> emergency
>>> announcement. Perhaps you could have a passcode required to enter the
>>> site
>>> that changes on a daily basis and is announced from twitter, so that your
>>> users get in the habit of checking twitter before logging in to your
>>> site.
>>>
>>> On Mon, Mar 2, 2015 at 6:40 PM, Adrien Johnson <adrienj@adrienj.com>
>>> wrote:
>>>
>>>> Deleting your key and taking down your service would prevent further
>>>> compromise of your system, but if your private key was already
>>>> stolen, it
>>>> wouldn't stop an attacker from continuing to announce your key and
>>>> running
>>>> an imposter service.
>>>>
>>>> -- 
>>>> 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
>>>>
>
>

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

