Handshake message parsing is ambiguous in type-safe implementations about mls-protocol

[burdges]

I'd kinda expect a trait instead of an enum for this in Rust, just because cipher suite agility creates many complexities. If it's only a compile time choice, or protocol version number, then differentiating MACs and/or hashes might provide the desired protections. Apologies if I've failed to understand all the goals here.

[rozbb]

No, this is a good point. I've chosen in my implementation to treat DH algorithms as trait implementations, and DhPoints as data. So I would have something like X25519.diffie_hellman(my_scalar, others_point). The reason I've chosen this representation for DH public keys is because these types cannot be known at compile time. If they could be, then I would probably use associated types for the aforementioned trait impls. So I have enums which I unwrap at runtime, and panic if there's a type error then. It's not pretty, but it'll hopefully prevent some bad things from happening.

[burdges]

Oh? I'm curious why the types cannot be known? Is it for linking with C or something?

[rozbb]

Well the types of, say, the DH implementor is not known. If DH operations are implemented as a trait DiffieHellman, then there are structs called X25519 and P256. So if these are marked by bytes, say 0x00 and 0x01, respectively, then what is the return type of deserialize_dh_from_byte(marker: u8) -> ???.
Well naturally it would be a dyn DiffieHellman. So say you do let dh_impl = deserialize_dh_from_byte(b). Then what types does dh_impl.multiply_basepoint(scalar: ???) -> ??? take and return? If each DH implementation has their own scalar type and point type, how can I know what to give this function?

[burdges]

I'd love it if Rust had type parameters for modules, but no such luck. Instead, we often create parameters traits for the entire module or crate, commonly called Trait or Params. It'd bloat the binary though if you need both X25519 and P256 in the same code, hence my C question. Anyways not a big deal. :)

[bifurcation]

From a protocol design POV, there are basically two options here:

1. Set the ciphersuite once, and force implementations to tell their deserializers what it is
2. Set the ciphersuite on every object, and force implementations to verify that all the ciphersuites are consistent

IMO, option 1 is likely to be less error-prone, simply because it touches less code, and it is more likely to fail if you get it wrong. It also doesn't seem that burdensome to implement. Yes, you have to route the ciphersuite around to all the right places, but things like templates and generics can help a lot.

[beurdouche]

I agree with Richard, the preferable way is usually to do 1 : ) It is more a implementation specific state machine enforcement issue than a protocol issue so I will close this, but feel free to discuss more in the Implementation issues if you feel like it is necessary.

[rozbb]

Yeah, I tend to agree with this argument. I think I can find a way to pass state into my deserializer.