On Sun, Feb 14, 2021 at 6:47 PM Benjamin Kaduk <ka...@mit.edu> wrote:
> 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. > > [Joe] In the past handling of close_notify was one of the rougher parts of TLS implementations. I'm not sure how much it has improved. > 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? > > [Joe] TEAP already has a result indicator within the tunnel, so it would not need to use the same machinery. I believe that many of the other tunnel methods have something similar, so I would expect tunneled methods to use their own mechanism as a result indication. > 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 > > _______________________________________________ > Emu mailing list > e...@ietf.org > https://www.ietf.org/mailman/listinfo/emu >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
