We elaborate on our findings and provide concrete recommendations for implementers of the nested ratchet protocol and its derivatives.

\subsection{Recommendations for protocol implementers}
\label{sec:recs}

\noindent\textbf{Let users choose to leave P2P-layer pre-keys unsigned}. We recommend implementers of the nested ratchet protocol and its derivatives to provide users with the option to leave P2P-layer authenticated key exchange pre-keys (i.e. those used in 3DH/X3DH/PQXDH) unsigned. This way, mutual deniability of the P2P layer and thus mutual deniability of the cumulative nested ratchet protocol is maintained. In this case, the user should be notified of the tradeoff between trusting the central server and mutual deniability. 

\noindent\textbf{Use forward-secure signatures for fan-out layer messaging}.
We find nested ratchet protocol derivatives, including Sender Keys and Megolm, needlessly compromise on post-compromise deniability guarantees by signing all messages in a single fan-out layer session with one private signing key. If a session's public signing key is compromised (i.e. any of the users in the group are compromised), every message in that session, past and future, may be provably attributed to the sender. To avoid this scenario, we advise implementors of the nested ratchet protocol or its derivatives to employ \textit{forward-secure signatures} in fan-out layer sessions as opposed to static signatures \cite{Itkis_Reyzin_2001}. Using such a primitive, signing keys may be ratcheted concurrently with the symmetric encryption key to provide perfect forward deniability. 
% https://www.cs.bu.edu/~reyzin/papers/forwardsig-optimal.pdf


\noindent\textbf{Do not use fan-out layer encryption for two-party channels}.
Federated secure communication protocols like Matrix, which employ Megolm as a critical sub-protocol, choose to ensure even peer-to-peer messaging uses the fan-out layer protocol. Matrix ``rooms'' always use Megolm over Olm, even for 1:1 rooms.\footnote{See \href{https://matrix.org/docs/matrix-concepts/end-to-end-encryption/}{matrix.org/docs/matrix-concepts/end-to-end-encryption}. Note, direct messages (i.e. ``m.direct'' in element) are still constructed as rooms.} Our analysis clearly shows this should not be done: Olm should be always used for the 1:1 setting. Fan-out layer protocols such as Megolm intentionally compromise on post-compromise security and initiator deniability to accomidate the group chat setting specifically, and thus should not be used over Olm or Signal in the two-party setting.