DTLS requires manual key management to distribute long-term session keys. These can be shared secrets for TLS-PSK methods, or certificates for other TLS methods.
I think you mean "distribution of long-term credentials" here. In (D)TLS the session keys are are fresh for each session (via the use of client.random and server.random).
Section 2.2: The manual key management for long-term session keys meets the last criteria in this section:
I think you mean "long-term credentials"; (D)TLS session keys are not long-term, they are refreshed on session resume.
Ideally, each long-term key in DTLS is shared only between one server and one client. Each client-server pair shares a unique key, and those keys are (ideally) not re-used across multiple client-server pairs. There aren't many deployments that are smaller scale than two parties.
Even if TLS-PSK is used and the PSKs are re-used across client-server pairs (e.g. RADIUS shared secret practices are replicated in TLS-PSK), the session keys would still be likely to be temporally and globally unique, due to the (D)TLS freshness functionality.
We could say that for PSK methods, the PSK that is used in TLS MUST be the output of the shared secret amplification, and not the original text as entered by the administrator. This method would be a step to addressing the requirements of [RFC4107] Section 2.3. At the minimum, it would increase the attack cost by a fixed factor of (say) 1,000,000.
It might help to articulate the threat model a bit. Are we worried about an offline dictionary attack on the PSK or its precursor, or are we worried about temporal or global uniqueness of the TLS master secret?
-- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/>