Re: [Geopriv] HELD and persistent TLS connections in emergency calls

[Hannes Tschofenig <Hannes.Tschofenig at gmx.net>]

Hi Cullen,

Cullen Jennings wrote:
> Few random thoughts....
>
> Certainly session resumption might work well here - basically when the 
> device connected the first time it would do the public key operation 
> to set up session once then save a secret that could be used for 
> future sessions without doing the expensive public key operations. 
> There are extensions to allow session resumption to only store state 
> on the client not server - RFC 4507 and soon to be approved update to it.

Yep; http://www.ietf.org/internet-drafts/draft-salowey-tls-rfc4507bis-01.txt
(Document already in *RFC Ed Queue*)

> It would be well worth having a look at the session resumption stuff 
> and seeing how to specify it's usage - it is implemented in many TLS 
> stacks including OpenSSL.
>
> I also think it would be worth looking at what the time to set up a 
> TLS session is.

We have done some performance measurements, see
http://www.tmg.informatik.uni-goettingen.de/publications/1297/psk_tls_gi2006_final.pdf

The analysis did not consider session resumption. However, as one can 
easily see the key length and the selected mode has an impact on the 
performance.


> The first thing would be to look at what size keys should the server 
> use - some recommendation for key size specific to LIS might help keep 
> people from using things way too large. The information transfered 
> over HELD is unlikely to have high long term value and that might 
> change the key sizes chosen. It would then be good to guess what the 
> processors might be on the very low end stuff by the time any of this 
> actually gets deployed. My gut feeling is 1/2 second does not sound 
> quite right. Whatever the answer is, it would be nice to see this 
> analysis.
While the above-mentioned study consider "low-end machines" as well it 
did not focus on mobile phones. Maybe that's something to add.

With the low-end servers we have used 1/2 second is certainly not correct.

> I can also imagine that in some cases getting a reference might help 
> in that the host that eventually fetched the reference might have a 
> much faster processor than a low end mobile phone.

Ciao
Hannes

> Cullen <with my individual hat on>
>
> PS - I simultaneously agree with Henning that it might be possible to 
> use long lived TLS connection while agreeing with Barbara that 
> regardless of the feasibility, operators will hate the idea. Hows that 
> for being on the fence :-)  But I hope we can avoid having to do this 
> approach.
>
>
> On Sep 14, 2007, at 10:34 AM, Brian Rosen wrote:
>
> > One of the uses for HELD is for an end device to obtain its 
> > location.  The
> > recommendations in ecrit-phonebcp say that the end device should get its
> > location when it boots, periodically thereafter, and as it makes an
> > emergency call.  The time to complete the operation doesn't matter in 
> > the
> > first two cases, but does at call time.
> >
> > Location sent by value should be protected from eavesdropping.  TLS 
> > is of
> > course the mechanism of choice for HELD. Unless we change our position,
> > we've stated that the security of the reference is the same as the 
> > value.
> > That means getting a reference doesn't help; you would want to 
> > protect the
> > transfer of the reference with TLS.
> >
> > What should the recommendation be for the TLS connection between the
> > endpoint and the HELD server?  Seems like we have two bad choices:
> > 1. The endpoint maintains a persistent TLS connection.  This seems
> > impossible for a LIS to maintain, and wasteful for the device
> > 2. We incur very long time to establish the TLS session at call time.  I
> > think this is currently something in the 1/2 second or more range for a
> > typical phone like embedded controller, sometimes much more.  That is 
> > WAY
> > too long for emergency call, where we're attempting to keep call set 
> > up in
> > the 2 seconds from dial to ring.
> >
> >
> > I don't have an answer here.  We don't use TLS with the other LCPs; 
> > we have
> > other mechanisms that protect the privacy to various degrees.  TLS is an
> > excellent mechanism for this purpose.  I just don't know how to deal 
> > with
> > the setup time.
> >
> > Brian
> >
> >
> >
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv at ietf.org
> > https://www1.ietf.org/mailman/listinfo/geopriv
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv at ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv



_______________________________________________
Geopriv mailing list
Geopriv at ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv