Change:
Does this look like a problem to you guys or am I missing the boat on something ?
Decryption might fail if it's not the right key or if the ROC is old. Yes, that can happen. However, what implementations should do is keep the old and new key and try both. I'm not sure if this is spelled out, but that would be ideal since it's possible to get out-of-order packets and the old key might be needed for the next packet received. No. A sender's transmit key is independent of another sender's transmit key. There's nothing to suggest a relationship to a conference key, except that the conference key is used to encrypt the EKT field. But, one should definitely not re-use an old conference key to transmit packets and conference keys should be discarded fairly soon, because a change in conference key is rather significant (e.g., a user left the conference and media should no longer use any old keys). Yes, by putting yet another auth tag on the packet, but I would not suggest it since the packet is getting large. An alternative is to compute the EKT tag and authenticate that using the E2E cipher. For AES GCM, treat the EKT Field as "additional authenticated data" (AAD). As an implementation challenge, though, I believe that most ciphers assume that all AAD to be included in the AES GCM processing must be in contiguous memory and libsrtp (and I suspect any other such library) does not allocate memory for per-packet processing for good reason (lots of mallocs of varying lengths that must be securely erased), which would be necessary since the other AAD is in the RTP header. But, it wouldn't be too bad if we changed the libsrtp API to allow the application to provide a buffer that the library can use to copy the data from the header and then concatenate the EKT field. The size of that buffer can be prescribed in terms of the size of the RTP header + max length of the EKT field (which is a known size). It is also possible to use a different "alternative initialization vector" (AIV) in the AES Key Wrap logic. By default, the AIV is 0xA65959A6. We could provide alternative values based on the current packet (e.g., effectiveaiv = (ROC XOR seqnum XOR defaultaiv) and put the ROC in the clear (since it's not secret). This would immediately tell the receiving endpoint that the EKT field is bad before we start E2E packet processing. (It would not be useful in detecting HBH manipulation.) However, I don't think we need to do these things. When a packet is received by a receiving endpoint, it will extract the EKT key if the EKT field properly decrypts. It should not immediately assume that's a valid key, though, because that could been produced by another endpoint and thrown in there by the hacker. The endpoint should first attempt to use the key during the E2E decipher phase. If it works, then add it to the front of the key list and set it as the active key. If the key fails to decrypt during E2E processing, then the EKT field was bad and the key should be discarded. So, in the worst case a bogus EKT field results in attempting to decrypt the packet and failing. It's no different than if the hacker manipulated the packet payload anywhere else. Granted, manipulating other places will cause a failure on HBH decryption, but failing on E2E decryption is not significantly worse. Just one more decryption cycle. DoS is achieved either way. (I mention "key list" as I think receivers should keep two old key around for a short time just in case there are out-of-order packets. I don't think timing the retention is important. They older keys could be kept indefinitely or perhaps purged after processing some number n packets, such as associating the key with the extended sequence number with which the key was last used. Purge could happen when a key search is performed. But, keeping three indefinitely is simpler logic.)
Yah, that makes sense. I'll try and update some text explaining this but not change how anything works.
OK - be great of folks could take another skim of this one
Concern: >>>Based on the DoS security consideration, it appears as if you’re okay with the EKT field not be protected by SRTP. (he asks without having dug into SRTP in a while) There’s really no way to get at integrity protection of the EKT field?
So the AESKeyWrap has it's own integrity protection. And the SSRC inside that has to match SRTP to make sure that it applies to the correct one.
Yeah. AES Key Wrap is self-authenticated by design.

Discussion:
An attacker who tampers with the bits in FullEKTField can prevent the intended receiver of that packet from being able to decrypt it.  This <del> is a minor denial of service vulnerability. </del> <ins> is a minor denial of service vulnerability.  Similarly the attacker could take an old FullEKTField from the same session and attach it to the packet.  The FullEKTField would correctly decode and pass integrity but the key extracted from the FullEKTField , when used to decrypt the SRTP payload, would be wrong and the SRTP integrity check would fail.  Note that the FullEKTField only changes the decryption key and does not change the encryption key.  None of these are considered significant attacks as any attacker that can modify the packets in transit and cause the integrity check to fail. </ins> An attacker could send packets containing a Full EKT Field, in an attempt to consume additional CPU resources of the receiving system