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

From: Andrew Newton <[email-masked]>
Date: Fri, 1 Sep 2006 06:26:20 -0400

On Aug 31, 2006, at 11:19 PM, Henning Schulzrinne wrote:

>>> We NEED to protect the query.  I can't imagine designing a system  
>>> designed
>>> for an end host to send its location in the clear for any purpose.
>>
>> I don't see much reason to design a system where the end host  
>> expects to fail authentication.  And regarding this noble of idea  
>> of protecting my location at the risk of my life, I'd rather you not.
>
> I'm confused by this discussion. Are we discussing
>
> (1) protecting privacy of LoST queries for regular PSAP URLs?
>
> (2) protecting access to emergency-infrastructure information  
> ("what is the police commander URL for this point")?
>
> For (1), I just don't see the big deal with normal server-side TLS,  
> as this query will occur well before the emergency in almost all  
> cases and is thus not time-critical. This is also where privacy  
> seems to matter most, since most people would probably not want to  
> be tracked continuously. (The tracking isn't really continuous  
> since you'd only do a query when entering a new coverage region.  
> For most people, that's maybe once a day, during their commute.)

First, Brian is not just talking about TLS with server certs.  He has  
stated repeatedly the idea you mentioned, TLS using HTTP basic or  
digest authentication for normal use, and TLS with server and client  
certs for the special case.

> For queries at the point of an emergency call, TLS with server-side  
> authentication seems harmless, as long as the client can decide to  
> ignore cert validation failures at that time. There is a low risk  
> of a MIM attack, but that's a reasonable trade-off, given the  
> alternatives.

Given that the master secret, which is used to encrypt the session,  
is generated using the keys in the server's certificate, I do not  
believe it is possible for a client to simply ignore cert validation  
failures.  Even it were, suggesting such a thing is bad practice.

-andy

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

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 1 Sep 2006 07:33:17 -0400

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. 

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.

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.

Brian

> -----Original Message-----
> From: Andrew Newton [mailto:[email-masked]]
> Sent: Friday, September 01, 2006 6:26 AM
> To: Henning Schulzrinne
> Cc: Brian Rosen; [email-masked]'
> Subject: Re: [Ecrit] Re: How many people do we plan to kill
> 
>

---

From: Andrew Newton <[email-masked]>
Date: Fri, 1 Sep 2006 08:05:19 -0400

This is what happens when you haven't had that first morning cup of  
coffee and decide to send email...

On Sep 1, 2006, at 6:26 AM, Andrew Newton wrote:
> believe it is possible for a client to simply ignore cert  
> validation failures.  Even it were, suggesting such a thing is bad  
> practice.

As I understand it, the client can create a master secret with the  
suspect public key.  But once you do that, you have essentially  
defeated TLS.  Which means, you are going through the expensive  
exercise of TLS negotiation and cannot guarantee privacy.  This is  
not a very good trade-off.  An evil-twin could trivially take  
advantage of this with an off-the-shelf HTTP proxy.  Given this,  
ROT13 might be more secure. :)

And as I said, some TLS libraries WILL NOT allow the connection to go  
forward under these conditions.  A quick look at JSSE, used by 99% of  
all Java programs which will likely constitute a huge number server- 
side XML-over-HTTP implementations (I don't know if J2ME includes  
JSSE, but if so then we are talking handsets as well), has no  
facility to say "ignore invalid peer certs".  At least none that I  
could find in the Javadoc.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Fri, 1 Sep 2006 08:13:58 -0400

> 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.

> 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.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 1 Sep 2006 08:22:42 -0400

> validation failures.  Even it were, suggesting such a thing is bad  

I agree that ignoring these is bad practice and one would hope that  
something as critical as LoST servers is operated by professionals,  
rather than the police chief's nephew who otherwise mows grass for a  
living, but at least in some cases, web browsers allow users to  
ignore expired certs, mismatched certs or certs with unrecognized  
CAs. Not good, but clearly established practice, given that the  
alternative is no service.

What's your alternative?

---

From: Andrew Newton <[email-masked]>
Date: Fri, 1 Sep 2006 09:55:33 -0400

> What's your alternative?

Do not specify bad practices.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Fri, 1 Sep 2006 09:59:27 -0400

On Sep 1, 2006, at 8:23 AM, Brian Rosen wrote:

> 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.

Ignoring the TLS part for a second, just why is HTTP basic or digest  
authentication necessary?

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 01 Sep 2006 10:12:25 -0400

I don't get it. TLS server-certs does just that. Digest or Basic add no 
certainty in this regard.

I suspect we're all talking past each other at this point.

Brian Rosen wrote:
> To establish a security association that the client reasonably trusts the
> server.  The server will always trust the client.  You then need to create a
> shared secret to use for the privacy key based on the SA.
> 
> Brian
>

---

From: Andrew Newton <[email-masked]>
Date: Fri, 1 Sep 2006 10:09:02 -0400

>> authentication necessary?

What?!  Isn't that what TLS is suppose to do?  I don't hold myself  
out as a security expert, but I would be hugely surprized if HTTP  
authentication isn't about the server trusting the client.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Fri, 1 Sep 2006 10:20:23 -0400

> I suspect we're all talking past each other at this point.

Well, at least we have agreement on this.

I'll try to write up my thoughts on this in another thread.  So far,  
all I've done is sniped at Brian.  I should really try to explain  
myself better.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 1 Sep 2006 08:23:55 -0400

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

> Sent: Friday, September 01, 2006 8:14 AM
> To: Brian Rosen
> Cc: 'Henning Schulzrinne'; [email-masked]'

---

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

I have confused Andy and others by including HTTP auth and TLS-with-certs in
the same sentence.

Forget I said anything about http auth.  Just think TLS-with-server-certs.

Brian

> 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
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 01 Sep 2006 16:47:28 +0200

Hi Andy,

yes, please summarize the discussion. I don't really understand what the 
problem statement is, why we need to develop fancy security mechanisms, 
etc. (I am LoST.)

Ciao
Hannes

Andrew Newton schrieb:
> I'll try to write up my thoughts on this in another thread.  So far, all 
> I've done is sniped at Brian.  I should really try to explain myself 
> better.
> 
> -andy
>

---

From: Ted Hardie <[email-masked]>
Date: Fri, 1 Sep 2006 07:51:21 -0700

>again as a plain TCP query, with no protection.

I believe that the normal case is TLS with server certificates, and that
the use of a basic/digest authentication would *NOT* be layered on
top of it, since there is no reason for the server to authenticate the client.

In the use case where that authentication is needed, client certificates
or digest could be used, but I don't think it is  required for
urn:service:sos lookups.  If you re-use LoST for urn:service:emergency-infrastructure
(as I mentioned yesterday), then maybe there it is.
	
				Ted

---

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

Brian

> Sent: Friday, September 01, 2006 9:59 AM
> To: Brian Rosen