Delivery-Date: Tue, 03 Mar 2015 09:23: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.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	RCVD_IN_DNSWL_MED,T_DKIM_INVALID,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 DDE431E0A66
	for <archiver@seul.org>; Tue,  3 Mar 2015 09:23:14 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 7346733CBD;
	Tue,  3 Mar 2015 14:23:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id C3A9B33CAD
 for <tor-talk@lists.torproject.org>; Tue,  3 Mar 2015 14:23:06 +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 8b1VHySq0EiQ for <tor-talk@lists.torproject.org>;
 Tue,  3 Mar 2015 14:23:06 +0000 (UTC)
Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com
 [IPv6:2607:f8b0:4002:c07::22b])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (Client CN "smtp.gmail.com",
 Issuer "Google Internet Authority G2" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id 985F733A3C
 for <tor-talk@lists.torproject.org>; Tue,  3 Mar 2015 14:23:06 +0000 (UTC)
Received: by ykbq200 with SMTP id q200so16797253ykb.2
 for <tor-talk@lists.torproject.org>; Tue, 03 Mar 2015 06:23:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:sender:in-reply-to:references:date:message-id:subject
 :from:to:content-type;
 bh=kpi+11iJgfHkG9asSMHvDERj4NZjaSbXkcdNeX8KsvY=;
 b=eZH4vnV8mDZG6S9nr2lJGA8FbHOhZIp3gLqqQieCwc1k1zoJK06ev4jHWiY8oU5vAL
 44MqkebYVLwGPtwCffqiySXxEGYuEEOcUn7cd0uUI/mzKIfpQegwnVsn8DPKiMlMlE0v
 woLM9IjklrYKw/GVmHgdICu+0r0BBXQchcFhrthvBUH8KCEp1ZML5kCm5EY/3peKZRvL
 RRAALFwHBNvr/MUmNSB64mqbibGC/NTGw3y4NePRGOmqnI5D5zBYIJZLNba5RrmubFc4
 SJsYI3ZeQ5j27hqJKQl/WD0KnUdxuBX83MicfMBSaTPjBnbGyjduMOcjM/ewZGcMy2oA
 I/lw==
MIME-Version: 1.0
X-Received: by 10.202.1.200 with SMTP id 191mr22003437oib.82.1425392584306;
 Tue, 03 Mar 2015 06:23:04 -0800 (PST)
Received: by 10.76.55.136 with HTTP; Tue, 3 Mar 2015 06:23:04 -0800 (PST)
In-Reply-To: <54F5B9DC.9010101@adrienj.com>
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>
 <54F5B9DC.9010101@adrienj.com>
Date: Tue, 3 Mar 2015 15:23:04 +0100
X-Google-Sender-Auth: IZgoDMgjHn21LORXWJpxXt0JBNA
Message-ID: <CAGH6_ppvP-1B8F_7w2QN95x4Dy8j0rjwhbbeYB1tUCk4GNzVGw@mail.gmail.com>
From: Domenico Andreoli <domenico.andreoli@linux.com>
To: tor-talk@lists.torproject.org
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-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>

The unvoidable single point of failure is the loss of control on a
given onion node.
Isn't possible to require multiple nodes to sustain a single hidden service?
So that loosing control of a single node doesn't compromise the whole service.

Domenico

On Tue, Mar 3, 2015 at 2:40 PM, Adrien Johnson <adrienj@adrienj.com> wrote:
> 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
-- 
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

