Re: [TLS] Re: when is it ok to resume a cached SSL/TLS session

> No, I don't agree with this analysis. The server being 
> unwilling
> to resume a session is normal behavior. The TLS state 
> machine
> explicitly handles such cases. Implementations which choke
> rather than doing a full handshake are broken.
>
> -Ekr

Perhaps the TLS state machine changed from the SSL state 
machine ? I did notice in your book how you tied your 
concept of the state transitions of an implementation to the 
TCP state machine, something I don't do.

Its like we said for trust chains: regardless of what a 
server sends, what  client APPLICATION uses is up to it. it 
can ignore the server-supplied trust chain, if it chooses.

The same goes for accessing client-side crypto. Jus because 
a server (which has not proved knowledge of secrets from a 
TLS-connection state) seeks me to access my crypto device 
DOES NOT MEAN I DO IT. Im perfectly entitled to have a 
product design that seeks the user to enter a smartcard at 
that point; and close MY connection attempt if the user does 
not present it in some time.

We are now squarely arguing over:-

   One advantage of TLS is that it is application protocol 
independent.
   Higher level protocols can layer on top of the TLS 
Protocol
   transparently. The TLS standard, however, does not 
specify how
   protocols add security with TLS; the decisions on how to 
initiate TLS
   handshaking and how to interpret the authentication 
certificates
   exchanged are left up to the judgment of the designers 
and
   implementors of protocols which run on top of TLS.

and then (note the final clause):-

   If the application protocol using TLS provides that any 
data may be
   carried over the underlying transport after the TLS 
connection is
   closed, the TLS implementation must receive the 
responding
   close_notify alert before indicating to the application 
layer that
   the TLS connection has ended. If the application protocol 
will not
   transfer any additional data, but will only close the 
underlying
   transport connection, then the implementation may choose 
to close the
   transport without waiting for the responding 
close_notify. No part of
   this standard should be taken to dictate the manner in 
which a usage
   profile for TLS manages its data transport, including 
when
   connections are opened or closed.

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