Archive

On Sun, Feb 14, 2021 at 6:47 PM Benjamin Kaduk <kaduk@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
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>

Re: [TLS] [Emu] Protected Result Indicators in EAP-TLS 1.3