Subject: Re: [TLS] CCS and key reset and renegotiation

From: Peter Gutmann <[email-masked]>
Date: Tue, 10 Jun 2014 15:58:17 +0000

"Salz, Rich" <[email-masked]> writes:

>I wasn't suggesting a set of ladders to replace a state machine.  Peter said
>it's not really a state machine but rather a ladder. I was emphasizing that,
>*if this is true*, then a ladder approach is way much better.

So I did some simple diagrams for SSL years and years ago, see page 10 of
https://www.cs.auckland.ac.nz/~pgut001/pubs/app_sec.pdf.  I didn't include
renegotiation because my code doesn't do it (I'd always seen it as a problem,
not a solution) and optional add-ons like client cert auth which can easily be
added.  The whole thing is so obviously a ladder that I never understood why
the RFC tried to make it a state machine.

(Interestingly, the same page also contains the SSH protocol as a ladder
diagram.  SSH does more or less the same thing as TLS, only a lot more
awkwardly, and they don't try and present the protocol as a state machine.
Mind you they don't do it as a ladder diagram either without a lot of digging
in the text "both sides send X, then once X has been sent they go on to Y,
then once that's done they do Z, ...").

Peter.

---

From: Michael StJohns <[email-masked]>
Date: Tue, 10 Jun 2014 19:45:15 -0400

> the RFC tried to make it a state machine.

The issue with understanding TLS via state machines is that it's not one 
state machine, but more like 6 - Client and server versions of a) 
negotiate cipher suite, b) negotiate keys, c) authenticate.  The three 
state machines on either side are interconnected - events in one state 
machine trigger transitions in other state machines. Messages 
sent/received related to specific state machines are interleaved in TLS 
in an attempt to reduce roundtrips.

Generally, if you can express things as a ladder diagram, you can find a 
way of expressing them as a state machine and vice versa.  I tend to 
prefer state machines because I can generally figure out if I'm missing 
something (e.g. dead states, unhandled messages, exception handling).  
Ladder diagrams are linear, and don't give you great indications of how 
the exception cases are handled.    But both have their place.  Ladder 
diagrams are especially helpful when you're dealing with more than 2 
entities and/or protocols and trying to understand who knows what when.

Mike

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>