Subject: [TLS] Issue 471: Relax requirement to invalidate sessions on fatal errors

From: Eric Rescorla <[email-masked]>
Date: Sat, 21 May 2016 15:11:14 -0700

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.

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 22 May 2016 12:25:16 +0300

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:
> "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.
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 24 May 2016 18:23:03 -0500

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:
> Alert messages with a level of fatal result in the immediate
> establish new connections. This requirement does not apply when the
> server's implementation of session resumption is stateless.
>
> Thanks,
>     Yaron
>