Subject: Re: [Emu] Consensus call for result indicators in EAP-TLS 1.3

From: John Mattsson <[email-masked]>
Date: Mon, 8 Feb 2021 17:31:21 +0000

>This consensus call has two parts:
>
>1. Please respond to the list if you support adding explicit result
>indications of success and failure from the EAP Server to the EAP Peer in
>EAP-TLS 1.3.  If you object please respond to the list indicating why.

I support this based on that implementors support it. Based on the ongoing disucssion
between Mohit and Bernard, the exact security benefits seem a bit uncertain.

>2. Please respond to the list if you support using TLS close_notify alert
>for a success indication and TLS error alert for a failure indication.  If
>you object please respond to the list indicating why.

I support that TLS error alert is a protected failure indication.

But 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 close_notify
- Sending user_cancelled
- Sending user_cancelled followed by close_notify
- (It would also not suprise me if some implementation
sends an Error alert followed by close_notify).

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 user_cancelled
- Forbid close_notify except as success indication
- Mandate Error alert before EAP-Failure

Do implementors and TLS people agree that is possible?