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

<home_pw@msn.com> writes:

>> 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 ?

No, it didn't. This feature has been there since SSLv3 (and in
variant, since SSLv2).

> 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.

No, I don't agree that we're arguing over this at all. We're arguing
about whether it's appropriate to treat failure to resume as an error.
It's not.

-Ekr

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