Call me crazy, but this seems like crazy overkill for rolling dice. To me, this is the equivalent to: I want to start a fire, instead of getting a match, I am going to build a nuclear weapon, detonate it, and go find a flaming sheet of paper from a destroyed office building. :-P
In gaming, perception > reality. Games lie to you all the time, but you never would realize it.
Simply use an RFC to send the rolled dice value from the host/authority, then simulate the dice roll (without physics) to match the result on each client. This is more secure, saves you a ton of physics madness, and is far more straight forward.
How you achieve the simulation? There are many ways. If you're more of an editory person (I generally avoid Unity's editors), you could use the animation tool to create a dice roll, and then manipulate the dice cube orientation before you run the animation ensure you get the desired output, since it will be rolling the same way each time.
An intermediate solution: technically, if you drop the dice from the same orientation, velocity, angular velocity, position, etc. you should get the same outcome. You could combine that with my previous suggestion of sending the outcome first and manipulating the throw variables to ensure you get the same result, or, simply send those variables in an RFC call and hopefully they should all end up the same on each client.
Long story short, in networking, you try to remove all randomness (make everything deterministic), so that you can simply send the start state, and all clients end up with the same result. This is how real-time strategies work. You cannot send 10,000 units worth of data each frame. So, you simply send the few things that do change, each player's orders, and each client runs the exact same simulation.
I am not sure if Unity's physics (uses PhysX for 3D), is deterministic. I would imagine it is. But who knows, there is a ton of floats, which could introduce rounding errors.