On Wed, Feb 10, 2021 at 10:48:10AM +0000, John Mattsson wrote: > With Alan's comments, I think we are down to 3 alternatives: > > (1a). Use close_notify alert as protected success. > Use error alerts as protected failure. > > - Forbid close_notify except as success indication > - Mandate Error alert before EAP-Failure > - Forbid all use of user_cancelled > > (1b). Use close_notify alert as protected success. > Use all other alerts as protected failure. > > - Forbid close_notify except as success indication > - Mandate Error alert or user_cancelled before EAP-Failure > > (2). Use application data as protected success. > Use all alerts as protected failure. > > - After sending application data in an EAP-Request the EAP-TLS server > MUST send only EAP-Success. > - Mandate alert (closure, error) before EAP-Failure > > I think it is important to discuss what the ongoing EMU consensus call will > mean in practice. Previous discussions was mostly about not sending more > handshake messages. Protected result indicators are quite different. > > It would we very good with early feedback from Ben and the TLS WG if they see > problems with any of the alternatives.
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. 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? I'd be happy to hear some more voices from the TLS WG chiming in to corroborate (or contradict) my conclusions in the first paragraph. Thanks, Ben _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
