Re: [Geopriv] draft-ietf-geopriv-lbyr-requirements-02 ???

["Roger Marshall" <[e-mail]>]

The Philly geopriv minutes reference a "129 bits of entropy...EKR
statement..." - besides the obvious typo, the 128 bits of entropy there
related to the security draft,
http://www3.tools.ietf.org/html/draft-barnes-geopriv-lo-sec-02, whereas
the stuff below came from a couple of Richard's (and others) discussion
thread on Q3:

1. a snippet of Richard's response of one such message...

R*: The dereference protocol MUST define an anonymized format for 
location URIs.  This format MUST identify the desired LO  by a 
random token with at least 128 bits of entropy (rather than an 
!                          ^^^^^^^^^^^^^^^^^^^
explicit identifier, such as an IP address).  Any URI whose 
dereference will not subject to authentication and access 
control MUST be anonymized.

Link to above message:
http://www.ietf.org/mail-archive/web/geopriv/current/msg05352.html


2. ...also an earlier email talking about (base) number examples which
don't work...

Example 1: Using a 5-digit number doesn't work, because that's only 10k 
queries, and I can write a script to run through those in a few minutes.

  Thus, you need more digits.

Example 2: Using a 32-byte number doesn't work if you assign it 
sequentially, since I can just start from the bottom and win a lot 
faster than at random.  Thus, the numbers need to be assigned at random.

Link to complete message:
http://www.ietf.org/mail-archive/web/geopriv/current/msg05346.html

What was the resolution between unique & random?  Whatever the outcome,
it should probably be inserted into the lbyr-requirements draft, yes?

-roger marshall.

