[openssl-dev] State machine rewrite

[Matt Caswell]

On 12/09/15 11:22, Kurt Roeckx wrote:
> On Sat, Sep 12, 2015 at 12:20:52AM +0100, Matt Caswell wrote:
>> Dependant on the preceding messages we
>> might need to have a CertificateVerify next. So transitions are actually
>> "guarded" - there is logic which determines whether a particular event
>> is "allowed" in the current scenario or not.
> 
> Does that just not mean you don't have all the states as real
> states, but that you're combining 1 state with something like a
> variable to determine between other states inside that state?

Yes, that is an excellent point and is indeed correct. I am "cheating" a
little by introducing guarded transitions. The implementation of these
guards inevitably goes off and inspects state that is held outside of
the state machine itself. The kind of state I'm talking about here are
things like the current ciphersuite; what extensions have been
sent/received; whether the client has sent a Certificate or not; etc. It
would of course be entirely possible to build a state machine which did
not rely on any of this external state - *all* of the state would be
locked into our current position within the state machine. For example,
this might mean that you need a different set of states and transitions
for handling (say) PSK ciphersuites to the set of states and transitions
that you need for other ciphersuites.

As you can imagine (and as you pointed out) this could lead to a real
explosion in the number of states that you need. There's more to it than
just that though. In the state machine as I have designed it the events
that trigger transitions are quite simple and the code can be generic
for handling them (at least for reading messages): an event is simply
the arrival of a message of a particular type. In this new extended
state machine that we are imagining where there are many more states,
the events are more complicated in order to distinguish between the many
more different transitions that we can now make. So for example in my
state machine an event might be "a ServerHello message has arrived",
whereas in the extended state machine the event might be "a ServerHello
with a PSK ciphersuite selected has arrived". This now means our event
detection logic is much more complicated - and is state specific. All we
have done is moved complexity out of the transition guards and into the
state machine structure *and* the event detection code.

On balance I think such an approach is not a good trade off. I much
prefer the simplicity of a one-to-one correspondence between messages
and states. Doing it the other way is much more likely to turn into a
code maintenance nightmare IMO.

Matt