Re: [core] Connection ID

[Hannes Tschofenig <[e-mail]>]

Hi Klaus,

Normally, you would not use post handshake authentication (DTLS/TLS 1.3) or renegotiation (DTLS/TLS 1.2) in an IoT context since the expectation is that you start with mutual authentication right away.

In TLS (1.2 and 1.3) there is no epoch value but you can still have these handshake messages. Hence, making rules that relate to epoch values just gets us into trouble*.

From your design vision point of view it is better to restrict the use of DTLS/TLS features.

Ciao
Hannes

*: I wonder whether we said anything about this issue in the CoAP over TCP/TLS draft....

-----Original Message-----
From: Klaus Hartke [mailto:[e-mail]]
Sent: 22 November 2017 16:48
To: Hannes Tschofenig
Cc: Carsten Bormann; Hannes Tschofenig; [e-mail] WG
Subject: Re: [core] Connection ID

Hannes Tschofenig wrote:
> Of course, there are security relevant events that can happen in a TLS/DTLS exchange, such as post-handshake authentication (DTLS 1.3) or renegotiation (DTLS 1.2), that should be of interest to the application. What exactly the applications do in response to such an event is application dependent. I don't think the CoAP spec should mandate a specific behaviour.

I would like CoAP over DTLS to be secure by default.

Application builders should be able to just switch on "coaps://" for their applications and be reasonably secure without performing an in-depth analysis of possible security holes related to epoch changes.
Of course, an application builder who wants to perform an in-depth analysis and implement their own behavior for security relevant events should be able to do that. But I would assume that in the majority of cases application builders will just use the defaults provided by the (most likely application-agnostic) CoAP implementation.

I understand that not all DTLS implementations expose enough information to react to epoch changes. What would be a good, realistic default behavior that application-agnostic CoAP implementations should implement to make applications secure by default?

Klaus
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.