On Feb 1, 2021, at 1:00 AM, Joseph Salowey <j...@salowey.net> wrote: [ re: commitment message ]
> [Joe] I'm not sure why it's needed. It's not clear to me why the peer can't > hold the TLS session open until it receives more TLS messages (handshake or > alert) or an EAP failure or EAP Success. I suspect that it can. The larger issue for me is that in EAP + TLS 1.2, the "TLS Finished" message comes after the client certificate has been validated. See Page 6 of https://tools.ietf.org/html/rfc5216 In EAP + TLS 1.3, the proposal is that the "TLS Finished" message comes before the client certificate has been validated. To me, this means that the client has absolutely no idea whether or not it's certificate has been verified. Any malicious actor could forge an EAP-Success (as it is entirely unauthenticated). This seems to be a major difference from TLS 1.2, and potentially a major problem. There is a goal to get EAP-TLS working in 3.5 rounds. That's a good goal, but I'd like to be sure that it doesn't come at the expense of security. Alan DeKok. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
