But if I missed something and implementors are fine with “Zero-byte”, I do not object. Zero-bytes is allowed by the TLS 1.3 specification and theoreticallty better as it is not send normally.
From: Emu <emu-boun...@ietf.org> on behalf of John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org> Date: Friday, 19 February 2021 at 07:09 To: Joseph Salowey <j...@salowey.net>, EMU WG <emu@ietf.org> Subject: Re: [Emu] Consensus call for result indicators in EAP-TLS 1.3 Small nit: Zero-byte application record was removed in -06 as many TLS implementations did not support sending a Zero-byte application record. Zero-byte was then changes to send 0x00 but accept any application data. Other EAP-TLS based method might require longer specific stings like “EAP-Success”. I think you questions are fine if the word “Zero-byte” is removed everywhere. Cheers, John From: Emu <emu-boun...@ietf.org> on behalf of Joseph Salowey <j...@salowey.net> Date: Friday, 19 February 2021 at 06:26 To: EMU WG <emu@ietf.org> Subject: Re: [Emu] Consensus call for result indicators in EAP-TLS 1.3 We have had a lot of productive discussion on this topic. I feel comfortable calling consensus that we should add protected result indicators to EAP-TLS 1.3. There also seems to be consensus to use TLS Failure alert for failure result indications. How to represent success indicators is not as clear. Fortunately, we have two options that seem to have some support. 1. Zero-byte application record. Multiple implementations already use this mechanism and it is clear that the EAP-TLS peer and server "application" can receive and send this indicator. There were additional concerns about the ordering of this application data record in the flight, but it seems that this should not be a problem as long as the TLS library is fed the entire EAP-TLS message containing the flight to process. 2. Close-Notify Alert. This would use an existing TLS message to signal success. We have had some implementation reports that the EAP-TLS server "application" can trigger the close_notify on at least one library. I have not heard any news from implementers if close_notify is accessible to the EAP-TLS peer/supplicant "application". I think it is not clear if the signal would be accessible to implementers for both the EAP-TLS peer and server. I'd like to hear from implementers about their experience with this mechanism: 1. Have you implemented the zero byte application record signa? If not, why not?l a. Is it sent after receiving the client finished? b. Do you anticipate problems if the application record comes before or after a NewSessionTicket message? c. did you run into any issues with this mechanism? 2. Have you implemented the close notify method? If not, why not? a. Is it sent after receiving the client finished? b. Were you able to cause the message to be sent for the server or determine that the message was received for the peer/supplicant? c. Did you run into any issues with this mechanism? Joe On Sat, Feb 6, 2021 at 5:22 PM Joseph Salowey <j...@salowey.net<mailto:j...@salowey.net>> wrote: There is growing support for mandating result indicators for EAP-TLS 1.3. The result indicators help protect the EAP protocol exchange in the many different types of environments EAP-TLS is used and make the integration with the EAP state machine clearer. This has the impact of adding a round trip to EAP-TLS 1.3 making a total of 4.5 round trips. It may be possible to optimize this exchange, but that would need further study and would be beyond the scope of this effort. 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. 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. This call will run for 1 week. Please respond by February 15, 2021. Thanks, Joe
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
