On Jan 5, 2021, at 4:47 AM, Mohit Sethi M <mohit.m.se...@ericsson.com> wrote: > What I am gathering is that this commitment message should instead be > made into a confirmation message, i.e. it should only be sent after > receiving TLS Finished from the client? This would result in one extra > round trip to both figure 1 and 3 in the current draft. So we would end > up with the same number of messages as RFC 5216 for full authentication > (https://tools.ietf.org/html/rfc5216#section-2.1.1) and actually do > worse than RFC 5216 (one extra round trip) in case resumption > (https://tools.ietf.org/html/rfc5216#section-2.1.2).
That sounds right. > Maybe this is acceptable? The draft anyway notes that "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.". In which case, I am not sure if the > reasons against using close_notify apply anymore. I won't offer opinions on TLS internals, as I'm out of my depth there. As an implementor, the priority is getting TLS alerts (expired cert, etc.) back from the EAP server to the EAP peer. Those messages can then be used to debug deployment issues. The exact method of doing this is less important. The "0x00" octet works now, so I'm happy with it. But if TLS review decides that should change, that's fine, too. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
