Subject: [core] Ticket #395 - CoAP over TCP: Session Resumption

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 25 Mar 2016 20:05:22 +0100

In https://trac.tools.ietf.org/wg/core/trac/ticket/395 Klaus provided
feedback for the CoAP over TCP draft and wrote:

"
Should each connection be independent from all other connections, or
should it be possible to set up a connection (e.g., registering to
observe multiple resources), disconnect and resume the connection at a
later time?
(I'm leaning towards independent connections.)
"

When DTLS / TLS client communicates with a server then it typically
establishes a session cache to allow session resumption. This is a
feature that is recommended to be used in the DTLS profile document.
There is also an additional version of the session resumption that does
not require the server to maintain any session state but the state is
stored in a ticket, cached at the client and later presented. This
feature is called 'session resumption without server-side state' and
defined in RFC 5077.

In any case, if there is already cached information established from a
prior exchange then the client should try to re-use that information to
accelerate the TLS handshake. The performance benefit are large when a
ciphersuite with public key cryptography is used during the full handshake.

My recommendation is to follow the guidance given in the DTLS profile. I
do, however, believe it would be useful to reference the DTLS profile
draft and to reference the appropriate section.

Did I correctly address your feedback?

Ciao
Hannes

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 28 Mar 2016 18:33:52 +0200

Hannes Tschofenig wrote:
> establishes a session cache to allow session resumption. [...]

To clarify, the question is about sessions at the CoAP level, not at
the DTLS/TLS level.

Should it be possible to send a CoAP request, close the TCP
connection, reconnect and receive the response?

Klaus

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 28 Mar 2016 18:44:39 +0200

> connection, reconnect and receive the response?

Without a checkpointing protocol, this is hard to ensure.

The requesting endpoint cannot be really sure that its request made it
before the connection closure.  Similarly, the responding end might have
to resend the response after resumption.  Finally, the server could have
lost the state in the time there was no connection.
Similarly, the client might have crashed between the time it received
the response and was able to process it.

(A true session layer protocol can solve this.  But there seems to be a
reason these are rarely used in the Web today.)

I don't mind if someone wants to work on such a session layer protocol,
but this should not be part of base CoAP-over-TCP; the CoAP-level
protocol state should share the fate of the TCP connection.

Grüße, Carsten

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 28 Mar 2016 18:46:32 +0200

> protocol state should share the fate of the TCP connection.

+1

Klaus

---

From: Christian Groves <[email-masked]>
Date: Tue, 29 Mar 2016 18:07:46 +1100

My understanding is that TLS1.3 
(https://tools.ietf.org/html/draft-ietf-tls-tls13-12)is deprecating 
session resumption. So it may not be good to rely on that mechanism.

Regards, Christian

On 26/03/2016 6:05 AM, Hannes Tschofenig wrote:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core