Subject: Re: [TLS] While we're patching

From: Peter Gutmann <[email-masked]>
Date: Fri, 6 Mar 2015 09:27:45 +0000

Watson Ladd <[email-masked]> writes:

>Did you test SKIP-TLS against your implementation? Because it's not clear
>from the paper that IRINA did.

Yes, but I'm not sure if the test was conclusive:

-- Snip --

Testing TLS 1.0 session...
  Remote host: https://ht.vc:6443.
Attempt to activate TLS 1.0 session failed with error code -25, line 1141.
  Error message = 'Timeout on read (select()) after 30 seconds'.

-- Snip --

Mind you it's enough to get Firefox, it's been sitting there for nearly ten
minutes now with the spinner whirling endlessly, so you don't even need to try
attacking the TLS implementation on that one.

>I don't see how this requirement goes away if a ladder diagram is used. (What
>is a ladder diagram anway? How does one implement it without writing a state
>machine?)

My implementation is:

Expect A;
Send B;
Expect C;
Send D;
if( A.option )
  Expect E1;
else
  Expect E2;
Send F;

which is quite different from:

while( TRUE )
  Get something;
  See what it is;
  Set state to some-state;

Actually TLS is pretty straightforward to do as a ladder diagram, if you want
to see a really hellish protocol to get right I'd look at SSH, which not only
allows arbitrary iterations of several messages but breaks what should be a
single message down into lots of little bits and pieces and sends them all
individually, with other messages coming back in between.  If SKIP-TLS was
bad, I'd hate to see what SKIP-SSH (or UNEXPECTED-MESSAGE-ORDER-SSH, or
ENDLESS-LOOP-SSH, or several other possibilities) would do.

Peter.

---

From: Roland Zink <[email-masked]>
Date: Fri, 06 Mar 2015 11:14:41 +0100

> which is quite different from:
There are many ways to implement something. In our implementation a 
state machine compiler was used. Basically you do write something like 
expect A Send B in it by writing  for a state a       a => (do b, go c). 
The compiler then ensures that when in state a some other event happens 
than A there will be a failure.

The expect A seems to imply a synchronous threaded implementation. When 
you go to asynchronous single threaded then you may end up with 
something like a state machine, e.g. you are in a state where you expect 
A and store this state somewhere.

I don't think the specification should say something how it is 
implemented. It should only clearly state what message sequences are 
allowed and which are forbidden. If optional messages are required in 
some cases then this must clearly be specified. If a formal state 
machine can be given then this is fine (but may turn out to be 
complicated). Otherwise text may be enough to state what is required.

Regards,
Roland