Re: returning to the previous state

Jim Lawson Williams <[email protected]> Sun, 18 May 1997 16:26:42 +1000
Newsgroups gmane.ietf.apps-tls
Message-ID <[email protected]>
(unnamed) (text/enriched, 2.2 KB)
G'day!


At 04:17 PM 5/17/97 -0700, Paul E. Hoffman wrote:

>There is nothing in the TLS spec that says

>anything about the API that is used to tell the higher-level protocol
(in

>our case, SMTP).


Oh, dear!  No man's land.  "Mere implementation detail, m'boy!  Don't
you

worry about that!"


I would have hoped that this might have been the forum to express what 

developers expect from an API: timer-management, for example.  To take
the 

specification cited, 6.2.1 states


  <bigger>The client and the server must share knowledge that the 

  connection is ending in order to avoid a truncation attack...

</bigger><bigger>  ...Each party is required to send a close_notify alert before 

  closing the write side of the connection. 

 

but skirts assigning responsibilities for what's supposed to

happen at the client-end if the server's close_notify response 

seems to be lost, stolen, or strayed.  I, for one, think the 

proper place for such time-outs is down in the TLS impementation.

I would, however, like to see some level of control vested in the

application layer.


I would like the options of saying "TLS, you take care of this

connection and manage the whole thing", or, alternatively, in the

extreme, "TLS, accumulate statistics on the initial hand-shake 

round-trip times. Set a default time-out from them, and tell me

the average and maximum round-trips, and what timeout you're 

about to set so that I can override that last value should I want

to.  Tell me if a close-notify time-out occurs so that I can 

decide whether to wait a little longer, or to terminate the 

session with extreme prejudice."


I appreciate that the immediate concern is the swift deployment 

of SMTP/TLS rather than some obscure and currently theoretical

application for one list-member, but if this is not the place to

discuss an "application view" of TLS APIs, where is?


Regards,

Jim LW  




</bigger>




>From the BBC's "Barchester Chronicles":


    "I know that ultimately we are not supposed to understand.

    But I also know that we must try."


       -- the Reverend Septimus Harding, 

          crypt-analyst, art-critic, tax-consultant, C++ programmer,

          humanitarian


(If vegetarians eat vegetables, what do humanitarians eat?

 Humane beans, perhaps?)