Rekeying in (D)TLS 1.3 does not update the exporter_secret

[emanjon]

This is another major problem for SCTP/DTLS and other semi-permanent uses of DTLS 1.3 uncovered during the work on RFC6083bis.

https://github.com/gloinul/draft-westerlund-tsvwg-dtls-over-sctp-bis

The current text is RFC6083bis is a quite unfortune (We would really like to encourage and recommend use of DTLS 1.3):
"For upper layer protocols where frequent re-run of Diffie-Hellman, rekeying of SCTP-AUTH, and server reauthentication is required and creating a new SCTP connection with DTLS 1.3 to replace the current is not a viable option it is RECOMMENDED to use DTLS 1.2."

SCTP/DTLS uses the TLS exporter to derive keys for SCTP-AUTH. SCTP/DTLS also uses SCTP-AUTH to handle when DTLS traffic keys from old epochs can be forgotten. With DTLS 1.2, renogotiation with ECDHE updates the exporter_secret. In DTLS 1.3, KeyUpdate does not update the exporter_secret.

RFC6083bis is now considering using a "hack" of adding the epoch value (or other info) to the DTLS 1.3 exporter context to at least get different SCTP-AUTH keys for each epoch. This would solve any "AEAD limits" problems with HMAC-SHA256 (we don't know what these limits would be but keying at some point seems good). It does not provide good protection against key leakage/compromise as the exporter_secret must be stored for years. A future solution for SCTP/DTLS 1.3 should make sure that an attacker is forced to do dynamic key exfiltration {{RFC7624}}.

gloinul/draft-westerlund-tsvwg-dtls-over-sctp-bis#52

The RFC6083bis authors discussed this today and would like to ask if DTLS 1.3 could provide the feature that the output of the TLS exporter changes after a KeyUpdate?

While the epoch limitations #249 are purely DTLS, this issue is inherited from TLS 1.3.

[ekr]

I agree that that text is unfortunate, but I feel like I'm kind of misunderstanding the situation.

Because KeyUpdate does not introduce new entropy, I would have expected users of exporters to export a key once and then to generate fresh keys as needed in an analagous fashion to the TLS transport key ladder rather than by re-exporting, which seems like it has risks of things getting desynchronized (for instance, how does the exporter work when you are sending with epoch X but receiving with X+1). What am I missing?

[emanjon]

That is a good point. RFC6038 does (as far as know) and RFC6083bis intends to control DTLS rekeying to sync the epoch used in DTLS with the "epoch" used for the SCTP-AUTH key. DTLS/SCTP cannot as far as we currently see follow the 2 minute default MSL requirement in DTLS. Very frequent rekeying (minutes) would lead to a large number of keys having to be stored. As KeyUpdate updates traffic keys I think that our exporting ideas do not work at all. DTLS/SCTP has to do like you suggest (export once and do key ladder) or setup new DTLS connections.

[emanjon]

FYI. We have now run into quite many problems with the interworking of semi-permanent DTLS/SCTP connections (lasting years) and DTLS 1.3:

• No Diffie-Hellman rekeying
• No post-handshake server authentication
• No rekeying of the exporter_secret
• 2^40.5 packets limit
• 2 minute MSL requirement
• 2^38.5 byte SCTP user message size limit

Our initial plan was to just replace DTLS 1.2 with DTLS 1.3, leave DTLS/SCTP as is, but as the problems keep adding up we are now considereing quite big changes to DTLS/SCTP 1.3 to make this work:
gloinul/draft-westerlund-tsvwg-dtls-over-sctp-bis#52

Using new DTLS connections instead of KeyUpdate could potentially address the first five, but is a significant change.

[chris-wood]

@emanjon with the change to track epochs using 64 bits in #255, can we now include the epoch in exported secrets to address this problem?

[emanjon]

@chris-wood As I just wrote in #249, we have restructured DTLS/SCTP (RFC6083bis) to solve all the issues we encountered with DTLS 1.3. DTLS 1.3 does not need to do any change to the exporter for the sake of DTLS/SCTP. As @ekr points out there are two different epochs to consider, using them both in the exporter could maybe lead to synchronization problems. It also does not provide the security properties of current IPsec deployments where attackers are forced to do dynamic key exfiltration instead of just static key exfiltration [RFC7624]. For very long-lived connections I think dynamic key exfiltration is a must. I think we can probably close this issue.

[chris-wood]

Thanks, @emanjon! Closing.