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

[Tobias Heer <[e-mail]>]

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





Am 10.08.2009 um 19:12 schrieb Henderson, Thomas R:

>
>
>> -----Original Message-----
>> From: Tobias Heer [mailto:[e-mail]]
>> Sent: Tuesday, July 28, 2009 6:02 AM
>> To: [e-mail]; Xu Xiaohu
>> Cc: [e-mail]
>> 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




--  

Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group
RWTH Aachen University, Germany
tel: [phone]
web: http://ds.cs.rwth-aachen.de/members/heer