Change:
Added text based on suggestions from Alan
Alan suggests to make them MUST RFC 8446 states optionally or SHOULD
I implemented MUST Error in a pull request. Alan "I would suggest instead that it MUST send the TLS alert before any EAP-Failure." John: This would require also mandating user_cancelled.....
To make a practical difference I think we need to follow Alans suggestion and mandate a protected failure indication before EAP-Failure. Looking at RFC 8446 it looks like TLS 1.3 can terminate a connection by: Not sending any alert Sending an Error alert Sending closenotify Sending usercancelled Sending usercancelled followed by closenotify (It would also not suprise me if some implementation sends an Error alert followed by closenotify). It seems a bit complicated to use alerts as both failure and success indications. To make it work I think EAP-TLS 1.3 needs to: Forbid all use of usercancelled Forbid closenotify except as success indication Mandate Error alert before EAP-Failure Do implementors and TLS people agree that is possible? Alternativeley Forbid closenotify except as success indication Mandate Error alert or user_cancelled before EAP-Failure
I expect John already knows, but to link the github issues, there is some discussion at URL about "user_cancelled" and how some implementations don't really adhere to the text of 8446.
Any error alert set from the server should be treated as a failure signal regardless of what other information may be present. I think a user_cancelled alert should be treated in the same way ( although I'm not sure there is reason for a server to send it so perhaps it should not be allowed). Any error alert or user cancelled from the peer should be treated as a failure indication from the peer and the server should respond with an EAP Failure. Note: In it is possible for the peer to send a client hello after receiving an alert from the server to restart the conversation. I'm not sure that this changes anything.
"Any error alert or user cancelled from the peer should be treated as a failure indication from the peer and the server should respond with an EAP Failure." Yes, or "any alert should be treated as a failure indication" if we go with application data as a success indication. "Note: In 5216 it is possible for the peer to send a client hello after receiving an alert from the server to restart the conversation. I'm not sure that this changes anything." That's a good observation. Not sure we can allow that with TLS 1.3 if an alert is an failure indication. BTW, my view is that draft-ietf-emu-eap-tls13 introduces protected result indicators when TLS 1.3 is used and does not update RFC 5216 with protected results when TLS 1.2 is used. I don't think this has not been clearly stated in the discussion. If somebody have a different view it would be good to know asap.
Correct, we should not change the behavior of 5216
This is resolved in PR
In the dicussion on the commitment message there has been quite a lot of talk about the need for an authenticated signal at the end of the handshake. This has not been discussed before. The -13 commitment message could not be used for that and close notify cannot be used for that. The NewSessionTicket could be used for this. This is a message that acknoledge that the server has accepted the client authentication. it is also a message that can only be sent be the server and not by an on-path attacker. Note that the NewSessionTicket is not cryptographically bound to the Clients second flight, but this is probably not needed. Jorge Vergara wrote that an authenticated signal is probably not needed. "1. I don't see a strict requirement for an authenticated signal at the end of the handshake." This issue is likely related to the newly opened issue of the EAP state machine.
Most of the current discussion in the group is about result indications and not signaling the end of the handshake. I doesn't seem that we need to signal the end of the handshake. The peer should always know how long a flight of messages is even if they are fragmented.
Agree, the protected result indications make any "end of handshake"-indication superfluous.
I think we can close this issue out once we have merged the application data as success indicator.
This will be resolved by merging PR , PR and PR

Discussion:
Figures figterm1, figterm2, and figterm3 illustrate message flows in several cases where the EAP-TLS peer or EAP-TLS server sends a TLS <del> fatal alert message.  In earlier versions of TLS, error alerts could be warnings or fatal.  In TLS 1.3, error alerts are always fatal and </del> <ins> Error alert message.  In earlier versions of TLS, Error alerts could be warnings or fatal.  In TLS 1.3, Error alerts are always fatal and </ins> the only alerts sent at warning level are "close_notify" and "user_cancelled", both of which indicate that the connection is not going to continue normally, see RFC8446. <ins> In TLS 1.3 RFC8446, Error alerts are not mandatory to send after a fatal error condition.  Failure to send TLS Error alerts means that the peer or server would have no way of determining what went wrong. EAP-TLS 1.3 strengthen this requirement.  Whenever an implementation encounters a fatal error condition, it MUST send an appropriate TLS Error alert. </ins> figterm1 shows an example message flow where the EAP-TLS server rejects the ClientHello with a Error alert.  The EAP-TLS server can also partly reject the ClientHello with a HelloRetryRequest, see