Clarify/revise language around epochs in section 9.1.1

[jimsch]

Current text is:

The following rules are added for matching an Acknowledgement message or Reset message to a Confirmable message, or a Reset message to a Non-confirmable message: The DTLS session MUST be the same, and the epoch MUST be the same.

However this does not really make any sense in terms of what DTLS does for authentication. The rule was initially created so that if the authentication data changed, which forces an epoch change, then the message would not be matched. The problem is that epochs can change for other reasons such as simple re-keys which do not change any of the authentication data.

When a re-authentication is done in TLS, then there is a large discussion about what this means. One interpretation is that the new authentication is added to the existing one. In which case not matching may not make sense. The other interpretation is that the new authentication replaces the old one.

Under each of these situations it does not really make sense for the client to have to add this rule for matching. The sequence of events would be:

• Client sends request
• Client-server does a new authentication set
• Client receives response from server

The server should have checked that the authentication was fine when creating the response and there is no change in the client that is at the other end of the pipe.

Recommend: Remove all of the language about epochs from RFC 7252.

[ektrah]

Small clarification: The rule was initially created because noone had performed a security analysis under which condition it's OK to send request and response(s) in different epochs. The change of authentication data is just one issue that shows that a careful security analysis is needed.

[ektrah]

https://mailarchive.ietf.org/arch/msg/core/biDJ8n4w0kBQATzyh9xHlKnGy1o etc. pp.

[ektrah]

https://mailarchive.ietf.org/arch/msg/core/TsyyKIHQ1FJtAvAo0ODNEt2Ileo etc. pp.

[boaks]

Let me try to add some practical notes:

For the most request/response pairs the time span is short, and therefore the probability that something changes according the DTLS layer is low.

The most pain comes with RFC7641, observe/notify. With that, the time span gets much larger. Assuming longer quiet periods, NAT timeouts occur too often. Though that pattern was used for LwM2M (data reporting), the most of the discussion have been in the OMA repo (at least, I feel so :-) ). For Eclipse/Californium we introduced therefore a (hopefully) flexible and customizable matcher-interface. With that, it's up to the application, what is considered to be save enough or not.

For coap-servers there is a left-risk, that the response is sent, when the IP is already "assigned" to a different client (e.g. after a NAT timeout of the original client). Therefore Californium uses that matcher-interface not only for incoming responses, it's also used for outgoing ones. For LwM2M, where the coap-roles are also used exchanged (initial the LwM2M server is a coap-server, after the registration exchange, the LwM2M-server acts as coap-client), that dtls-context-matching is even extended to all messages, e.g. no coap-data-request is sent to a device, if the context doesn't still match the one of the registration message of that device.

[sbernard31]

Recommend: Remove all of the language about epochs from RFC 7252.

:+1:

[sbernard31]

Maybe a bit out of the topic of this issue.

@boaks raises that particular attention should be taken for RFC7641 observe/notify case:

For the most request/response pairs the time span is short, and therefore the probability the something changes according the DTLS layer is low. The most pain comes with RFC7641, observe/notify. With that, the time span gets much larger. Assuming longer quiet periods, NAT timeouts occur too often.

Regarding this topic about matching request/response for observe/notify. It could maybe have a very similar issue with coap over tcp.

The RFC8323 says :

 Responses MUST be returned over the same connection as the originating request. 

Which is fine for "classic" CoAP request/response but maybe not for observe/notify.

RFC-9006§4.3 - TCP Connection Lifetime says :

One approach for infrequent data transfer is to use short-lived TCP connections.
Instead of trying to maintain a TCP connection for a long time, it is possible that short-lived
connections can be opened between two endpoints, which are closed if no more data 
needs to be exchanged. For use cases that can cope with the additional messages
and the latency resulting from starting new connections, it is recommended to use a sequence
of short-lived connections instead of maintaining a single long-lived connection.

I'm not totally sure but I feel using sequence of short-lived connections could fit the case of an observed device which send notify very infrequently but with current RFC8323 this seems not possible.

This seems to illustrate that the "classic" Request/Response matching is often not very well suited to observe/notify.

[cabo]

I reopened this so further PRs can easily reference this issue.

[sbernard31]

(0953e9d is a very good summary)