Alan DeKok 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.
Jorge said offline that he also wanted this behaivior. I will update the draft to make TLS Error alerts mandatory to send. Maybe the draft should summarize the profiling EAP-TLS 1.3 does on TLS 1.3 - OCSP stapling mandatory to support for server - Only cipher suites with confidentiality - MUST send Erros alert. >> 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? I already did that when I added text to the GitHub version on alternative success indicatiors. If close_notify is to be used as an alternative success indicatiors, forbidding and enforcing this is essential, otherwise, close_notify cannot be used. Cheers, John _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
