Re: [TLS] TLS state machine

[Bodo Moeller <bmoeller at acm.org>]

On Wed, Mar 21, 2007 at 06:35:59PM +0000, Stefan Santesson wrote:

> Considering this being the TLS state machine, the TLS extension
> mechanism clearly allows a change of the TLS state machine as it
> allows other handshake messages to be inserted in this flow.
> 
> What are the criteria that distinguish a valid change to the TLS
> state machine from an invalid (unsuitable) one?
> Or is this totally subjective?

I guess this generally is pretty much subjective: changes to the
standard TLS handshake state machine for specific ciphersuites or
extensions presumably would be accepted if there are compelling
arguments supporting these changes.  Here
draft-santesson-tls-gssapi-01.txt has a (potentially curable) problem
because it explains what you would be able to do, but not why and when
you would want to do this.

However, if I understand Eric's criticism correctly, his main
complaint concerning the state machine is not that there *are*
changes; rather, it is that the changes are quite drastic.
The standard TLS handshake state machine has the following simple
properties:

- There is a finite number of states.

- Any given handshake will end (one way or another) after a finite
  number of handshake messages has been exchanged -- i.e., the state
  transition diagram does not have any cycles.

The standard TLS handshake state machine (as well as extended TLS
handshake state machines maintaining similar properties) inherently
bounds the number of rounds and the amount of data exchanged in any
given handshake.  draft-santesson-tls-gssapi-01.txt doesn't do that,
unless considered in conjunction with specific GSS-API mechanisms
enforcing specific bounds.  Even if you are willing to trust that
any specific GSS-API mechanism will guarantee a finite handshake,
draft-santesson-tls-gssapi-01.txt doesn't guarantee upper bounds.

This particular concern might be cured by requiring any specific
GSS-API mechanism to provide to the TLS layer (an upper bound on) the
number of messages to be exchanged before the GSS-API portion of the
handshake actually starts.  Then you could have the TLS layer do a
count-down with handshake messages gss_token<n>, gss_token<n-1>, etc.,
down to gss_token<1> (these count-down numbers being a purely internal
concept, not appearing on the wire).

Bodo


_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls