Version -13 includes neither the word "stateful" nor "stateless", so if Yaron's proposal is taken, it would be better to explicitly refer to session tickets or ID-based resumption (with appropriate citations).
That said, I'm not sure I see the need for a normative requirement on the server; we could note that the previous version required session invalidation and clients should not expect to be able to reuse sessions in this state, and leave it at that. (Or do that and drop to a MAY be invalidated.) -Ben On 05/22/2016 04:25 AM, Yaron Sheffer wrote: > 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