> -----Original Message-----
> From: James M. Polk [mailto:[e-mail]] 
> Sent: Tuesday, April 01, 2008 1:36 PM
> To: Roger Marshall; Hannes Tschofenig
> Cc: GEOPRIV
> Subject: Re: [Geopriv] draft-ietf-geopriv-lbyr-requirements-02 ???
> 
> Roger
> 
> There were comments in Philly that 128 was an arbitrary 
> number without backing, so why was it picked.  There was also 
> discussion on the difference between unique and random in 
> Philly, which was resolved -- but that doesn't mean either 
> issue is dropped.
> 
> James
> 
> At 03:03 PM 4/1/2008, Roger Marshall wrote:
> >The following summarizes the third of the three original subj:
> >questions, Q1,Q2,Q3:
> >
> >Q3.
> >
> >...about draft-ietf-geopriv-lbyr-requirements-01
> >Sent: Friday, February 15, 2008 4:24 PM, From: James M. Polk
> >
> > >
> > > I may have missed the text, but I don't see it in a 
> requirement -- 
> > > but at the last meeting, I was told by James W and Hannes 
> that each 
> > > LbyR URI MUST be unique.  I don't read that anywhere in this ID.
> > >
> > > I read that "...it MUST be hard to guess..."
> > >
> > > why can't all 200 participants in the room draw from a 
> smaller pool 
> > > of numbers that a cryptographically random value?  It 
> would still be 
> > > "hard to guess" who has which identifier...
> >
> >Not much discussion here, but there seemed to be two 
> differing views on
> >this:
> >
> >[a.] One view (Hannes) is that we need to add a new requirement...
> >
> > > [...from...] Tschofenig, Hannes
> > > Sent: Sunday, February 17, 2008 3:48 AM
> > > Subject: Re: [Geopriv] Q3 about
> >draft-ietf-geopriv-lbyr-requirements-01
> > >
> > > Uniqueness is very important. The draft should really have such a 
> > > requirement. Saying that a part of the identifier is 
> random is not 
> > > enough.
> > >
> > > We need to add a requirement.
> >
> >[b.] the other view, (James P. responding to Richard's clarification 
> >q's), seems to take some exception with the idea of a new req.
> >
> >[...from...] James M. Polk
> >Sent: Sunday, February 17, 2008 7:05 PM To: Richard Barnes; 
> Tschofenig, 
> >Hannes
> >Subject: Re: [Geopriv] Q3 about 
> draft-ietf-geopriv-lbyr-requirements-01
> > >
> > > At 08:27 PM 2/17/2008, Richard Barnes wrote:
> > > >Could you two clarify what you mean by "unique"?
> > >
> > > well, this is part of what I was getting at. For example, 
> within RFC 
> > > 3261, the Call-ID value "MUST be unique through space and 
> time" -- 
> > > meaning the alphanumeric value is never repeatable by any 
> UA ever, 
> > > not just within the same UA.
> > >
> > > This is reeeeally unique.
> > >
> > > I think this is more than we need here.
> > >
> > > >That is, within what scope should the URI be unique?
> > >
> > > I think a URI has to be unique within a LIS for all clients that 
> > > have asked for one. I'm not sure we need to be any more 
> unique than 
> > > that.
> > >
> > > >Do you mean to prevent the LS from issuing multiple URIs
> > > that refer to
> > > >the same location?
> > >
> > > I actually don't see a problem in this... but I could be 
> wrong (and 
> > > want to know why I'm wrong BTW)
> > >
> > > >Or are you trying to rule out a case where an LS just hands
> > > out one URI
> > > >(or a few URIs), then hands out different LOs depending 
> on who asks 
> > > >(i.e., the LS uses one URI to refer to multiple LOs)?
> > >
> > > No, from my pov, unique means that a LIS has one unique 
> URI for each 
> > > client that has asked for one.
> > >
> > > I do not believe this URI has to be unique from what's given out 
> > > tomorrow, as long as no two clients have the same URI.
> > > This is one of the uses of the valid-for parameter (that both the 
> > > DHCP Option ID and HELD ID have).  My client shouldn't 
> necessarily 
> > > always be given the same URI, since there is no real guarantee it 
> > > won't be compromised, someone will always have knowledge 
> of my URI 
> > > once they learn it once.
> > >
> > > Having my URI change periodically has a benefit, as long as it 
> > > doesn't change sooner than the active timer of the 'valid-for' 
> > > parameter is set (unless there's been a new request and a 
> particular 
> > > client's URI has been overwritten.
> >
> >SUMMARY:
> >I don't have any further record of any progression on the 
> topic, which 
> >kept me from adding said requirement in -02.  What should the 
> >resolution now be?
> >
> >Thanks.
> >
> >-roger marshall.
> >
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of James M. Polk
> > > Sent: Monday, March 31, 2008 1:19 PM
> > > To: Hannes Tschofenig
> > > Cc: GEOPRIV
> > > Subject: Re: [Geopriv] draft-ietf-geopriv-lbyr-requirements-02 ???
> > >
> > > At 07:53 AM 3/30/2008, Hannes Tschofenig wrote:
> > > >It seems that you are saying that Roger has to keep things going.
> > >
> > > All I'm saying is that there was never a post 
> articulating what the 
> > > consensus reached answers were to each of the 3 questions 
> I asked on 
> > > the list.  I don't believe that is asking a lot. Do you 
> think this 
> > > is asking too much?
> > >
> > > Each of the 3 questions had ~ 5 to 75 responses, so there 
> were a lot 
> > > of folks interested in the questions, and obviously the first 
> > > response didn't answer any of the 3 Qs right away.
> > >
> > >
> > > >Roger, could you post a description of the outstanding 
> issues with 
> > > >a suggestions on how to address them?
> > > >
> > > >Ciao
> > > >Hannes
> > > >
> > > >James M. Polk wrote:
> > > > > At 12:40 PM 3/29/2008, Hannes Tschofenig wrote:
> > > > >> Given the status of HELD this document should have been
> > > finished a
> > > > >> while ago.
> > > > >> I am not even sure whether I have seen a WGLC for it.
> > > > >>
> > > > >> What are the next steps for it?
> > > > >> Why isn't it done already?
> > > > >
> > > > > weeeeelllll....
> > > > >
> > > > > There were 3 fairly substantiative questions posted
> > > against -01 of
> > > > > the ID just before the -0X deadline, and there needs to
> > > be time for
> > > > > proper review of -02 to see if this version answers at
> > > least these 3 questions.
> > > > >
> > > > > I think 1 has been answered
> > > > >
> > > > > I think another has not reached consensus
> > > > >
> > > > > and the last wasn't answered at all
> > > > >
> > > > > but this is memory (which may or may not be reliable)
> > > > >
> > > > >
> > > > >> _______________________________________________
> > > > >> Geopriv mailing list
> > > > >> [e-mail]
> > > > >> https://www.ietf.org/mailman/listinfo/geopriv
> > > >
> > > >_______________________________________________
> > > >Geopriv mailing list
> > > >[e-mail]
> > > >https://www.ietf.org/mailman/listinfo/geopriv
> > >
> > > _______________________________________________
> > > Geopriv mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/geopriv
> > >
> >
> >
> >CONFIDENTIALITY NOTICE: The information contained in this 
> message may 
> >be privileged and/or confidential. If you are not the intended 
> >recipient, or responsible for delivering this message to the 
> intended 
> >recipient, any review, forwarding, dissemination, distribution or 
> >copying of this communication or any attachment(s) is strictly 
> >prohibited. If you have received this message in error, 
> please notify 
> >the sender immediately, and delete it and all attachments from your 
> >computer and network.
> >
> >_______________________________________________
> >Geopriv mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/geopriv
> 
> 
_______________________________________________
Geopriv mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/geopriv