Thanks, Mohit. You could also delete the entire paragraph because it adds nothing to what is already said in the TLS 1.3 spec. See https://github.com/hannestschofenig/draft-ietf-emu-eap-tls13/pull/1
Ciao Hannes From: Mohit Sethi M <mohit.m.se...@ericsson.com> Sent: Monday, November 2, 2020 9:58 AM To: Hannes Tschofenig <hannes.tschofe...@arm.com>; Mohit Sethi M <mohit.m.se...@ericsson.com>; emu@ietf.org Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec I now understand your issue with the sentence "An EAP-TLS peer and server SHOULD support the use of HelloRetryRequest message.". I guess there is no need for it, i.e., the section would be just fine without that sentence: TLS 1.3 [RFC8446] defines that TLS servers can send a HelloRetryRequest message in response to a ClientHello if the server finds an acceptable set of parameters but the initial ClientHello does not contain all the needed information to continue the handshake. One use case is if the server does not support the groups in the "key_share" extension, but supports one of the groups in the "supported_groups" extension. In this case the client should send a new ClientHello with a "key_share" that the server supports. As noted in Section 4.1.4 of [RFC8446], the server MUST provide the supported_versions extensions and SHOULD contain the minimal set of extensions necessary for the client to generate a correct ClientHello pair. A HelloRetryRequest MUST NOT contain any extensions that were not first offered by the client in its ClientHello, with the exception of optionally including the cookie extension. The case of a successful EAP-TLS mutual authentication after the server has sent a HelloRetryRequest message is shown in Figure 8. Note the extra round-trip as a result of the HelloRetryRequest. Commit on git: https://github.com/emu-wg/draft-ietf-emu-eap-tls13/commit/d4ac353a90dc7466d6da9deb5f50f4eb7c585e9b --Mohit On 11/2/20 9:39 AM, Hannes Tschofenig wrote: Hi Mohit, I read Jim's email and he is not saying that you should make it an optional to support feature. The issue is: - are you trying to change the functionality of TLS 1.3 with this draft, and - is there a good reason to do so? In this case, the "SHOULD" statement gives an implementer absolutely not idea when or when it would be good to implement this feature. Besides this, I don't even believe that the TLS 1.3 spec gives you that freedom for this specific feature anyway. Ciao Hannes From: Mohit Sethi M <mohit.m.se...@ericsson.com><mailto:mohit.m.se...@ericsson.com> Sent: Saturday, October 31, 2020 6:04 PM To: Hannes Tschofenig <hannes.tschofe...@arm.com><mailto:hannes.tschofe...@arm.com>; emu@ietf.org<mailto:emu@ietf.org> Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec Hi Hannes, Jim Schaad had asked for this: https://mailarchive.ietf.org/arch/msg/emu/XpRkNN-mh5BuiTD1O8iEfz9sM4M/ It is still optional to use. The figure only shows what the exchange would look like if a HRR was sent by the server. --Mohit On 10/21/20 12:16 PM, Hannes Tschofenig wrote: Hi all, Section 2.1.6 says: " An EAP-TLS peer and server SHOULD support the use of HelloRetryRequest message. " My understanding of the TLS 1.3 specification is that the HelloRetryRequest is not an optional-to-implement message but it is only optional to use. Is there a reason to deviate from the TLS 1.3 specification? Is there any reason to talk about the HRR message? The purpose of the message is given in the TLS 1.3 spec and whether you use it or not is up to the deployment. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ Emu mailing list Emu@ietf.org<mailto:Emu@ietf.org> https://www.ietf.org/mailman/listinfo/emu IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ Emu mailing list Emu@ietf.org<mailto:Emu@ietf.org> https://www.ietf.org/mailman/listinfo/emu IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
