At least 2 existing implementations of MLS have some sort of curve-specific DH public key type. This is to ensure type safety and reduce the likelihood of the programmer accidentally using one point value for a different curve. For me, this is
enum DhPoint {
X25519([u8; 32]),
P256([u8; 32]),
}
The issue I run into is that I cannot unambiguously deserialize DHPublicKey
s into a DHPoint
. Recall the definition opaque DHPublicKey<1..2^16-1>
. The parse of an unmarked sequence of bytes is dependent on ambient state, namely the CipherSuite
of the current session. Notably, the value of this CipherSuite
is not repeated in any top-level messages. This means that a given Handshake
message will have at least two correct interpretations unless context is specified.
This is not a massive issue, but one could imagine a case where a participant receives a message from another participant who somehow disagrees on the current CipherSuite
. The receiver will parse all the messages correctly, check the signatures, and throw an invalid signature error. If we were to mark the type of the DHPublicKey
, though, the receiver would parse the values and check that they agree with the current CipherSuite
. This check will fail, and it will throw a decoherence error, which is more appropriate and informative.
DHPublicKey
is not the only data type for which this ambiguity occurs. I propose that we change at least some opaque
datatypes to enums. Currently, the not-really-bytes opaque types are
DHPublicKey
SignaturePublicKey
ECIES::ciphertext
UserInitKey::signature
Handshake::signature
ApplicationPlaintext::signature
Application::encrypted_content
My own implementation makes distinctions between different signature types, ECDSA pubkey types, and ECDH pubkey types. Encrypted content is treated as a binary blob.