I still find the proposed Section 2.1 confusing. How about this? "If the TLS implementation correctly implements TLS version negotiation, EAP-TLS will automatically leverage that capability. The EAP-TLS implementation needs to know which version of TLS was negotiated to correctly support EAP-TLS 1.3 as well as to maintain backward compatibility with EAP-TLS 1.2.
TLS 1.3 changes both the message flow and the handshake messages compared to earlier versions of TLS. Therefore, much of Section 2.1 of [RFC5216] does not apply for TLS 1.3. Except for Sections 2.2 and 5.7 this document applies only when TLS 1.3 is negotiated. When TLS 1.2 is negotiated, then [RFC5216] applies." On Fri, Jun 18, 2021 at 10:15 PM John Mattsson <john.matts...@ericsson.com> wrote: > Hi Bernard, > > > > Thanks for your comments on backward compatibility. I think PR #83 > addresses your comments. I did not write anything about TLS 1.0 and TLS 1.1 > as RFC 8996 (which updates RFC 5216) formally forbids support and > negotiation of these weak versions. > > > > https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/83/files > > > > Below is how the two related paragraphs would look after merging #83. > > > > > > 1. Introduction: > > > > This document updates [RFC5216] to define how to use EAP-TLS with TLS 1.3. > When older TLS versions are negotiated, RFC 5216 applies to maintain > backwards compatibility. However, this document does provide additional > guidance on authentication, authorization, and resumption for EAP-TLS > regardless of the underlying TLS version used. This document only describes > differences compared to [RFC5216]. All message flow are example message > flows specific to TLS 1.3 and do not apply to TLS 1.2. Since EAP-TLS > couples the TLS handshake state machine with the EAP state machine it is > possible that new versions of TLS will cause incompatibilities that > introduce failures or security issues if they are not carefully integrated > into the EAP-TLS protocol. Therefore, implementations MUST limit the > maximum TLS version they use to 1.3, unless later versions are explicitly > enabled by the administrator. > > > > 2.1 Overview of the EAP-TLS Conversation: > > > > TLS 1.3 changes both the message flow and the handshake messages compared > to earlier versions of TLS. Therefore, much of Section 2.1 of [RFC5216] > does not apply for TLS 1.3. EAP-TLS 1.3 remains backwards compatible with > EAP-TLS 1.2 [RFC5216] . TLS version negotiation is handled by the TLS > layer, and thus outside of the scope of EAP-TLS. Therefore so long as the > underlying TLS implementation correctly implements TLS version negotiation, > EAP-TLS will automatically leverage that capability. Except for Sections > 2.2 and 5.7 this document applies only when TLS 1.3 is negotiated. When TLS > 1.2 is negotiated, then [RFC5216] applies. The EAP-TLS implementation needs > to know which version of TLS that was negotiated. > > > > Cheers, > > John > > > > > > *From: *Emu <emu-boun...@ietf.org> on behalf of Joseph Salowey < > j...@salowey.net> > *Date: *Monday, 14 June 2021 at 01:54 > *To: *Bernard Aboba <bernard.ab...@gmail.com> > *Cc: *EMU WG <emu@ietf.org> > *Subject: *Re: [Emu] EAP TLS 1.3 backward compatibility with RFC 5216 > > > > > > On Sun, Jun 13, 2021 at 2:44 PM Bernard Aboba <bernard.ab...@gmail.com> > wrote: > > draft-ietf-emu-eap-tls13-16 Section 2.1 contains the following text: > > > > EAP-TLS 1.3 remains backwards compatible with EAP-TLS 1.2 [RFC5216] . TLS > version > > negotiation is handled by the TLS layer, and thus outside of the > > scope of EAP-TLS. Therefore so long as the underlying TLS > > implementation correctly implements TLS version negotiation, EAP-TLS > > will automatically leverage that capability. > > > > I am concerned that this statement is potentially misleading. An > implementation of RFC 5216 that negotiates TLS 1.2 and utilizes the key > hierarchy defined in RFC 5216 Section 2.3 will not interoperate with an > implementation of draft-ietf-emu-tls13-16 that also negotiates TLS 1.2 and > utilizes the key hierarchy defined in Section 2.3 of that document. > > > > So in what sense is EAP-TLS 1.3 "backwards compatible" with EAP-TLS 1.2? > > > > The only way this makes sense to me is if it is stated that > draft-ietf-emu-eap-tls13 applies only when TLS 1.3 is negotiated, and that > if TLS 1.2, 1.1 or 1.0 is negotiated, then RFC 5216 applies. > > > > > > [Joe] Good point. I think this is missing from the draft. The EAP-TLS > implementation does need to know which version of TLS is negotiated. I > agree that this draft applies to when TLS 1.3 is negotiated and not > previous versions of TLS. > > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
