On Jan 29, 2021, at 5:35 PM, Jorge Vergara <jover...@microsoft.com> wrote: > > [Jorge] The diagrams in the draft mostly imply that the commitment message > being the last thing sent, after any NewSessionTicket. As stated, this is > problematic since the TLS stack may re-order these, and the NewSessionTicket > may have to come in another EAP-TLS fragment entirely if the combined message > ends up crossing a fragment boundary. > > In my mind, it is obvious that the rest of the EAP-TLS packet should be > processed so that the EAP-TLS client can correctly receive the > NewSessionTicket and any other handshake data that may have been in this > final message.
OpenSSL has a feature SSL_MODE_AUTO_RETRY which makes it process TLS messages *after* the Finished message. i.e. the Session Ticket, etc. When an application calls SSL_Read(), all of the TLS data is processed, instead of just the "TLS finished" message. They've made this the default, because most applications get it wrong. It would be good for the draft to note that TLS libraries should process all of the TLS messages before handing application data over to the application. > However, once that complete EAP-TLS packet is processed, the next message > from the server should indeed be an EAP-Success, EAP-Failure, or EAP-Request > with a TLS Alert Message as draft-13 indicates. Section 2.1.1. says: After the EAP-TLS server has recieved a EAP- Response to the EAP-Request containing the Commitment Message, the EAP-TLS server sends EAP-Success. Which *could* be seen as mandating EAP-Success, no matter what certificate is sent by the client. I suggest making this behaviour clearer. i.e. the document should include something like your sentence above. > This is currently how the Windows client implementation operates, but it is > mostly by chance. If we made the full processing of the EAP-TLS packet > explicit, then I think this would resolve the concerns around ordering here. I agree. I would also like clarification on just what the commitment message does, and why it's needed here, and not for TLS 1.2. Alan DeKok. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
