Change:
From URL Already fixed on master. I think the idea here is to forbid the use of 0x01, treating it as a reserved value (due to legacy, pre-standard implementations). I think you're looking in the wrong place, actually. There are two levels of constraint here: len(EKTCiphertext) < 256 - len(Epoch) - len(SPI) len(SRTPMasterKey) < len(EKTCiphertext) - len(SSRC) - len(ROC) - len(SRTPMasterKeyLength) - Cipher.Overhead So we can make the following bounds... EKTCiphertext = 1251BYTE ; 255 - 2 - 2 SRTPMasterKey = 1242BYTE ; 251 - 1 - 4 - 4 - Overhead=0 ... but the maximum SRTPMasterKey will never be maximized in practice because the crypto overhead will be non-zero. And we can't really nail it down here in the ABNF because different ciphers will have different overhead. In any case, I have added the above constraints. I agree. In fact, the natural order of operations is to form the SRTP packet, then compute and append the EKT tag. I have made this change. Already fixed on master. I don't think this is unclear, but I have adapted the text to say that the implementation MAY continue normal SRTP/SRTCP processing. I have added a definition in {{EKT}}. Already fixed on master. The word "immediately" appears nowhere here. The sequencing seems clear: Receipt of a new EKTKey should trigger an update to the SRTP Master Key, but you don't start using that for 250ms. I have edited to clarify. I have removed the remaining mentions of SRTCP. Edited to: "it is RECOMMENDED that the FullEKTField be transmitted in three consecutive packets" This is covered by the "new receiver" and "rekey" cases. I have left this as-is. As noted above, the statement in §4.5 is not inconsistent. And your notion of "fate sharing" is pretty strict here. The intent is that the keying packets are following the same general path (in terms of media servers, etc.) as the media. It's not a perfect match. I have left this as-is. I don't know the answer on the merits, but it's an application decision anyway. I have added a note that applications will need to decide what latency/bandwidth tradeoff they want to make. On master, this table has been shifted down by one, so this change is no longer needed. Re-sending my initial comments, as only one of the 17 were addressed in subsequent revisions. While no single comment rises to the level of a DISCUSS-worthy issue, several of these are moderately severe. I would appreciate either a response to each comment, or a corresponding change in the document. Thanks to the work that everyone has put in on getting an EKT mechanism specified and finalized. I have a handful of comments that I would like to see considered prior to publication of the document. Nit: "...participant to securely..." Shouldn't this be "%x01 / %x03-ff" ? I think this either needs to be "1*255BYTE", or we need text that explicitly indicates that an SRTPMasterKeyLength value of 0x00 means "256 bytes." Probably the former. I think this is even further constrained by the fact that EKTCiphertext is limited to 256 bytes, and contains the SRTPMasterKeyLength, SRTPMasterKey, SSRC, and ROC (and is not compressed) -- which means the SRTPMasterKeyLength can't be more than (256 - 1 - 4 - 4 =) 247 bytes. So perhaps "1*247BYTE" is more appropriate? Why? This seems unnecessary and unnecessarily complicated. If the order of operations has an impact on the bits on the wire (I don't see how it does?), then please include some explanatory text here that clarifies the reason for this constraint. Nit: s/ShortEKFField/ShortEKTField/ I can see implementors easily interpreting this as requiring them to discard the RTP payload as well. If that's not the intention (I don't think it is), consider adding text like "The FullEKTField is removed from the packet then normal SRTP or SRTCP processing occurs." This is the first appearance of the phrase "EKT tag," which never seems to be properly defined. I presume this is meant to be the combination of the EKT Ciphertext and the SPI? In any case, please clearly define this term somewhere, preferably before using it the first time. The parenthetical phrase appears to be missing something here. Nit: "...either... is exceeded..." Nit: "...implementations need..." I suppose it's not terribly important for interop, but the implication that this change takes place immediately seems to contradict the 250 ms period specified in §4.2.1. Perhaps a few words here about how these two normative statements are intended to interact would save implementors a bit of grief. After reading this far, I was quite surprised to find this qualification. If this is the intention for this document, please adjust the rest of the text to match. Some examples follow. Nit: "...containing..." (alternately, remove "be transmitted" -- both make a grammatically correct sentance) More substantially -- under "New sender:", I'm a little surprised that there isn't any mention of other senders re-keying in response to a new sender joining. In the vast majority of conferences, when a sender joins, that same entity generally will also be a receiver. It seems this should trigger other senders to include the key in their next packet. Is this actually true? Going back to the 250 ms period specified in §4.2.1, it seems that the master key is sent out in packets pretty far removed from those it actually protects. Between this and the inconsistency I mention in §4.5 above, this increasingly feels like maybe there were two different ways of reasoning about the timing of sending a master key versus the timing of actually using it. Does the text in §4.2.1 perhaps represent an outdated notion of how this is intended to work? Is this "100ms" correct?  Assuming, say, the use of Opus at voice quality with 20 ms packets, this is taking packets on the order of 40 bytes in length and tacking on something like 20 to 30 bytes to every fifth packet. That's an increase in overall stream size on the order of roughly 15% to 20%. At the same time, when using real-time video, intra frames are going to happen roughly every 500 ms to 1500 ms. If a cadence on that order is okay for audiovisual streams, I have to imagine it's okay for audio streams. So, to clarify: is this "100ms" a typo for "1000 ms"? Section 5.2.1 reserves "0" as well. I suspect we want to replicate that reservation in this table.

