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

["James M. Polk" <[e-mail]>]

At 05:04 PM 4/1/2008, Roger Marshall wrote:
>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,

no, I brought up this point at the mic about unique vs. random and 
EKR -- who's better at security than all of us -- followed me and 
said he didn't understand the 128 number, how it was derived or what 
it was accomplishing.

I can't help it if this exact sequence isn't in the minutes, it 
happened and the audio will back me up.

>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,

if you have 20 employees in an enterprise (i.e., within the same 
LIS), 10k numbers is just fine.

you're missing the point that having the number doesn't make the 
identity known, given that any of these employees on this LIS could 
in wildly different geographic areas.

>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,

but who knows they're sequential without knowing the identity of the 
users to make a complete examination of the impact on sequential vs 
non-sequential numbering?

>since I can just start from the bottom and win a lot
>faster than at random.

"win"?  who knows where the start point is? doesn't that matter? I 
think it does.

>Thus, the numbers need to be assigned at random.

this is circular logic - and not convincing


>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