On Feb 5, 2021, at 2:46 PM, John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org> wrote: > > I see now that the two paragraphs you send seems to be contradicting each > other > > https://tools.ietf.org/html/rfc8446#section-2 > > A failure of the handshake or other protocol error triggers the > termination of the connection, optionally preceded by an alert > message (Section 6). > > https://tools.ietf.org/html/rfc8446#section-6.2 > > Whenever an implementation encounters a fatal error condition, it > SHOULD send an appropriate fatal alert and MUST close the connection > without sending or receiving any additional data. > > Unclear if Error alert is optional or SHOULD.....
SHOULD sent it with no ADDITIONAL data. That seems clear to me. As for "Can an application typically enforce Error alerts in TLS?" the answer is "not as such, no". The TLS layer generally *will* produce TLS alerts. The application has the choice whether or not to send them. i.e. it should just discard the TLS alerts, and instead send EAP-Failure. My suggestion here is to document and mandate this behaviour. This matches ~15 years of existing practice. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
