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

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

Brian,

That sounds like a logical argument for integrity and confidentiality. 

So, the authentication aspects are secondary, correct?  That is what
threw me.  The authentication would only be required if the response
(jurisdicational data) for some reason was only to be given out to
select clients.  Your comments earlier suggested that the authentication
would be done on all queries, and if that failed, then some fall-back
action taken.  Did I misread you on that?

Mike

> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]] 
> Sent: Friday, September 01, 2006 10:40 AM
> To: Michael Hammer (mhammer); 'Andrew Newton'
> Cc: [email-masked]'
> Subject: RE: [Ecrit] Re: How many people do we plan to kill
> 
> 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
> 
> > -----Original Message-----
> > From: Michael Hammer (mhammer) [mailto:[email-masked]]
> > Sent: Friday, September 01, 2006 10:29 AM
> > To: Brian Rosen; Andrew Newton
> > Cc: [email-masked]
> > Subject: RE: [Ecrit] Re: How many people do we plan to kill
> > 
> > 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:56:38 -0400

You understand.  I confused you by talking about HTTP auth.  My mistake,
creating confusion.  You don't need client auth in most cases.

Brian

> Sent: Friday, September 01, 2006 10:50 AM