Hi, Maybe not so important to figure out who suggested what, but I think the whole discussion took place at IETF 102.
https://datatracker.ietf.org/meeting/102/materials/slides-102-emu-eap-tls-with-tls-13-00.pdf https://datatracker.ietf.org/meeting/102/materials/minutes-102-emu-00 https://www.youtube.com/watch?v=Ez2Y4wK94Sk At the same meeting it was also ruled out to use the Reserved bits in EAP-TLS header and to make EAP-Success carry payload. Latency and security was discussed a lot with Bernard keeping the security high and Jouni expressing on the mailing list before the meeting that he wanted to cut even more roundtrips from the message flow. According to the minutes it seems like Jim suggested the use of application data and Eric suggested the interpretation to make this mean no more handshake messages. This was added to the draft and everybody was happy with that for 2.5 years. While individual persons cannot represent the TLS WG, there was a large amount of senior TLS people present and active in the discussion. --------------------- John: Jouni implemented this draft and found the NewSessionTicket was inconvenient Darshak: Point is well taken. We should not restrict NewSessionTicket. The server could signal with EAP that it will send other things. Bernard: You are not changing EAP. EAP-Success can be spoofed. Understand exactly which state it is, not an EAP task but method specific. Reception of properly encrypted message should take precedence over EAP-Success. At every point, important to know if you are in continuing, success or failed state. It has nothing to do with EAP. Jim Schaad: Have the server send an encrypted content message. Will add latency. Bernard: That's how EAP-TLS does currently with Finish message. Darshak: Does sending this encrypted content message indicate that no more TLS messages will be sent. Jim: TLS content message (a record) to know when you are done and make transition. That takes the place of the TLS Finish message. Hannes: Differenced to other EAP messages. Before there were clear definitions. What is finished actually? NewSessionTicket is still a handshake. Cram it in earlier in the exchange. Darshak: Isn't the TLS server allowed to send NewSessionTicket later. Are you restricting it in EAP? Eric: You want to know that there will be no more TLS messages? Profile TLS to say don't do this. None of the Post-Handshake messages are needed. John: Need more discussion on the mailing list. Could we use FLAG in EAP-TLS. Bernard: If you use this and it determines cryptographic state, then you have just introduced a vulnerability. Don't do that. John: Piggyback Newsessionticket on the EAP-SUCCESS Bernard: Not a good idea. --------------------- Do close_notify even fulfill the requirements here. It cannot be spoofed, but it is a very strange alternative success message. It can also be sent by the server earlier to indicate failure for any reason.... Cheers, John -----Original Message----- From: John Mattsson <john.matts...@ericsson.com> Date: Wednesday, 3 February 2021 at 00:48 To: "emu@ietf.org" <emu@ietf.org> Subject: Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine Alan wrote: ><john.mattsson=40ericsson....@dmarc.ietf.org> wrote: >> 4. was something I thought was clear. The -13 version states that “The >> EAP->TLS server commits to not send any more handshake messages”. This was >> >according to my memory exactly what was requested from the implementors. > > The text is in draft-mattsson-eap-tls13-02, but not in > draft-ietf-emu-eap->tls13-00. The announcement message is here: > >https://mailarchive.ietf.org/arch/msg/emu/8Axkmgh_ZPCTwhvmRjVMvXGTKko/ > > Which doesn't mention the commitment message. I can't find any other > >discussion about the commitment message on the archive. That doesn't > >necessarily mean much, as the archive is difficult to search. > > So it's not clear where that came from. I Agree. The initial problem was brought up by Jouni who identified both the problem with the extra round-trip as well as the uncertainty in the EAP state machine. https://mailarchive.ietf.org/arch/msg/emu/SBdblHmLQTbBwoZHK8Rih-g5ne8/ The idea with the commitment message was suggested by Jim Schaad during IETF 102 and then added in -01. The meaning of the commitment message was likely also discussed during that EMU session. I do not remember the exact discussions. It was likely not an implementor that suggested this definition. I mixed it up with Jouni raising the problem. > In the last weeks discussion, the commitment message has been given a lot of > >different interpretations that are not coming from the draft. The meaning of > >and requirements for the -13 commitment message now seems quite unclear. > > An in-progress draft is not an authoritative source of information. The WG > >is discussing what the commitment message means, with an eye to making > >recommendations for the draft, and implementors. Of course not, but the exact same definition has been in the draft since -01 without anybody question it before now. This made me think it was clear and widely accepted. That does not make it right and I have never said it is wrong to question that definition. I think we can agree that the meaning of the commitment message now seems unclear. /John _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
