feat(session): Validate MLS proposal sender and type

[thomas-vilte]

Overview

I have implemented a critical validation step for incoming MLS proposals within the session processing logic. This enhancement ensures that only proposals conforming to the DAVE protocol's security requirements are accepted, specifically by validating the sender type and the proposal's content type.

Key Changes

Proposal Validation Function: I introduced a new private method, proposalAllowedByDAVELocked, in session/mls.go. This function is responsible for inspecting an MLSMessage to determine if it originates from an External sender and if its content is either an Add or Remove proposal.

Integration into Batch Processing: The processProposalBatchLocked function now calls proposalAllowedByDAVELocked for each incoming proposal. If a proposal fails this validation, it is logged and rejected, preventing further processing.

Enhanced Test Coverage: I updated session/proposal_validation_test.go to include new test cases that specifically verify the rejection of proposals with disallowed sender types (e.g., SenderTypeNewMemberProposal) and disallowed proposal types (e.g., PreSharedKeyProposal). I also added buildExternalSenderPackageWithKey to facilitate accurate testing of proposals originating from the external sender, mirroring real-world DAVE behavior.

Technical Impact

This change significantly enhances the security and robustness of our MLS session management. By strictly validating proposal senders and types at an early stage, I am enforcing DAVE's protocol specification, which dictates that only Add and Remove proposals from the voice gateway's external sender are permitted. This prevents potential vulnerabilities from malformed or unauthorized proposals, ensuring the integrity and security of the group state. The improved test suite now provides stronger assurances that our validation logic correctly handles both valid and invalid proposal scenarios.

🧪 Test Plan & Evidence

Suggested Manual Verification

• Unit Tests: Run go test ./... and ensure all tests pass
• No Regressions: Verify that related features still work as expected