[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cf-dev] Sharing DTLS session state among multiple nodes
|
Hi all,
just to get me up to date: DTLS is still the focus, not TLS?
> 2)
If we focus on DTLS, RFC 6347, 4.1.2.1 MAC, and 4.1.2.7 Invalid Record
recommend to silently ignore (most) errors (at least as far as I read and understand it).
Please also consider, that, caused by "spoofing" not any "error" should close the session,
otherwise the devise may starve (DoS)
So there will be only very rare cases, when a "fatal alert" will be send and the other side
will trust that.
Mit freundlichen Grüßen / Best regards
Achim Kraus
Bosch Software Innovations GmbH
Communications (INST/ESY1)
Stuttgarter Straße 130
71332 Waiblingen
GERMANY
www.bosch-si.de
www.blog.bosch-si.com
Tel. +49 711 811-58139
achim.kraus@xxxxxxxxxxxx
Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B
Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn
-----Ursprüngliche Nachricht-----
Von: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx] Im Auftrag von Simon Bernard
Gesendet: Mittwoch, 21. September 2016 18:04
An: Californium (Cf) developer discussions <cf-dev@xxxxxxxxxxx>
Betreff: Re: [cf-dev] Sharing DTLS session state among multiple nodes
This seems to me a better approach than the previous one :) (trying to persist ConnectionStore).
Some remarks/questions below :
1) Why LeastRecentlyUsedCache.class is no more threadsafe ?
2) The TLS spec[1] say :
"Error handling in the TLS Handshake protocol is very simple. When an error is detected, the detecting party sends a message to the other party. Upon transmission or receipt of a fatal alert message, both parties immediately close the connection. Servers and clients MUST forget any session-identifiers, keys, and secrets associated with a failed connection. Thus, any connection terminated with a fatal alert MUST NOT be resumed."
Should we implement this ?
3) If we implement 2) the "InMemoryConnectionStore.find()" should always look in the shared store (SessionCache) and should not check before in the connections map in memory.
4) Not directly linked to this branch but the RF5077[2] is another way to resume session:
"This mechanism is useful in the following situations:
1. servers that handle a large number of transactions from different users
2. servers that desire to cache sessions for a long time
3. ability to load balance requests across servers
4. embedded servers with little memory"
Here[3][4] are interesting posts about session resumption and Forward Secrecy [3][4].
Simon
[1]https://tools.ietf.org/html/rfc5246#section-7.2.2
[2]https://tools.ietf.org/html/rfc5077
[3]https://timtaubert.de/blog/2014/11/the-sad-state-of-server-side-tls-session-resumption-implementations/
[4]https://blog.twitter.com/2013/forward-secrecy-at-twitter-0
Le 21/09/2016 à 12:04, Hudalla Kai (INST/ESY1) a écrit :
> Hi,
>
> some months ago I had started to work on introducing means to Scandium
> to be able to share state of an established DTLS session (crypto
> params) among multiple nodes.
>
> The idea is to allow for clients being able to resume a DTLS session
> (using an abbreviated handshake) with another node than the one the
> session has been originally been established with (e.g. after the original node has crashed).
>
> I have added the code to the session_cache branch based on current
> master [1]. There also has been a question raised around that topic [2].
>
> I would be interested in getting some feedback whether you think this
> is a useful addition and you could put this to work in your environment.
>
> [1] https://github.com/eclipse/californium/tree/session_cache
> [2] https://github.com/eclipse/californium/issues/89
>
_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cf-dev
