Hi Joe, Good initiative.
1. To have an alternate success indication is new. The requirement needs to be the possibility to have an _protected_ success indication. This is requires in at least IEEE 802. It seems to be a weakness in the IEEE 802 spec, but EAP-TLS simply has to align with this. I don't think a 3.5. round-trip needs any security analysis, but I don't think it is worth specifying such a mode without resumption. A 3.5 mode not suitable for IEEE 802 with resumption would require significant TLS work. This might be worth doing in the future, but should not be done now. I think 4.5 roundtrip with a mandatory protected success indication is the only thing we should specify now. 2. TLS Error alert are perfect matches for alternative failure alerts. Early Error alerts are unprotected. Later Error alerts are protected. Martin and Ben both indicated that they think using application data is problematic. First because of reordering done by the TLS implementation and secondly as they they seem to disslike the use of applicaiton data to signal what the TLS implementation should do. close_notify in a separate flight mitigates any reordering issues and automatically implies that no more handshake messages are sent. As long as the implementors can live with it I would suggest that we use close_notify as a success indication and move forward, but I don't have a strong opinion. As Bernard suggested I think we should write that TLS Error messages are alternate failure indicators. 3. While I agree that TLS should have specified the exporter that way, it does not provide any significant value to EAP-TLS. I do not think EAP-TLS should use anything else that a standardized TLS exported, and waiting for a new standardized TLS exporter takes far too long time. I think the separate labels for MSK and EMSK are good. Have we aligned on using context or not? Using contect seemed like a simpler solution, but not all TLS implementations support context. I do not think we should include anything form client finished at this point. Cheers, John From: Emu <emu-boun...@ietf.org> on behalf of Joseph Salowey <j...@salowey.net> Date: Thursday, 4 February 2021 at 17:24 To: EMU WG <emu@ietf.org> Subject: [Emu] Way Forward for EAP-TLS 1.3 Based on John's email [1] and a few other discussions I've had offline I'm proposing the following series of consensus calls to find a path forward: 1. Consensus on requiring result indicators using a 4.5 roundtrip protocol. I think this is a conservative approach that could move forward quicker then alternatives. It may be possible to securely use an abbreviated protocol in some environments or with some additions to TLS, but the security analysis for this would take more time and may lead nowhere. An abbreviated protocol could be covered in an update. 2. Consensus on what signal to use for result indicators, such as Close_Notify and fatal alerts. 3. Consensus on whether to enhance the key derivation to include certificates or other information from that includes the client and server identity. This would help ensure that keys were not passed down to the lower layer prematurely. I think we can run 1 and 3 in parallel. We will also need to take resumption into account. Please respond to this thread, either privately or on the list, with your concerns. I'd like to start these calls before next week. Cheers, Joe [1] https://mailarchive.ietf.org/arch/msg/emu/hawPjEH2RRin4MlzqJe57Yrf0bQ/
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
