Hi Mohit, Sorry for the slow response.
On Fri, Jul 31, 2020 at 02:08:44PM +0000, Mohit Sethi M wrote: > Dear all, > > Thanks all for the discussion on the commitment message. > > draft-ietf-emu-eap-tls13-10 > (https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-10) in figure 2 shows > the ticket establishment and commitment message: [snip] > > and the relevant text on commitment message: > > When an EAP server has sent its last handshake message (Finished or a > Post-Handshake), it commits to not sending any more handshake > messages by sending a Commitment Message. The Commitment Message is [reordering] > > I couldn't parse the comments about the "KeyUpdate" message. Perhaps having > the discussion over email will help me understand the issue. > I was referring to the specific promise to not send any more *handshake* messages here -- the only currently defined handshake messages that the EAP server could be sending are NewSessionTicket and KeyUpdate. (Okay, or EKTKey from draft-ietf-per-srtp-ekt-diet, but EAP is not using that at all.) I was not sure if the need was to avoid sending KeyUpdate vs. NewSessionTicket, and why the application layer needed to be concerned with it at all -- to some extent both can be handled internally by the TLS implementation. The application probably wants to get involved if it wants to resume using a session ticket, but it's permitted to just drop the tickets on the floor and never use them. > a TLS record with application data 0x00 (i.e. a TLS record with > TLSPlaintext.type = application_data, TLSPlaintext.length = 1, and > TLSPlaintext.fragment = 0x00). Note that the length of the plaintext > is greater than the corresponding TLSPlaintext.length due to the > inclusion of TLSInnerPlaintext.type and any padding supplied by the > sender. EAP server implementations MUST set TLSPlaintext.fragment to > 0x00, but EAP peer implementations MUST accept any application data > as a Commitment Message from the EAP server to not send any more > handshake messages. The Commitment Message may be sent in the same > EAP-Request as the last handshake record or in a separate EAP- > Request. Sending the Commitment Message in a separate EAP-Request > adds an additional round-trip, but may be necessary in TLS > implementations that only implement a subset of TLS 1.3. This construction feels weird to me because it's using application data to try to make a promise about the TLS layer, which is a fragile construction and could break if there are changes to the TLS implementation without corresponding changes to the application code. In general, the application will not even know when/whether the TLS implementation is going to send more messages (though it would be fairly surprising for the TLS implementation to spontaneously send stuff in the absence of other application messages). Using close_notify as we seem to be agreeing upon feels better since it's the TLS-layer mechanism for doing so and the TLS implementation is expected to do the right thing in terms of not sending more messages, once it's sent or received. -Ben _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
