Hi, I think it is important to point out that the discussion has been about _protected_ result indications. RFC 3748 discussed protected and non-protected result indications. Also worth noting that it is not possible with protected failure indication when the server does not accept the ClientHello.
Michael Richardson wrote: >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). For a full handshake it is probably more like 10.5 -> 11.5 roundtrips or more. Certificate chains are large and EAP-TLS typically sends 2 of them. For resumption is might 3.5 round trips -> 4.5. In cases a no-more-handshake indication is needed anyway to ease implementation, or in cases where the server wants client finished before sending newsessionticket, there is probably no increase at all. John -----Original Message----- From: Emu <[email protected]> on behalf of Michael Richardson <[email protected]> Date: Sunday, 7 February 2021 at 03:21 To: EMU WG <[email protected]> Subject: Re: [Emu] Consensus call for result indicators in EAP-TLS 1.3 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 _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
