Subject: RE: [Ecrit] Re: How many people do we plan to kill

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 1 Sep 2006 10:29:02 -0400

Brian,

>From the peanut gallery:

My impression just from reading this thread is that there are two cases
being considered:

1) 90% - does not require any security, just requires an input to result
in some public information,

2) 10% - requires security to protect some data from being given out to
a select group of people.

The solution proposed seems to focus first on catering to the 10%, and
telling the other 90% that if you jump through the hoops and it doesn't
work, try an alternate unprotected means.

That seems backwards to me.  It seems like the 90% path should be tried
first, and if the data turns out to require a higher degree of
protection, the system challenges the requestor to authenticate
themselves and move to a confidential mode of exchanging the
information.

Is that the case?

Mike

> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]] 
> Sent: Friday, September 01, 2006 8:24 AM
> To: 'Andrew Newton'
> Cc: [email-masked]'
> Subject: RE: [Ecrit] Re: How many people do we plan to kill
> 
> I agree that there is no off the shelf client library that 
> automatically retries a failed TLS operation by attempting a 
> plain TCP operation, but I think it's about 2 or 3 lines of 
> code, in the application, to do it. 
> 
> The last paragraph is not the special case; it's the normal case.
> The normal case is TLS with basic/digest so that the query 
> gets privacy and integrity protection when sending its 
> location and getting its emergency call URI.  Its backup, if 
> it needs to and wants to, is to try the operation again as a 
> plain TCP query, with no protection.
> 
> Brian
> 
> > -----Original Message-----
> > From: Andrew Newton [mailto:[email-masked]]
> > Sent: Friday, September 01, 2006 8:14 AM
> > To: Brian Rosen
> > Cc: 'Henning Schulzrinne'; [email-masked]'
> > Subject: Re: [Ecrit] Re: How many people do we plan to kill
> > 
> > 
> > On Sep 1, 2006, at 7:33 AM, Brian Rosen wrote:
> > 
> > > Andy
> > >
> > > I kept thinking I was missing something.  At this point, 
> I think you 
> > > are missing something.
> > >
> > > The endpoint would first attempt to create a TLS connection.  If 
> > > that succeeded, then he would complete his "https" query.
> > >
> > > If it failed, he does an "http" query.
> > >
> > > All servers that I know of would support that.  All 
> client libraries 
> > > that I know of would support that.
> > 
> > Oh, I think I understand what you are saying.  And no 
> client library 
> > that I know of supports this out of the box.  The LoST application 
> > will have to specifically employ this retry logic.
> > 
> > > For the moment (maybe forever) ignore my special case; we need to 
> > > make sure we agree on the basic mechanism before we deal with 
> > > special cases.
> > 
> > Is your special case the paragraph that follows?  Because 
> I'll happily 
> > ignore it if it is not up for consideration.
> > 
> > > The normal, should-work-every-time case is a TLS query 
> with basic/ 
> > > digest authentication.  There is a backup, completely at 
> the option 
> > > of the client, to run a no-security query and get the 
> same response 
> > > it would have if the TLS attempt had succeeded.  The 
> server doesn't 
> > > care if you use TLS, the client does.  The TLS query is on a 
> > > different port than the non-TLS query, as it is on any similar 
> > > server.
> > 
> > -andy
> 
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit
> 

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 1 Sep 2006 10:39:59 -0400

Nope.

99% of the queries will be from end devices that want privacy and integrity
protection.  They will query with TLS-with-server-certs.  IF THAT FAILS, and
only if it fails, will they fall back to no TLS, no security, just a raw TCP
based query.  It's unacceptable, I think, for anyone to be sending their
location in the clear, unless they can't get a privacy service to work.
Then, and only then, can they make the tradeoff of, "do I send my location
in the clear so I can progress the emergency call, or do I abandon the call
if I can't protect my location privacy".  I assume nearly all of us will
choose the former, but, again, only after we try and fail to protect it.

The 1% is the special case, and instead of TLS-with-server-certs, they will
do TLS-with-client-certs.

Brian

> From: Michael Hammer (mhammer) [mailto:[email-masked]]
> Sent: Friday, September 01, 2006 10:29 AM
> To: Brian Rosen; Andrew Newton
> Cc: [email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Fri, 1 Sep 2006 08:03:20 -0700

At 10:39 AM -0400 9/1/06, Brian Rosen wrote:
>based query.

If I understand correctly, you actually mean over HTTP, not over
a raw TCP transport. 

>  It's unacceptable, I think, for anyone to be sending their

There actually are lots of devices that might trust the layer two
encryption between their device  and its first hop and their provider's
network sufficiently that they would not bother with TLS.  In any case,
if you are supporting HTTP (or raw TCP) as a fallback, you have
to support it on the server side, full stop, as there is no way of
guaranteeing that the client using it has or has not tried tls and failed.

>choose the former, but, again, only after we try and fail to protect it.

There is an underlying question here of whether we need to design
one protocol method for look-ups when the intent is store information
for later use and a different protocol method for use when the
information is needed during an emergency.  In the first, the bias
is for privacy; in the second, the bias is for minimizing latency. 

We've discussed this optimization before, and my sense is that we
have a rough consensus that we push people away from starting
from scratch during emergency call setup at the BCP level (encouraging
the lookups to take place at times when locations have changed, on
boot, and after expiry).  I personally believe we also need to support
a stripped-down, latency-optimized version for use during call set-up,
for cases like booting the phone for the emergency call.  Re-using that
for cases where TLS fails makes sense to me, but there is an obvious
attack here--insert a monkey in the middle that will fail the TLS
check so that the client will drop down to a protocol where the
monkey in the middle will succeed.
				Ted

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 1 Sep 2006 11:37:00 -0400

In line

> From: Ted Hardie [mailto:[email-masked]]
> Sent: Friday, September 01, 2006 11:03 AM
> To: Brian Rosen; 'Michael Hammer (mhammer)'; 'Andrew Newton'
> Cc: [email-masked]'
Yeah, I was half-heartedly dealing with the issue that so far, LoST doesn't
actually specify a protocol, even though we are all thinking some form of
http transport.  It's http with TLS and http without TLS.

> guaranteeing that the client using it has or has not tried tls and failed.

I agree, all servers have to support HTTP.  It's not a problem for them
(they aren't giving out sensitive data).

> is for privacy; in the second, the bias is for minimizing latency.
Yeah, we should look at that.  Nothing strikes me as an obvious way to
differentiate.  Even in an emergency, you WANT privacy, it's just that you
are willing to sacrifice it if necessary.

> monkey in the middle will succeed.
Agree that having a cached good PSAP URI is important.

I would LIKE to have the LoST query run at call time always.  The reason is
that during disasters, things change.  Even with a still-valid TTL, it
really is better to query and get the current data.  Can't count on that
though, because, it's in disasters that the queries are more likely to fail.

MITM worries me also.  We need to explore that area.