Discussion:
endpoint can securely send its SRTP master key and current SRTP rollover counter to the other participants in the session.  This data furnishes the information needed by the receiver to instantiate an <del> SRTP/SRTCP receiver context. </del> <ins> SRTP receiver context. </ins> EKT can be used in conferences where the central media distributor or conference bridge cannot decrypt the media, such as the type defined

4.1. The EKTField uses the format defined in tag-format-base for the <del> FullEKTField and ShortEKTField. </del> <ins> FullEKTField and ShortEKTField.  The EKTField appended to an SRTP packet can be referred to as an "EKT tag". </ins> The following shows the syntax of the EKTField expressed in ABNF <del> RFC5234.  The EKTField is added to the end of an SRTP or SRTCP packet.  The EKTPlaintext is the concatenation of SRTPMasterKeyLength, SRTPMasterKey, SSRC, and ROC in that order.  The EKTCiphertext is computed by encrypting the EKTPlaintext using the EKTKey.  Future extensions to the EKTField MUST conform to the syntax of ExtensionEKTField. </del> <ins> RFC5234.  The EKTField is added to the end of an SRTP packet.  The EKTPlaintext is the concatenation of SRTPMasterKeyLength, SRTPMasterKey, SSRC, and ROC in that order.  The EKTCiphertext is computed by encrypting the EKTPlaintext using the EKTKey.  Future extensions to the EKTField MUST conform to the syntax of ExtensionEKTField. </ins> These fields and data elements are defined as follows:

tag is appended. Rollover Counter (ROC): On the sender side, this is set to the <del> current value of the SRTP rollover counter in the SRTP/SRTCP context associated with the SSRC in the SRTP or SRTCP packet.  The length of this field is 32 bits. </del> <ins> current value of the SRTP rollover counter in the SRTP context associated with the SSRC in the SRTP packet.  The length of this field is 32 bits. </ins> Security Parameter Index (SPI): This field indicates the appropriate EKTKey and other parameters for the receiver to use when processing

4.3. <del> At any given time, each SRTP/SRTCP source has associated with it a single EKT parameter set.  This parameter set is used to process all </del> <ins> At any given time, each SRTP source has associated with it a single EKT parameter set.  This parameter set is used to process all </ins> outbound packets, and is called the outbound parameter set for that SSRC.  There may be other EKT parameter sets that are used by other <del> SRTP/SRTCP sources in the same session, including other SRTP/SRTCP sources on the same endpoint (e.g., one endpoint with voice and video might have two EKT parameter sets, or there might be multiple video sources on an endpoint each with their own EKT parameter set).  All of the received EKT parameter sets SHOULD be stored by all of the participants in an SRTP session, for use in processing inbound SRTP and SRTCP traffic.  If a participant deletes an EKT parameter set (e.g., because of space limitations, then it will be unable to process Full EKT Tags containing updated media keys, and thus unable to receive media from a particpant that has changed its media key. </del> <ins> SRTP sources in the same session, including other SRTP sources on the same endpoint (e.g., one endpoint with voice and video might have two EKT parameter sets, or there might be multiple video sources on an endpoint each with their own EKT parameter set).  All of the received EKT parameter sets SHOULD be stored by all of the participants in an SRTP session, for use in processing inbound SRTP traffic.  If a participant deletes an EKT parameter set (e.g., because of space limitations, then it will be unable to process Full EKT Tags containing updated media keys, and thus unable to receive media from a particpant that has changed its media key. </ins> Either the FullEKTField or ShortEKTField is appended at the tail end of all SRTP packets.  The decision on which to send when is specified

When an SRTP packet is sent with a FullEKTField, the EKTField for that packet is created as follows, or uses an equivalent set of <del> steps.  The creation of the EKTField MUST precede the normal SRTP packet processing. </del> <ins> steps. </ins> The computed value of the FullEKTField is appended to the end of the SRTP packet, after the encrypted payload.

If a source has its EKTKey changed by the key management, it MUST also change its SRTP master key, which will cause it to send out a <del> new FullEKTField.  This ensures that if key management thought the EKTKey needs changing (due to a participant leaving or joining) and communicated that to a source, the source will also change its SRTP master key, so that traffic can be decrypted only by those who know the current EKTKey. </del> <ins> new FullEKTField and eventually begin encrypting with it, as defined in outbound-processing.  This ensures that if key management thought the EKTKey needs changing (due to a participant leaving or joining) and communicated that to a source, the source will also change its SRTP master key, so that traffic can be decrypted only by those who know the current EKTKey. </ins> 4.6.

The three cases are: <ins> In general, sending EKT tags less frequently will consume less bandwidth, but increase the time it takes for a join or rekey to take effect.  Applications should schedule the sending of EKT tags in a way that makes sense for their bandwidth and latency requirements. </ins> 5. This document defines an extension to DTLS-SRTP called SRTP EKTKey Transport which enables secure transport of EKT keying material from the DTLS-SRTP peer in the server role to the client.  This allows <del> 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. </del> <ins> those peers to process EKT keying material in SRTP 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. </ins> In cases where the DTLS termination point is more trusted than the media relay, the protection that DTLS affords to EKT key material can