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

From: Tobias Heer <[email-masked]>
Date: Tue, 11 Aug 2009 09:23:56 +0300

Hi Dacheng,

Am 11.08.2009 um 06:21 schrieb Dacheng Zhang:

> HI,Tobi:
>
> You mentioned in your emails that your solution can provide a stronger
> binding between hierarchy information and HITs. I am a little  
> confused about
> this argument. Why do we need a stronger binding? Could your please  
> use an
> example to clarify in which condition the binging in current  
> solutions is
> not strong enough?

As I pointed out in my E-Mail to Tom, my main intention was to make  
you aware of the possibility to have a hierarchy-dependent HIT as  
described in draft-jiang-hiprg-hhit-arch-02.txt, not to point out any  
flaws in your design or in the current HIT design. If you don't see  
any application for this, feel free to discard the suggestion.

>
> In addition, there is something that I am not very sure in your  
> algorithm.
> If X is used to prevent guessing, the confidentiality of X must be
> guaranteed.
> That is, X must be kept privately.
X must be kept as secret as the hierarchical information. It is safe  
to reveal X to everyone who is intended to receive the hierarchical  
information.

> However, in your solution,
> communicating peers need to know X in order to verify the binding  
> between a
> HIT and its public key pair. Then how can two communicating peers  
> exchange X
> securely before they have achieved basic exchange?
>
This is where the Htag comes in. If you don't intend to disclose X and  
the hierarchy, the Htag is sufficient to verify the HIT / HI relation.  
Since the Htag is the result of H(Hierarchy, X), the hierarchical  
information cannot be guessed from the Htag. 	

BR,

Tobias

>
> ^_^
>
> BR
>
> Dacheng
>
> -----邮件原件-----
> 发件人: Tobias Heer [mailto:[email-masked]]
> 发送时间: 2009年8月11日 0:50
> 收件人: Henderson, Thomas R
> 抄送: [email-masked]; Xu Xiaohu; [email-masked]
> 主题: Re: [hiprg] draft-zhang-hip-hierarchical-parameter-00:
> Includinghieararchy in HIT generation
>
> 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:[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
>
>
>
>
> --  
>
> 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
>
>
>
>
>
>
>

--  

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: Sheng Jiang <[email-masked]>
Date: Tue, 11 Aug 2009 14:50:10 +0800

Hi, Tobias,

Thanks for your email. As the initial author of draft-jiang-hiprg-hhit-arch,
our original motivation is to enable HIT to be independently used in many
scenarios that needs hierarchical information. I believe the similor
motivation also apply to Dacheng and his
draft-zhang-hip-hierarchical-parameter. Two of us are  actually working
closely.

The main different between his proposal and mine is that his proposal
remains the current HIT architecture, hierarchical information is additional
while mine binds hierarchy information and HITs together and actually
request a revolutionized HIT architecture.

The biggest advantage of my proposal, also the answer Why do we need a
strong binding between hierarchy information and HITs, is to enable HIT to
be independently used in many scenarios that needs hierarchical information,
such as high efficiency resolution, group management of HIT, etc. This
proposal also ensure the global uniqueness of HITs, which the current HIT
architecture cannot guarantee.

Best regards,

Sheng

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Tobias Heer
> Sent: Tuesday, August 11, 2009 2:24 PM
> To: Dacheng Zhang
> Cc: [email-masked]
> Subject: Re: [hiprg] 
> draft-zhang-hip-hierarchical-parameter-00: 
> > binding between hierarchy information and HITs. I am a 
> little confused 
> > about this argument. Why do we need a stronger binding? Could your 
> > please use an example to clarify in which condition the binging in 
> > current solutions is not strong enough?
> 
> As I pointed out in my E-Mail to Tom, my main intention was 
> to make you aware of the possibility to have a 
> hierarchy-dependent HIT as described in 
> draft-jiang-hiprg-hhit-arch-02.txt, not to point out any 
> flaws in your design or in the current HIT design. If you 
> don't see any application for this, feel free to discard the 
> suggestion.
> 
> >
> X must be kept as secret as the hierarchical information. It 
> is safe to reveal X to everyone who is intended to receive 
> the hierarchical information.
> 
> > between a HIT and its public key pair. Then how can two 
> communicating 
> > peers exchange X securely before they have achieved basic exchange?
> >
> This is where the Htag comes in. If you don't intend to 
> disclose X and the hierarchy, the Htag is sufficient to 
> verify the HIT / HI relation.  
> > 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 
> > other approach. Maybe the authors of draft-jiang-hiprg-hhit- 
> > arch-02.txt can give some reasoning.
> >
> > HITs would reveal the hierarchy (even in cases where this is not 
> > wanted).
> > Hence
> > 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.
> >
> > 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).
> >
> > original sense, and yes you must supply the Htag to allow 
> > verification.
> > Hence, it
> 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.
> >
> >>> 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.
> >>>
> >> 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 
> Dipl.-Inform. Tobias Heer, Ph.D. Student Distributed Systems 
> Group RWTH Aachen University, Germany
> tel: +49 241 80 207 76
> _______________________________________________
> hiprg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/hiprg
>