>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? _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
