Joseph Salowey <[email protected]> wrote: > There is growing support for mandating result indicators for EAP-TLS > 1.3. The result indicators help protect the EAP protocol exchange in > the many different types of environments EAP-TLS is used and make the > integration with the EAP state machine clearer. This has the impact of > adding a round trip to EAP-TLS 1.3 making a total of 4.5 round trips. > It may be possible to optimize this exchange, but that would need > further study and would be beyond the scope of this effort.
> This consensus call has two parts:
> 1. Please respond to the list if you support adding explicit result
> indications of success and failure from the EAP Server to the EAP Peer
> in EAP-TLS 1.3. If you object please respond to the list indicating
> why.
I support this.
> 2. Please respond to the list if you support using TLS close_notify
> alert for a success indication and TLS error alert for a failure
> indication. If you object please respond to the list indicating why.
As I understand it, it is the use of Close_Notify that pushes us to 4.5 round
trips.
Given a client-certificate (or chain) of >1500 bytes more than one packet would
be
required send that, and I believe that we can't send Close_Notify until the
certificate has been communicated (and verified).
So my question is: is this really 3.5 round trips -> 4.5 round trips, or is
it really more like that we are going from perhaps 5.5 round trips to 6.5
round trips (for example).
I posit this, because I think that the increase in round trip count is
largely irrelevant on non-challenged (RFC7228 term) networks.
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
