Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cf-dev] Sharing DTLS session state among multiple nodes
TLS and DTLS 1.3 are still something in it's infancy and will need to support 1.2 for a decade I think..

--
Julien Vermillard

On Thu, Sep 22, 2016 at 9:05 AM, Hudalla Kai (INST/ESY1) <Kai.Hudalla@xxxxxxxxxxxx> wrote:
Julien,

thanks for the hint regarding adoption of RFC 5077 and the fact that session resumption will be done differently in TLS 1.3.
Given the adoption of RFC 5077 in several (D)TLS libs I would actually currently tend to adopt it in Scandium as well. 

However, if TLS 1.3 is "around the corner" then it might be questionable whether it is worth the effort.
What's your impression regarding status and adoption of TLS 1.3? My feeling is that we will be using TLS 1.2 for still some time...

What do you guys think? 
-- 
Mit freundlichen Grüßen / Best regards

Kai Hudalla
Chief Software Architect

Bosch Software Innovations GmbH
Schöneberger Ufer 89-91
10785 Berlin
GERMANY
www.bosch-si.com

Registered office: Berlin, Register court: Amtsgericht Charlottenburg,
HRB 148411 B;
Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn

On Mi, 2016-09-21 at 20:34 +0200, Julien Vermillard wrote:

On Wed, Sep 21, 2016 at 6:52 PM, Simon Bernard <contact@xxxxxxxxxxxxxxx> wrote:
Le 21/09/2016 à 18:19, Hudalla Kai (INST/ESY1) a écrit :
Thanks for the excellent feedback, Simon :-)

On Mi, 2016-09-21 at 18:04 +0200, Simon Bernard wrote:
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 ?

I thought that it would make sense to leave that to the context in which the
cache is used in case you find other ways of making sure that a cache is
always only accessed by a single thread.
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 ?

You mean that we need to make sure that a session is removed from the cache
in such cases, right? I guess we should do that.

Exactly.

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.

To make sure that we do not use a "stale" session that has been removed from
the cache by another node, right?

Right.

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


Thanks for the links. I already had taken a look at RFC5077 but my concern is
that we will probably not find many client implementations supporting it,
right?

This begin to be implemented. gnutls support it and wolfssl seems to support it too.

OpenSSL and mbed support it also.
But for TLS 1.3 both methods are gone ;) https://tlswg.github.io/tls13-spec/#rfc.section.2.2




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

_______________________________________________
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


_______________________________________________
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


_______________________________________________
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

_______________________________________________
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

Back to the top