[Hipsec-rg] reverse DNS lookups of HITs

[thomas.r.henderson at boeing.com (Henderson, Thomas R)]

 

> -----Original Message-----
> From: JiangSheng 66104 [mailto:shengjiang at huawei.com] 
> Sent: Tuesday, January 13, 2009 2:22 AM
> To: Henderson, Thomas R; oleg.ponomarev at hiit.fi
> Cc: hipsec-rg at listserv.cybertrust.com; 
> brian at cs.auckland.ac.nz; shengjiang at huawei.com
> Subject: Re: [Hipsec-rg] reverse DNS lookups of HITs
> 
> > > > I see how one could technically build such a name 
> server, but I'm
> > > > wondering about the scalability of it and how it would
> > > operationally be
> > > > deployed.
> > >
> > > I guess one modern server could keep like ten million records
> > > in RAM? How
> > > many base exchanges can it do per second? Reverse DNS updates
> > > are rare
> > > anyway.
> > >
> > > When HIP gets widely deployed and there are millions of
> > > users, we might
> > > hope to use more resources :)
> > >
> > 
> > This type of question is precisely what this research 
> group's primary
> > charter is to answer, in my opinion.  What are the consequences of
> > deploying HIP on a large scale in the Internet?  If it means that we
> > will have a few root servers handling reverse DNS queries 
> for all hosts,
> > without any aggregation, how will that architecture scale, 
> and how will
> > the deployment incentives work?  Or, if that turns out to 
> be a bad idea,
> > what are the practical alternatives that allow someone to write
> > domain-name-based ACLs?
> 
> This is exactly where we need hierarchical HIT for. (See 
> http://tools.ietf.org/id/draft-jiang-hiprg-hhit-arch-01.txt.) 
> The aggregation of Hierarchical HIT proposal can help to 
> organize HITs in the large scale deployment and improve 
> looking-up efficiency in either mapping system (such as DNS, 
> or DHT, etc.) or ACL. This proposal is also compatible with 
> the flat-structured HIT architecture, which can meet the 
> requirement of privacy.

Regarding your proposal:

   For index and resolution purposes, HITs are aggregatable with 
   management domain tags of arbitrary bit-length, similar to IPv4 
   addresses under Classless Inter-Domain Routing [RFC4632]. 
...
   The most important security property of HIT is that it is self-
   certifying (i.e., given a HIT, it is computationally hard to find a 
   Host Identity key that matches the HIT). Although this document 
   limits the hash output to be 94-bit long, it does not affect the self

   certifying security property. 

It seems to me that this self-certifying property is lost if one
prepends an unsecured management domain tag.  There is nothing stopping
a malicious node from using management domain tags of its choosing to
evade ACLs that are based on management domain tags.  

- Tom