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

[Hannes Tschofenig <[e-mail]>]

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
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/geopriv
>
>
> _______________________________________________
> Geopriv mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/geopriv



_______________________________________________
Geopriv mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/geopriv