Delivery-Date: Wed, 02 Jul 2014 06:41:57 -0400
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.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	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 8113F1E0A2C
	for <archiver@seul.org>; Wed,  2 Jul 2014 06:41:53 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 2280A2FBB4;
	Wed,  2 Jul 2014 10:41:51 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 3A3BE2E2CE
 for <tor-talk@lists.torproject.org>; Wed,  2 Jul 2014 10:34:03 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at eugeni.torproject.org
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 c-eBjI9bdV26 for <tor-talk@lists.torproject.org>;
 Wed,  2 Jul 2014 10:34:03 +0000 (UTC)
Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [132.250.118.211])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
 (Client did not present a certificate)
 by eugeni.torproject.org (Postfix) with ESMTPS id 10C152C425
 for <tor-talk@lists.torproject.org>; Wed,  2 Jul 2014 10:34:03 +0000 (UTC)
Received: from vpn212046.nrl.navy.mil (vpn212046.nrl.navy.mil [132.250.212.46])
 by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id s62AXxKl016398
 for <tor-talk@lists.torproject.org>; Wed, 2 Jul 2014 06:33:59 -0400
Date: Wed, 2 Jul 2014 06:34:06 -0400
From: Paul Syverson <paul.syverson@nrl.navy.mil>
To: tor-talk@lists.torproject.org
Message-ID: <20140702103406.GA3851@vpn212046.nrl.navy.mil>
References: <20140630181150.579a117b@gate.rlogin.net>
 <DUB121-W340733C713F86F8887940DC8040@phx.gbl>
 <53B234B4.5010705@cyblings.on.ca>
 <DUB121-W87B38C15F614AFC2BF53BC8070@phx.gbl>
 <272befac-46cd-4eb4-b1d8-73aa517f590d@email.android.com>
 <DUB121-W257E25780AF7E06F86145CC8070@phx.gbl>
 <20140701183608.GC8758@buridan.fw5540.net>
 <DUB121-W251AEBCFE9EC8755DE31F9C8070@phx.gbl>
 <20140701200059.GD8758@buridan.fw5540.net>
 <DUB121-W17ABE3FF8F80351100ADD1C8070@phx.gbl>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DUB121-W17ABE3FF8F80351100ADD1C8070@phx.gbl>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-CCS-MailScanner: No viruses found.
X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email
Subject: Re: [tor-talk] Illegal Activity As A Metric of Tor Security and
 Anonymity
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>

On Tue, Jul 01, 2014 at 10:06:38PM +0100, Mark McCarron wrote:
> Paul,
> 
> Paul,
> 
> What you are seeking a full design for a distributed Web Hosting
> platform within Tor.  Let's see...

Well even a sketch (which you begin to provide below) would be more
helpful to be able to comment on whether you actually have practical
security improvements in mind than was simply claiming that others could
obviously do better and just chose not to do so.

I also wasn't specifically talking about hosting web pages. This
thread has meandered a bit, but I was responding to the repeated
claims that it was obvious how we could have designed our systems to
be more secure by asking how, because it was not at all obvious to me.

> 
> We can use the existing mechanisms for hidden services, but rather than directing packets to/from a externally hosted site, we direct the packets internally within onion land.  On an initial page request, packets are directed to a random node on Tor network to find the first portion of the page.  That node then selects another random node to deliver the next portion.  This process repeats until all content is delivered to the client.
> 
> There are are a number of important elements in this design:  
> 
> 1.  "Page/Content/Media portions" can be migrated anywhere in the network randomly.  This is an automated system.  
> 2.  The network forgets content/media not access for a long time.
> 3.  Migrations should look no different than regular connections
> 4.  There is no way to query the location of "Page/Content/Media portions" (that is internal to the network)
> 5.  No optimisation should be made for geographic delivery
> 6.  Uploads are shredded and delivered to different nodes (network migrates them)
> 7.  All data is encrypted before upload. (route through decryption nodes when properly accessed as a .onion address)
> 8.  Encryption keys are regularly changed
> 9.  Multiple copies of each site improving availability.
> 10.  Using hashes, remove duplicates of pages/content/media (instead share the same resource as a link/reference)
> 
> That would be the basics of it.  It needs fully fleshed out but to
> the end user it would be a CPanel like interface and a standard
> website with DB support.

