Draft: draft-ietf-emu-eap-tls13

Commentary: Added text based on suggestions from    suggests to make them MUST RFC 8446 states optionally or SHOULD 
 I implemented MUST Error in a pull request .  " I would suggest instead that it MUST send the TLS alert before any EAP - Failure . "  : 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 ?   closenotify except as success indication Mandate Error alert or user_cancelled before EAP - Failure 
 I expect  already knows , but to link the github issues , there is some discussion at about " user_cancelled " and how some implementations do n'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 do n'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 can not 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 .   wrote that an authenticated signal is probably not needed . " 1 . I do n'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 does n'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 . 
  , 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
Paragraph (version A):
Figures figterm1, figterm2, and figterm3 illustrate message flows in
several cases where the EAP-TLS peer or EAP-TLS server sends a TLS
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
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.
Paragraph (version B):
Figures figterm1, figterm2, and figterm3 illustrate message flows in
several cases where the EAP-TLS peer or EAP-TLS server sends a TLS
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
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.
Paragraph (version B):
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.