Subject: [Emu] EAP-TLS and TLS alerts

From: John Mattsson <[email-masked]>
Date: Fri, 5 Feb 2021 19:36:58 +0000

Hi,

Alerts are definitly not mandatory in TLS 1.3. Adding a note stating that alerts are not mandatory seems like a good idea. But "suggests" seems like the wrong word and optional != SHOULD.

I would like more feedback from other people before adding new requirements on TLS. Can an application typically enforce Error alerts in TLS?

John

---

From: John Mattsson <[email-masked]>
Date: Fri, 5 Feb 2021 19:46:25 +0000

Hi,

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.....

Maybe you should ask the TLS WG.

John

-----Original Message-----
From: John Mattsson <[email-masked]>
Date: Friday, 5 February 2021 at 20:36
To: EMU WG <[email-masked]>
Subject: [Emu] EAP-TLS and TLS alerts

Hi,

John

---

From: Alan DeKok <[email-masked]>
Date: Fri, 5 Feb 2021 14:53:18 -0500

> 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.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 5 Feb 2021 15:02:54 -0500

>  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.

  Typo, sorry.  It "could" discard the TLS alert and send EAP-Failure.

  I would suggest instead that it MUST send the TLS alert before any EAP-Failure.

  One reason is that currently, the EAP layer has no reliable indication that the TLS layer failed.  It *could* just get an EAP-Failure at any point.  Which makes implementations fragile and awkward.

  If instead EAP-TLS 1.3 mandates sending a TLS alert *before* EAP-Failure, then this meets the "altReject" criteria of RFC 4137.  And implementations know exactly what to expect, and when.

  Alan DeKok/