This still makes the *stateful* implementation much more deterministic
and those implementations are common enough. So how about:
Alert messages with a level of fatal result in the immediate termination
of the connection. In this case, other connections corresponding to the
session may continue, but the session identifier MUST be invalidated,
preventing the failed session from being used to establish new
connections. This requirement does not apply when the server's
implementation of session resumption is stateless.
Thanks,
Yaron
On 22/05/16 01:11, Eric Rescorla wrote:
https://github.com/tlswg/tls13-spec/issues/471
http://tlswg.github.io/tls13-spec/#alert-protocol says:
"Alert messages with a level of fatal result in the immediate
termination of the connection. In this case, other connections
corresponding to the session may continue, but the session identifier
MUST be invalidated, preventing the failed session from being used to
establish new connections."
However, this is not consistent with a stateless implementation of
session tickets.
RFC5077 is a bit handwavy on this but implies that you shouldn't do this
with tickets
(see also [SBR04] for discussion of this). I propose we remove this
requirement
-Ekr
[SBR04] Shacham, H., Boneh, D., and E. Rescorla, "Client-side
caching for TLS", Transactions on Information and System
Security (TISSEC) , Volume 7, Issue 4, November 2004.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
