Hi, We are working on RFC6038bis (DTLS/SCTP) with the goal to remove the user message size limitation, mandate more modern DTLS versions (DTLS 1.2 or 1.3 only), and mandate SHA-256 or stronger in SCTP-AUTH.
https://datatracker.ietf.org/doc/draft-westerlund-tsvwg-dtls-over-sctp-bis/ 3GPP use cases for DTLS/SCPT are semipermanent connections lasting months or even years. Interruptions are not ok. We have noticed the following issues: - TLS 1.2 suggests a Session ID lifetime of 24 hours. We note that the suggestion is not normative and has been removed in TLS 1.3. - With very long connection lifetimes, it becomes important with frequently mutual authentication, and frequent rekeying of DTLS and SCTP-AUTH, preferably with (EC)DHE. -- In DTLS 1.2, frequent mutual authentication and (EC)HDE-based rekeying of DTLS and SCTP-AUTH can be accomplished with frequent renegotiation followed by calling the exporter. Is mandating use of RFC 5745 and following the recommendations in RFC 7525 secure enough or is more profiling needed? https://security.stackexchange.com/questions/24554/should-i-use-ssl-tls-renegotiation -- In DTLS 1.3, renegotiation is gone and there is no real replacement: frequent client authentication can be achieved Post-Handshake but there is no Post-Handshake server authentication. Frequent symmetric rekeying can be achieved with KeyUpdate, but not frequent (EC)DHE. Furthermore, after rekeying with KeyUpdate, the exporter_secret does not change so to derive frequent keys for SCTP-AUTH, a sequence number or similar would have to be concatenated to the exporter label and even then SCTP-AUTH would not get forward secrecy. How do we solve this issues? Or are they solved? If not, would the TLS WG be positive to work on solving them. Short term DTLS 1.2 will likely be used as DTLS 1.3 is not published yet. Long term DTLS 1.3 is the only solution. Cheers, John _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
