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 09:53:43 2002