Code change:
This is much more compatible with extensibility patterns in TLS stacks, and in a way that is very forward-compatible with the forthcoming DTLS 1.3, while still being implementable in pre-1.3 stacks. DTLS 1.3 has a notion of post-handshake handshake messages, like and , which are acknoweldged with an message. The framework described here simply sends as yet another post-handshake message. Depends on
r? NAME
I have a bunch of comments but really I could live with this like you have it now.

Related discussion:
text: 5.2. <del> This document defines a new TLS negotiated extension called "srtp_ekt_key_transport" and a new TLS content type called EKTMessage. Using the syntax described in DTLS RFC6347, the following structures are used: If a DTLS client includes srtp_ekt_key_transport in its ClientHello, then a DTLS server that supports this extensions will includes srtp_ekt_key_transport in its ServerHello message.  If a DTLS client includes srtp_ekt_key_transport in its ClientHello, but does not receive srtp_ekt_key_transport in the ServerHello, the DTLS client MUST NOT send DTLS EKTMessage messages.  Also, the srtp_ekt_key_transport in the ServerHello MUST select one and only one EKTCipherType from the list provided by the client in the srtp_ekt_key_transport in the ClientHello. When a DTLS client sends the srtp_ekt_key_transport in its ClientHello message, it MUST include the SupportedEKTCiphers as the extension_data for the extension, listing the EKTCipherTypes the client is willing to use in preference order, with the most preferred version first.  When the server responds in the srtp_ekt_key_transport in its ServerHello message, it MUST include a SupportedEKTCiphers list that selects a single EKTCipherType to use (selected from the list provided by the client) or it returns an empty list to indicate there is no matching EKTCipherType in the clients list that the server is also willing to use.  The value to be used in the EKTCipherType for future extensions that define new ciphers is the value from the "EKT Ciphers Type" IANA registry defined in iana-ciphers. The figure above defines the contents for a new TLS content type called EKTMessage which is registered in iana-tls-content.  The EKTMessage above is used as the opaque fragment in the TLSPlaintext structure defined in Section 6.2.1 of RFC5246 and the srtp_ekt_message as the content type.  The srtp_ekt_message content type is defined and registered in iana-tls-ext. When the Server wishes to provide a new EKT Key, it can send EKTMessage containing an EKTKey with the new key information.  The client MUST respond with an EKTMessage of type ekt_key_act, if the EKTKey was successfully processed and stored or respond with the the ekt_key_error EKTMessage otherwise. The diagram below shows a message flow of DTLS client and DTLS server using the DTLS-SRTP Key Transport extension. Note that when used in PERC I-D.ietf-perc-private-media-framework, the Server is actually split between the Media Distrbutor and Key Distributor.  The messages in the above figure that are "SRTP packets" will not got to the Key Distributor but the other packets will be relayed by the Media Distributor to the Key Distributor. </del> <ins> This document defines a new TLS negotiated extension and a new TLS handshake message type .  The extension negotiates the cipher to be used in encrypting and decrypting EKTCiphertext values, and the handshake message carries the corresponding key. The diagram below shows a message flow of DTLS 1.3 client and server using EKT configured using the DTLS extensions described in this section.  (The initial cookie exchange and other normal DTLS messages are omitted.) In the context of a multi-party SRTP session in which each endpoint performs a DTLS handshake as a client with a central DTLS server, the extensions defined in this session allow the DTLS server to set a common EKT key among all participants.  Each endpoint can then use EKT tags encrypted with that common key to inform other endpoint of the keys it is using to protect SRTP packet.  This avoids the need for many individual DTLS handshakes among the endpoints, at the cost of preventing endpoints from directly authenticating one another. 5.2.1. To indicate its support for EKT, a DTLS-SRTP client includes in its ClientHello an extension of type listing the EKT ciphers the client supports in preference order, with the most preferred version first.  If the server agrees to use EKT, then it includes a extension in its ServerHello containing a cipher selected from among those advertised by the client. The field of this extension contains an "EKTCipher" value, encoded using the syntax defined in RFC5246: 5.2.2. Once a client and server have concluded a handshake that negotiated an EKT cipher, the server MUST provide to the client a key to be used when encrypting and decrypting EKTCiphertext values.  EKT keys are sent in encrypted handshake records, using handshake type .  The body of the handshake message contains an structure: [[ NOTE: RFC Editor, please replace "TBD" above with the code point assigend by IANA ]] The contents of the fields in this message are as follows: If the server did not provide a extension in its ServerHello, then EKTKey messages MUST NOT be sent by either the client or the server. When an EKTKey is received and processed successfully, the recipient MUST respond with an Ack handshake message as described in Section 7 of I-D.ietf-tls-dtls13.  The EKTKey message and Ack must be retransmitted following the rules in Secton 4.2.4 of RFC6347. Note: To be clear, EKT can be used with versions of DTLS prior to 1.3.  The only difference is that in a pre-1.3 TLS stacks will not have built-in support for generating and processing Ack messages. If an EKTKey message is received that cannot be processed, then the recipient MUST respond with an appropriate DTLS alert. </ins> 5.3.