On Feb 14, 2021, at 9:46 PM, Benjamin Kaduk <ka...@mit.edu> wrote: > On first look it seems like all of those will be able to achieve the > required properties. In some sense it is "probably" going to be "easier" > for an application using TLS to use TLS application data (as opposed to > alerts) to affect its behavior, though I believe that TLS implementations > generally do provide the needed information about received alerts and > flexibility in what alert to send that's needed for the (1) variants.
close_notify seems to work fine for EAP-TLS with multiple peer / server implementations, and at least 2 TLS library implementations. > Another potential factor that I'm not (currently) equipped to evaluate is > the reusability of the machinery defined by EAP-TLS for use by other EAP > mechanisms. E.g., if we say that for EAP-TLS any application data is a > protected success, would that be in conflict with any scenarios for the EAP > mechanisms that do have to send some data on the TLS application data > stream? Implementation so far shows no. The patches to make PEAP / TTLS work with TLS 1.3 are relatively minor. Mostly updating the key exporters. We have protected success / failure indicators for EAP-TLS 1.3. I think that's a positive step. The question for the other EAP methods is "do we need protected success / failure indicators". As Joe noted, TEAP already provides them in the inner tunnel, as does PEAP (with inner MS-CHAP), or TTLS (with inner MS-CHAP. TTLS with inner PAP / CHAP doesn't provide them. If we're willing to live without those indicators for other TLS-based EAP methods, then draft-dekok-emu-tls-eap-types is essentially done. It needs some minor updates, but there are no major protocol questions left open. Alan DeKok. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
