RE: crypto delay (Notes from Non-meeting)

Well, I'd love to take emergency calls off the table in this
group and just go do what we need in SIPPING, but that's not
the way the AD's see it. I also see the point that there really
should only be one way to send location. I think that there are
quite a few uses for location that don't have much of a privacy
concern, and a lot more where the concerns will be addressed by
contract rather than by mechanism. It's really hard to get our
arms around the disparate requirements without getting one
end (speed, simplicity, efficiency) or the other (very fine
grained control with very strong protection) upset.

The "low" end wants most of the mechanisms optional, the "high"
end doesn't. That seems to be the nut of the problem - what
is mandatory to implement and even, a new concept, what is
mandatory to use.

Compromise on privacy seems to be hard to find.

I've been working on it over a year, I'll keep working at it :)

Brian

> -----Original Message-----
> From: Adam Shostack [mailto:adam@zeroknowledge.com]
> Sent: Wednesday, April 03, 2002 9:51 AM
> To: Rosen, Brian
> Cc: 'Andrew Daviel'; 'geopriv@mail.apps.ietf.org'
> Subject: Re: crypto delay (Notes from Non-meeting)
>
>
> On Wed, Apr 03, 2002 at 08:27:56AM -0500, Rosen, Brian wrote:
> > > Acatually, I'm not sure whey we spend so much time discussing the
> > > E911 scenarios, though I'm clearly guilty of doing so myself.
> > > The reaction
> > > time thing just caught my eye.
> > >
> > One of the "users", probably the first user, of the geopriv object
> > is emergency calls in SIP. The requirements for emergency
> calls at the
> > top level are pretty straightforward, but are clearly subject to
> > interpretation as you dig down.
>
> Perhaps this is a mistake? I think that emergency calling is complex,
> and I'm far more concerned about my non-emergency privacy.
>
> (I do think there is a security concern, which is that if I send your
> internet phone a hyperlink of the form "img src=tel:sos" you may hand
> out your location without the same meaning as actually dialling 911.
> We likely can't cope with this at the protocol level, but should note
> it in the security concerns section, and suggest that turning off
> privacy preference should be based on user action...)
>
> > Emergency callers have some expectation of privacy. That
> expectation
> > is presently pretty limited. There is no harm in providing a higher
> > level of privacy, provided that you don't screw something
> up. Response
> > time is one of those things that can be screwed up.
> Phones, in general,
> > have fairly puny processors. SIP phones have beefier
> processors than
> > first gen cell phones, and 3G cell phones have processors capable of
> > non-trivial crypto, but I think we have to keep "fraction
> of a second
> > on embedded cpu" goals when we make crypto choices. If we
> are forced
> > to choose between increased security and increased response time on
> > emergency calls, it makes sense to me to choose increased
> security up
> > to the point where on a typical SIP phone or 3G handset, you either
> > overflow limited memory, or more likely limited MIPS. The
> latter is the
> > "fraction of a second" kind of thing. I'm presently
> worried about it,
> > but there are others who think there are solutions that achieve
> > strong assurances within the kinds of time/MIPS/Memory constraints
> > we deal with. I'm certainly not oppossed to trying.
>
> I'm also interested in trying, and would like to throw out the
> suggestion that we might specify a level of crypto which is secure,
> and offer nothing on slower processors. That would make sense if we
> worry about roll-back attacks, and the ongoing cost of having weak
> crypto in the system.
>
> Adam
>
Received on Wed Apr 3 16:45:39 2002