RE: [Geopriv] coming to terms on location by reference

There is no "catastrophic failure mode" and citing circumstances outside
the scope of the protocol do not reflect on the protocol. Actually
privacy is an ideology. However, I could take the position that this
group be disbanded in the interests of its "name" because I can cite an
arbitrary number of circumstances under which information in a presence
server, including location, may become compromised.

I agree it's a pointless discussion which is why I advise not to use
such scenarios to criticize a protocol element. It results in wasted
effort and increasingly moot discussion.

Cheers,
Martin

> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Thursday, 14 September 2006 10:13 AM
> To: Dawson, Martin
> Cc: GEOPRIV
> Subject: Re: [Geopriv] coming to terms on location by reference
>
> I think it is pointless to discuss this further. I will strongly
> object to any protocol that has such blatant security problems and
> hope that the name of this working group actually means something.
> This has nothing to do with ideology, unless you want to declare
> privacy an "ideology" and we should just trust everybody.
>
> As I pointed out, it doesn't matter whether you trust 'anybody'. A
> protocol with a catastrophic failure mode is not a good engineering
> design, in my view.
>
> Trying to denigrate this by "sowing seeds of fear" is rhetoric, not
> rational argument.
>
> Henning
>
> On Sep 13, 2006, at 7:59 PM, Dawson, Martin wrote:
>
> > This is the kind of ideological rhetoric that I object to in an
> > engineering forum.
> >
> > * If you don't trust anybody, don't use networks... or just about
> > anything else. The principle of the LIS is that it's the access
> > network
> > that can determine location. They don't need an IETF protocol to do
> > this. Law enforcement agencies can, and do, place warrants on access
> > providers to obtain location, session data, and session times. They
> > may
>
> I said nothing about not allowing warrants. The mechanism I objected
> to facilitates warrantless spying.
>
>
>
> > do this for sound social good or they may do it for nefarious and/or
> > oppressive purposes. Their ability to do this is not governed by
IETF
> > spec capabilities and it's an act of hubris to think it is.
>
> Lots of engineering organizations have objected, in general, to
> network designs that expose such weaknesses, particularly given that
> there are solutions that do not suffer from such catastrophic failure
> modes.
>
>
> >
> > * If you want to ensure that ethical controls are placed on these
> > activities - and the proper standard of staff and organizational
> > responsibilities - then use the democratic process. You need sound
> > legislation and an ethical administration. If you don't live in a
> > democracy, you may need to consider revolution. You will make zero
> > contribution by trying to project your politics through a protocol
> > specification.
>
> I didn't know that facilitating warrantless interception was the
> mission of this working group. Thanks for clarifying that.
>
>
>
> >
> > * There are valid purposes for these mechanisms; trying to
deposition
> > them by sowing seeds of fear is not sound engineering.
> >
> > Cheers,
> > Martin
> >
> >> -----Original Message-----
> >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> >> Sent: Thursday, 14 September 2006 5:03 AM
> >> To: Brian Rosen
> >> Cc: Dawson, Martin; 'Hannes Tschofenig'; 'GEOPRIV'
> >> Subject: Re: [Geopriv] coming to terms on location by reference
> >>
> >>
> >>
> >> Brian Rosen wrote:
> >>>> I don't see an issue for this in a jurisdiction where the
emergency
> >>>> services authority does have the authorization to obtain location
> > at
> >> any
> >>>> time. The way it is managed in those jurisdictions is that there
> > are a
> >>>> very limited number of entities that can make this query and they
> > are
> >>>> provided with a certificate from a jurisdiction-based certificate
> >>>> authority. Note that I assume a jurisdiction typically equals a
> > country
> >>>> in this instance though it can be anything.
> >>> While I believe that, in normal circumstances, this can be made to
> > work
> >>> reliably, I don't want to create a situation in which a failure
here
> >> causes
> >>> a call to not get location.
> >>
> >> There's also a more subtle issue. Since the LIS doesn't know when
> >> there's an emergency, such a certificate essentially gives every
> >> PSAP,
> >> i.e., every police department, the immediate and continuous
> >> ability to
> >> obtain the movement records of citizens anywhere in the country,
> > without
> >> the (modest) check of having to present a warrant to the carrier
> >> and a
> >> fairly extensive approval process which is reasonably heavy-weight.
> >>
> >> At least some people might find such a capability a bit scary.
> >>
> >> Even if you don't worry about the being snooped on officially, it
> >> significantly lowers the bar for local mischief by rogue or bored
> >> PSAP
> >> call takers or first responders. There have been enough stories
about
> >> surveillance cameras being used for "entertainment" purposes that
I'd
> >> rather not give random employees in two-person PSAPs run on a
kitchen
> >> table (which roughly describes the one in my town) the capability
to
> > do
> >> that.
> >>
> >> In addition, there are likely to be various non-governmental
entities
> >> that might handle emergency calls, such as the equivalent of
> >> OnStar or
> >> VSP-operated default call centers. They would presumably also need
> >> the
> >> ability to query for location information. Now, I'm giving such
> >> capability to minimum-wage call center employees that used to sell
> >> replacement windows the week before.
> >>
> >> There's also a more unlikely failure scenario: Unless there's some
> > kind
> >> of certification body and capability-based certs, you end up with
> >> thousands to tens of thousands of entities sharing the same private
> > key.
> >> This is not a comforting thought.
> >>
> >> Even with capability-based certs, this mechanism has a particularly
> >> nasty single-compromise failure. If a bad actor manages to obtain
one
> >> such certificate (by pretexting, say, to use the word of the week),
> > that
> >> bad actor can get the location information of the whole citizenry
of
> > the
> >> whole country, not just the call records of a few board members.
> >>
> >> In short, some protocol capabilities are best left out since they
are
> >> just too dangerous when they *succeed*. (There are other ways to
deal
> >> with L-by-R authorization, but I find the certificate one
> >> particularly
> >> objectionable and dangerous. I'm very troubled that proponents of
> > L-by-R
> >> advocate them.)
> >>
> >>
> >>>
> >>> I agree that the configuration protocol (endpoint to LIS) should
be
> > the
> >> same
> >>> whether it's LbyR or LbyV. It does not follow that the
dereference
> >> protocol
> >>> (between the dereferencer and the LIS) should be the same. If the
> > LCP
> >> had a
> >>> policy upload function, I would consider that a good thing. I'm
not
> >> sure
> >>> it's a requirement that it be the same protocol, but I think it's
> > very
> >>> desirable.
> >>
> >> For the case of SIMPLE, XCAP is the to-be standardized policy
upload
> >> protocol. It seems unlikely that this would be appropriate for the
> > other
> >> functions.
> >>
> >> Henning
> >
> >
----------------------------------------------------------------------
> > --------------------------
> > This message is for the designated recipient only and may
> > contain privileged, proprietary, or otherwise private information.
> > If you have received it in error, please notify the sender
> > immediately and delete the original. Any unauthorized use of
> > this email is prohibited.
> >
----------------------------------------------------------------------
> > --------------------------
> > [mf2]
>

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Wed, 13 Sep 2006 19:29:54 -0500