Subject: Re: [hiprg] draft-zhang-hip-hierarchical-parameter-00: Includinghieararchy in HIT generation

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 10 Aug 2009 09:12:38 -0700

> -----Original Message-----
> From: Tobias Heer [mailto:[email-masked]] 
> Sent: Tuesday, July 28, 2009 6:02 AM
> To: [email-masked]; Xu Xiaohu
> Cc: [email-masked]
> Subject: [hiprg] draft-zhang-hip-hierarchical-parameter-00: 
> Includinghieararchy in HIT generation
> 
> Hi!
> 
> I just wanted to clarify my comment in the HIPRG meeting on 
> including  
> the hierarchy in the HIT creation process. I think it would 
> be good to  
> have the hierarchy information in the HIT creation process 
> because the  
> hierarchy will be bound to the HIT itself.
> 
> Below I briefly sketched a possible way of including it without  
> revealing the hierarchy to all hosts.
> 
> HIT generation could work like this:
> 
> 1. Pick random secret X
> 
> 2. H(Hierarchy, X) => HTag
> 
> 3. H(PubKey, ..., HTag) => HIT (Orchid)
> 
> --> Only use LTag if you do not want to reveal hierarchy.
> --> Use hierarchy and X if you want to reveal the hierarchy.

Hi Tobias,

I recently had a chance to listen to the audio archive of the meeting
and I'm reviewing the mail now.  Can you explain in more detail what is
the use case for what you are proposing?  I thought that the draft was
mainly concerned with having publicly revealed hierarchies so that
reverse lookups could exploit hierarchy.  In your proposal above, for
the observer who knows X, how does such observer retrieve hierarchy
bits, given the HIT, HTag, and X?

Also, I am not sure you can claim that the result from your above is a
HIT, because according to RFC4843 and 5201, a HIT is formed without
these HTags.  In particular, the HIT would no longer be able to be
associated to the key, for an observer who does not know the magic HTag
to apply. 

Tom

---

From: Tobias Heer <[email-masked]>
Date: Mon, 10 Aug 2009 19:50:02 +0300

Hi Tom,

I was just picking up an idea that was described in another  
hierarchical HIT draft (draft-jiang-hiprg-hhit-arch-02.txt). I did  
like the touch that the "HIT" is determined by the hierarchy because  
it binds the hierarchy to the HIT and it becomes more difficult to  
spoof the hierarchy information for a given HIT because with a  
different hierarchy you end up with a different HIT. Hence, the  
hierarchy information would be self certifying in the sense that if I  
give a HIT to someone, the hierarchy would be bound to it and it would  
stay like that unless I changed my HIT. I have not really considered  
the practical benefits, I just wanted to tell the authors about the  
other approach. Maybe the authors of draft-jiang-hiprg-hhit- 
arch-02.txt can give some reasoning.

Dacheng was worried that putting the hierarchy information into the  
HITs would reveal the hierarchy (even in cases where this is not  
wanted). Hence my suggestion to secure the hierarchy information with  
an additional hash. However, since the number of hierarchies is  
probably too small to make a full search through all hierarchies  
infeasible (one could just hash each hierarchy information and see  
whether a given hash matches), I introduced X, which is supposed to  
protect against this simple search. This was only meant as a quick  
reply to Dacheng's privacy concerns.

The proposed solution was not meant to replace the hierarchy  
information in an additional parameter it was only intended to have a  
stronger binding between hierarchy information and HIT. I already  
stated this in a reply to Dancheng's e-mail on the list (28th of July,  
17:29 GMT+3).

You are perfectly right that the resulting hash is not a HIT in the  
original sense, and yes you must supply the Htag to allow  
verification. Hence, it must also be transmitted with the HI. And yes,  
it breaks backwards compatibility with hosts that don't know what to  
do with it. However, since it seems that more hash functions will be  
introduced in the process of adding crypto agility to HIP, one could  
consider this as an additional "hash function" or way of hashing.

Don't get me wrong: I'm not saying we should do this. I just wanted to  
make people aware of the way it is handled in the other draft.

BR and greetings from Helsinki,

Tobi

--  

Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://ds.cs.rwth-aachen.de/members/heer

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 10 Aug 2009 10:33:41 -0700

> Hence, the  
> stay like that unless I changed my HIT. 

...

> stronger binding between hierarchy information and HIT. 

Maybe this is a terminology issue but I don't think of this as a binding
or as self-certifying, in the same way that a certificate binds a name
to a principal, or in the way that current HITs are self-certifying,
because there is no authorization to use the hierarchy bits.

- Tom

---

From: Tobias Heer <[email-masked]>
Date: Mon, 10 Aug 2009 21:16:35 +0300

> because there is no authorization to use the hierarchy bits.

I agree, this is probably a terminology problem. I also agree that  
this binding (or call it linking if you prefer) does not imply  
authorized use of the hierarchy data in the HIT generation.

BR, Tobias

--