Submitting this issue to address key selection in MAC security processing.

In SubMac::ProcessTransmitSecurity(void), the AES key is set using mTransmitFrame.SetAesKey(GetCurrentMacKey());. This hardcodes the transmission to always use the current active MAC key.

While this works in most scenarios, it fails during retransmissions (such as indirect frame retx). In these cases, the key index (Key ID) of the original transmission attempt is saved and reapplied to the frame. If that original attempt occurred right before a key rotation, the required key index actually points to the previous MAC key (Key Sequence - 1), but the code will incorrectly force the new, current key.

The same issue is present in Mac::ProcessTransmitSecurity(TxFrame &aFrame) when processing TREL frames.

Proposed Solution

Instead of defaulting to GetCurrentMacKey(), read the key index directly from the frame's headerand use that index value to resolve and apply the correct key.