On Feb 6, 2021, at 1:01 AM, John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org> wrote: > > I personally fine with writing MUST send an Error alert if the WG wants that.
This is what all implementations have done for ~15 years. The TLS Alert satisfies the "altReject" requirements of RFC 4137. Which means it's a very good iea. > This would maybe help with using close_notify as an alternate success > indication. I'm not sure how. Both are needed, but they're independent. > The most pressing question regarding alerts is if EAP-TLS can force the TLS > implementation to not use close_notify in any situation except for success. TLS libraries will not close TLS connections unless applications ask for that. Anything else is madness, TBH. > RFC 8446 allow an TLS implementation to send close_notify after receiving > client finished. The server might send it because of an error in the client > Finished or because it wants to close the connection for any reason. OK... > > Server > decides to close connection. > > EAP-Request/ > EAP-Type=EAP-TLS > <-------- (TLS close_notify) All that is normal and expected. > EAP-Response/ > EAP-Type=EAP-TLS --------> > <-------- EAP-Failure That seems wrong. > I don't if this would be common or expected behavior from the server, but if > EAP-TLS cannot enforce that this to not happen, then we cannot use > close_notify as an alternate success indication, because an alternate success > indication cannot be followed by EAP-Failure. Perhaps just update the document to say that such use-cases are forbidden? We can never prevent implementations from doing stupid things. But it is very useful for a specification to note the corner cases / error conditions, describe them, and explain why they're wrong and should not be used. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
