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

[Sheng Jiang <[e-mail]>]

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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> On Behalf Of Tobias Heer
> Sent: Tuesday, August 11, 2009 2:24 PM
> To: Dacheng Zhang
> Cc: [e-mail]
> Subject: Re: [hiprg] 
> draft-zhang-hip-hierarchical-parameter-00: 
> Includinghieararchy in HIT generation
> 
> 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:[e-mail]]
> > 发送时间: 2009年8月11日 0:50
> > 收件人: Henderson, Thomas R
> > 抄送: [e-mail]; Xu Xiaohu; [e-mail]
> > 主题: 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:[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
> >
> >
> >
> >
> >
> >
> >
> 
> 
> 
> 
> --  
> 
> 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
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> hiprg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/hiprg
>