Draft: draft-ietf-perc-srtp-ekt-diet

Commentary: 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 ? 
 I have a bunch of comments but really I could live with this like you have it now .
Paragraph (version A):
This document defines an extension to DTLS-SRTP called SRTP EKT Key
Transport which enables secure transport of EKT keying material from
one DTLS-SRTP peer to another.  This allows those peers to process
EKT keying material in SRTP (or SRTCP) and retrieve the embedded SRTP
keying material.  This combination of protocols is valuable because
it combines the advantages of DTLS, which has strong authentication
of the endpoint and flexibility, along with allowing secure
multiparty RTP with loose coordination and efficient communication of
per-source keys.
Paragraph (version B):
This document defines an extension to DTLS-SRTP called SRTP EKT Key
Transport which enables secure transport of EKT keying material from
the DTLS-SRTP peer in the server role to the client.  This allows
those peers to process EKT keying material in SRTP (or SRTCP) and
retrieve the embedded SRTP keying material.  This combination of
protocols is valuable because it combines the advantages of DTLS,
which has strong authentication of the endpoint and flexibility,
along with allowing secure multiparty RTP with loose coordination and
efficient communication of per-source keys.
Paragraph (version A):
This document defines a new TLS negotiated extension called
"srtp_ekt_key_transport" and a new TLS content type called
EKTMessage.
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version A):
The diagram below shows a message flow of DTLS client and DTLS server
using the DTLS-SRTP Key Transport extension.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version B):
extension in its ServerHello containing a cipher selected from among
those advertised by the client.
Paragraph (version B):
extension in its ServerHello, then EKTKey messages MUST NOT be sent
by either the client or the server.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
If an EKTKey message is received that cannot be processed, then the
recipient MUST respond with an appropriate DTLS alert.
Paragraph (version A):
The DTLS ekt_key is sent using the retransmissions specified in
Section 4.2.4.  of DTLS RFC6347.
Paragraph (version B):
message is sent using the retransmissions specified in Section 4.2.4.
of DTLS RFC6347.  Retransmission is finished with an Ack message or
an alert is received.
Paragraph (version A):
IANA is requested to add srtp_ekt_key_transport as a new extension
name to the "ExtensionType Values" table of the "Transport Layer
Security (TLS) Extensions" registry with a reference to this
specification and allocate a value of TBD to for this.  Note to RFC
Editor: TBD will be allocated by IANA.
Paragraph (version A):
IANA is requested to add srtp_ekt_message as an new descriptions name
to the "TLS ContentType Registry" table of the "Transport Layer
Security (TLS) Extensions" registry with a reference to this
specification, a DTLS-OK value of "Y", and allocate a value of TBD to
for this content type.  Note to RFC Editor: TBD will be allocated by
IANA.
Paragraph (version B):
as a new extension name to the "ExtensionType Values" table of the
"Transport Layer Security (TLS) Extensions" registry with a reference
to this specification and allocate a value of TBD to for this.
Paragraph (version B):
as a new entry in the "TLS HandshakeType Registry" table of the
"Transport Layer Security (TLS) Parameters" registry with a reference
to this specification, a DTLS-OK value of "Y", and allocate a value
of TBD to for this content type.