Subject: RE: crypto delay (Notes from Non-meeting)

From: Andrew Daviel <[email-masked]>
Date: Mon, 01 Apr 2002 21:34:25 -0800 (PST)

On Wed, 20 Mar 2002, Rosen, Brian wrote:

> 	3) Impractical to use
> 		takes seconds to verify the signature on the
> 		processors in the devices. Cannot add a second
> 		to post dial delay

Just how much time is considered important in emergency calls ?
If there are humans in the loop who don't know each other, or maybe
even speak the same language fluently, we're talking tens of seconds at
least, maybe minutes. Emergency services can't put a response together
that fast, in any case. A few seconds taken to authenticate a location
and reduce the incidence of false alarms is going to save time and lives
in the long run.
There is perhaps an issue if the caller believes the equipment is broken
and tries to reconnect, or abandons it altogether. This might be obviated
by some display or audible feedback of call/authentication progress.

-- 
Andrew Daviel

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 02 Apr 2002 08:59:01 -0500

I don't think the crypto delay is a big issue by itself. What tends to
kill you (sorry...) is the delay incurred by extra round-trips and the
increased probability of losses. For example, if you use TCP (for SSL),
losing the first SYN packet will increase your setup delay by three
seconds. Thus, I'm particularly worried about anything that requires
extra connections from either the user agent or the emergency call
center, e.g., to check CRLs or to retrieve certificates. Another problem
is anything that may, with some probability, require retry. For example,
if you encrypt your call request via S/MIME with the ECC's public key,
just to discover that the ECC can't decrypt it for some reason, you've
added one additional round-trip and probabilistically additional chances
of packet loss and retry delays. For some real numbers, see the paper by
Tony Eyers and myself on "Predicting Internet Telephony Call Setup" at
http://www.cs.columbia.edu/sip/papers.html 

According to discussions on the 911 list, one common standard for 911
answering times is that 90% of all 9-1-1 calls are answered in < 10
seconds. That's the human call setup delay, not the signaling delay.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 02 Apr 2002 09:12:10 -0500

I don't see how caller authentication has anything to do with geo-priv.
Authenticating a location is going to be almost impossible unless you
rely on a trusted intermediary to provide the location. For PDAs with
GPS, that doesn't work. The best you can do is have the originator sign
the request and then later prosecute them. That is, if you can
realistically track [email-masked].

Also, while dispatch times are important, in many cases the important
delay is time to answer, so that the emergency call center can, for
example, provide instructions on CPR or other first-aid advice.

---

From: Marc Linsner <[email-masked]>
Date: Tue, 02 Apr 2002 09:38:47 -0500

Absolutely correct!  Time to answer the call is very important.  As the
Wireless Phase II implementations are unfolding, it is very typical for the
call to be completed (people talking) for 20+ seconds before the location
information is displayed on the PSAP's screen.  This time lag has nothing to
do with authentication/crypto, it's simply the time it takes to triangluate
and derive a reasonably accurate location.

Taking time to authenticate and/or intiate crypto may be doable if it all
works.  Can we complete the call if something fails?

-Marc Linsner-