It sounds like you are describing a censorship resistant publishing
scheme for (relatively) static content like Freehaven or the Eternity
Service (minus the forgetting in 2. which is more like Vanish or the
Infernity Service---which I think I only ever wrote up partially in
some mailing list comment somewhere 15 years or so ago). 

It's hard to comment without more details about intended goals,
adversary model etc. But what you are describing is a very limited subset
of the way many hidden services are used now.  People use HS for private
chatrooms, for maintenance access to their firewalled systems, to
manage the damage caused to an operation when insiders are compromised
because they only over get access to the hidden service part, not
to mention things like Strongbox and similar systems. 

My point is simply that this could not serve as a drop-in replacement
for hidden services as they are currently used to protect people and
their activities (assuming I get the gist from this initial
description).  That might be OK. You might be starting to describe
something useful.  But useful how, and in what context, and with what
security would need spelling out in much more detail.

> 
> I'll see about expanding on this.

Looking forward to it. Please keep in mind that much of the time when
we get good ideas, someone has already not only had similar ones but
written them up, possibly implemented them, possibly deployed them,
possibly published them in peer-reviewed venues, etc. So please as
much as possible explain how what you offer is an improvement over
existing designs described e.g. in papers in the anonbib.

aloha,
Paul

> 
> Regards,
> 
> Mark McCarron
> 
> > Date: Tue, 1 Jul 2014 16:00:59 -0400
> > From: paul.syverson@nrl.navy.mil
> > To: tor-talk@lists.torproject.org
> > Subject: Re: [tor-talk] Illegal Activity As A Metric of Tor Security and Anonymity
> > 
> > On Tue, Jul 01, 2014 at 08:31:00PM +0100, Mark McCarron wrote:
> > > Paul,
> > > 
> > [snip]
> > > Eliminating this correlation attack is trivial.  
> > 
> > So you keep saying. Everybody who has worked on this who has responded
> > has said that they don't know how and that they find this a hard
> > problem. But your response is simply to keep repeating that it is
> > trivial to eliminate without telling us how.
> > 
> > > The attack is dependent on having visibility at both ends.  One at
> > > the users end (perhaps ISP) and one near the hidden service (perhaps
> > > exchange).  It doesn't take much to match these two together (like
> > > multiple nations sharing intelligence data).  One simple attack is
> > > just to flood the hidden service with connections and note where
> > > traffic spikes.
> > > 
> > > So, the simple solution is to distribute hidden services within Tor,
> > > so that class of attack will fail.  There are no servers in a data
> > > center to expose because it is everywhere and no one can tell, just
> > > by examining the flow of encrypted packets, who was looking at what.
> > 
> > Lots of smart people have thought about hidden service design. E.g.,
> > Karsten did his dissertation on it and earlier guard nodes were
> > introduced to Tor based on Lasse and my illustration of how easy
> > attacks were on hidden services without guards. Our original design of
> > hidden services in Tor harks back to notions of rendezvous services in
> > earlier NRL onion routing work and earlier work by Ian Goldberg, I
> > think in _his_ dissertation if memory serves.  That HS design
> > languished at times while other aspects of Tor were more urgently
> > worked on and that they could use more attention has been
> > acknowledged, and it is getting some. It could use still more and will
> > hopefully be getting it soon.
> > 
> > You may be way smarter than all of these people, but so smart that we
> > can't infer how your simple solution works from these two sentence
> > descriptions. As a kneejerk thought based on just even this brief
> > description: a malicious active client is a trivial adversary to
> > create. It can induce whatever signature it wants on its flow to the
> > HS and can actively affect flows from the HS. What keeps the Tor relay
> > adjacent to the HS or the ISP at the HS or between it and the adjacent
> > relay from recognizing timing signals from malicious clients?
> > For that matter, I don't understand why the system you mention would
> > not be vulnerable to the attack you mention to motivate it.
> > 
> >  
> > > 
> > > Now, I know there are a wide range of additional methods to expose
> > > users and the majority are beyond your direct control, but this type
> > > of attack is something within your control.
> > 
> > Please illustrate how. Please give a design sketch with at least
> > enough details and at a simple enough level of description that even
> > the world's top hidden service design and analysis researchers can
> > understand it since they keep telling you they don't understand these
> > trivial fixes you keep mentioning.
> > 
> > [snip]
> > 
> > aloha,
> > Paul
> > -- 
> > 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

