Re: [tsvwg] DTLS 1.3 over SCTP

[Magnus Westerlund <[e-mail]>]

Hi,

>
> >  Otherwise, I think it is good that RFC 6083 are being fixed for its security issues unless completely replaces by a more capable solution. However, this draft it does not address all the requirements to our understanding that 3GPP has on a DTLS based security solution. The short-commings are the following:
> >
> >     • Do not support sufficiently large protected message sizes. As discussed in this thread the theoretical maximum message sizes for some of 3GPP application protocols are above 144 kb and even as large as 500 kb.
> >     • Periodic re-authentication of the peer
> >     • Forward secrecy rekeying, like re-running differ-hellman exchange, which is not done by the DTLS 1.3 keyupdate mechanism.
>
> Any idea how that last two goals are achieved by using TLS 1.3 or DTLS 1.3? Or were these
> features just dropped when getting rid of re-negotiation?
> MW: TLS 1.3 dropped these capabilities when re-negotiation was removed. I think the main reason is that no one was there and pushing for long lived use cases. In the web world there are rarely any real issue with dropping the connection and forcing the client to reconnect if one runs into these needs. SCTP application clearly has other expectations, especially the applications 3GPP have for it.
> So those two later issues and the lack for any solution in DTLS 1.3 is why we defined the parallel DTLS Connection procedure.

Doesn't provide (D)TLS forward secrecy? Where are the requirements for re-negotiation coming from? Was there a liaison statement making that requirement clear?

MW: Yes, the initial DTLS handshake will provide forward secrecy assuming the right handshake algorithms are used, like (EC)DHE. However, if one uses key-update that new transport key does not have all what might be considered forward secrecy properties. If an attacker manages to break or exfiltrate a particular transport key, the attacker will be able to continue to have access to the DTLS connection for the rest of its life time as the endpoint’s new key is provided protected by the old (broken) key. I do note that DTLS 1.3 Key-update will not allow to determine what the keys where in any transport key epoch before the one that was first broken. Note the more detailed wording below on these properties.
The basis of this requirement is good modern practices and as we have documented in the security consideration section of SCTP/DTLS this exists as recommendation from national security organizations. https://www.ietf.org/archive/id/draft-ietf-tsvwg-dtls-over-sctp-bis-06.html#name-security-considerations

”(D)TLS 1.3 [RFC8446<https://www.ietf.org/archive/id/draft-ietf-tsvwg-dtls-over-sctp-bis-06.html#RFC8446>] discusses forward secrecy from (EC)DHE, Key Update, and tickets/resumption. Forward secrecy limits the effect of key leakage in one direction (compromise of a key at time T2 does not compromise some key at time T1 where T1 < T2). Protection in the other direction (compromise at time T1 does not compromise keys at time T2) can be achieved by rerunning (EC)DHE. If a long-term authentication key has been compromised, a full handshake with (EC)DHE gives protection against passive attackers. If the resumption_master_secret has been compromised, a resumption handshake with (EC)DHE gives protection against passive attackers and a full handshake with (EC)DHE gives protection against active attackers. If a traffic secret has been compromised, any handshake with (EC)DHE gives protection against active attackers.

The document “Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement” [RFC7624<https://www.ietf.org/archive/id/draft-ietf-tsvwg-dtls-over-sctp-bis-06.html#RFC7624>] defines key exfiltration as the transmission of cryptographic keying material for an encrypted communication from a collaborator, deliberately or unwittingly, to an attacker. Using the terms in RFC 7624, forward secrecy without rerunning (EC)DHE still allows an attacker to do static key exfiltration. Rerunning (EC)DHE forces and attacker to dynamic key exfiltration (or content exfiltration).

When using DTLS 1.3 [RFC9147<https://www.ietf.org/archive/id/draft-ietf-tsvwg-dtls-over-sctp-bis-06.html#RFC9147>] AEAD limits and forward secrecy can be achieved by sending post-handshake KeyUpdate messages, which triggers rekeying of DTLS. Such symmetric rekeying gives significantly less protection against key leakage than re-running Diffie-Hellman as explained above. After leakage of application_traffic_secret_N, an attacker can passively eavesdrop on all future data sent on the connection including data encrypted with application_traffic_secret_N+1, application_traffic_secret_N+2, etc. Note that Key Update does not update the exporter_secret.

DTLS/SCTP is in many deployments replacing IPsec. For IPsec, NIST (US), BSI (Germany), and ANSSI (France) recommends very frequent re-run of Diffie-Hellman to provide forward secrecy and force attackers to dynamic key extraction [RFC7624<https://www.ietf.org/archive/id/draft-ietf-tsvwg-dtls-over-sctp-bis-06.html#RFC7624>] ANSSI writes "It is recommended to force the periodic renewal of the keys, e.g., every hour and every 100 GB of data, in order to limit the impact of a key compromise." [ANSSI-DAT-NT-003<https://www.ietf.org/archive/id/draft-ietf-tsvwg-dtls-over-sctp-bis-06.html#ANSSI-DAT-NT-003>]”


So 3GPP has not expressed these requirements in any of the LS we have received. My understanding is that we have considered necessary requirements for the applications and their properties to meet modern security recommendations. John is on vacation, but I will see if I can learn if there exists some 3GPP documentation on requirements that I can point to, or if anyone else that can contribute their view on 3GPP.
I hope you see that forward secrecy and the possibility to re-run (EC)DHE exchanges periodically is quite relevant to minimize the impact of any breach if it would occur for this very long lived SCTP associations that these 3GPP applications are using as well as for any other usage of this security mechanism.
Cheers
Magnus