Re: crypto delay (Notes from Non-meeting)

>
> I mostly agree. I do think there's an authorization requirement for
> revealing location information when the call may not be what the user
> intended. (Think about a hyperlink that fetches an image from
> tel://sos, causing the user to reveal their location to a set of
> machines involved in call setup.)

That's a broken implementation, not a crypto or privacy problem. The SIP
entity would only reveal its location when making a call to sip:sos@...
, sip:911@, etc. I believe you're misunderstanding the mechanism.

Yes, this can be intercepted by a bogus proxy that you might be
visiting. However, if you're in the network housing the bogus proxy, the
network probably can find out which Ethernet jack you're using or which
802.11 AP you are coming in on and sell that information to the highest
bidder. If a proxy that does 911/sos routing does something illegal with
the location information, that is probably as much a ground for
prosecution as it would be if your local 911 operator went spouting off
to neighbors about the suicidal caller she got that day.

If you're paranoid and the firewall in the visited network allows it,
you would tunnel to your home proxy via TLS. The home proxy would then
route the call, based on the location information. If you use
sips:sos@home, you'd even get TLS from the home proxy to the PSAP. I
think that this would be much more effective than a special CA for PSAPs
or a special encryption for location information. To spell this out in
more detail:

- my emergency call from any visited network goes TLS to home proxy (in
my case, cs.columbia.edu), affording message privacy and server
authentication;

- cs.columbia.edu home proxy finds appropriate PSAP based on location
information;

- home proxy routes request to PSAP (and verifies its identity) using
TLS

This requires no CA for PSAPs, only a database that's trusted. There are
a number of companies that offer such databases (references available
upon request) that map location information to jurisdictional
information. As long as you can trust these providers, this is at least
as good as a CA would be, minus the PKI issues.

This illustrates that geo-specific privacy would add no appreciable
privacy value, but increase complexity and add failure modes.

Less paranoid individuals may use other permutations; I'm not enough of
a nanny that I would want to prescribe what people do.

> I care about location because I fully expect that its going to be
> revealed all over the place, after its been installed for emergency
> use. I don't see a way to resolve privacy with emergency use; the
> constraints may be sufficient that we say "If you think you're calling
> an emergency line, turn off all privacy."

This doesn't have to be "turn off all privacy". See above.

>
> > The emergency call problem is actually pretty simple. It only gets to be
> > hard if you put artificial constraints on it that no real user much
> > cares about (as witnessed by real, existing systems).
>
> So are there privacy constraints around revealing your information to
> what you think is a PSAP that you think you want to dial? If not,
> can the protocol simply state "emergency call: no privacy"? Do we
> need a protocol message for that?

Again, there is this strange notion of a protocol "message". In this
case, there are no separate messages. Location information has to be an
integral part of the session setup, as it determines the route the
session setup takes.

>
> Adam
Received on Wed Apr 3 20:24:12 2002