Re: [Pce] Review of draft-dhody-pce-pceps-tls13
> On Oct 17, 2023, at 21:34, Sean Turner wrote: > > Stephane, > > Thanks for the comments and sorry it’s taken me so long to respond. These > comments made me entirely rethink what’s in the I-D. I was way too focused on > maintaining alignment with draft-ietf-netconf-over-tls13 and that should not > have been something to fixate on. > >> On Sep 19, 2023, at 09:26, Stephane Litkowski (slitkows) >> wrote: >> >> Hi WG, >> >> Chairs requested me to review draft-dhody-pce-pceps-tls13. >> Here are couple of comments regarding the draft, I’m not an expert in this >> area, so my comments may sometimes be inaccurate: >> >> Intro: >> • As RFC8253 is already making TLS 1.2 as required (Section 3.4 of >> RFC8253), why does this draft cares about “address support requirements for >> TLS 1.2” ? What is missing in RFC8253 ? >> >> >> >> Section 4: >> • The two first paragraph related to TLS1.2 are already covered by >> RFC8253 section 3.4, what is changing ? >> >> • Regarding: “Implementations that support TLS 1.3 >> [I-D.ietf-tls-rfc8446bis] are REQUIRED to support the mandatory-to-implement >> cipher suites listed in Section 9.1 of [I-D.ietf-tls-rfc8446bis].¶ >> • This is already mandated as per TLS1.3 draft (Section 9.1), >> so is the purpose of defining specific requirement for PCEP app ? > > In thinking about what’s missing, I have come to realization that really only > two things are: > > 1) A statement about what to do if an PCEPS implementation supports more than > one version of TLS. I tend to think that if a connection can support a later > version it should. > > 2) A statement about not supporting TLS 1.3’s early data. And, maybe some > text about what early data is and why we’re saying anything about it at all. > > I think we can do that by adding two restrictions to those that are already > listed in s3.4 Step 1 and a couple of notes. So, I thought what if we recast > the entire draft to do exactly that. Let me know what you think about the > following PR: > https://github.com/ietf-wg-pce/draft-ietf-pce-pceps-tls13/pull/11 > > >> Security considerations: >> • I don’t see Security considerations of RFC8253 referred in the >> section ? shouldn’t the draft build on top of it ? Is there any new >> consideration compared to RFC8253 brought by TLS1.3? > > Yeah those ought to be there too. See the following PR: > https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/ #cutpastefail try: https://github.com/ietf-wg-pce/draft-ietf-pce-pceps-tls13/pull/10 >> Brgds, >> >> Stephane > > Cheers, > spt > ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WGLC for draft-ietf-pce-pceps-tls13-01
Hi Cheng, Sorry it’s taken me so long to get back to this. Stephane’s comment resulted in a fair number of changes. It short I recast the draft to focus much more on your 0 comment. Now it’s a little more clear about what’s being added. Just two things that I highlighted in my message to the list: https://mailarchive.ietf.org/arch/msg/pce/5EBnkSeD5q7c55V9e2PfnIY88-0/ Cheers, spt > On Sep 13, 2023, at 09:06, Cheng Li wrote: > > Hi PCE, > > I support the WGLC. The draft is simple but useful, we should move it to RFC > very fast. > > Some editorial comments: > > 0. Title of this draft is unclear, what is update of PCEPS. Good to explain > more clear. > > 1. Abstract: > This document updates RFC 8253 to address support requirements for TLS 1.2 > and TLS 1.3 and the use of TLS 1.3's early data. > > Address? To many meanings for this word, we may change it by another? > Describe? Same for the one in introduction. > > 2. Section 4. > I think the name of this section is not clear. This section describes the > requirements in implementation. Should change to Requirements? > However, section use Early Data as a title, then we should add a section > called requirements and move section 3 and 4 into this section? > > 3.Section 4 > Implementations MUST support TLS 1.2 [RFC5246] and are REQUIRED to support > the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite [RFC9325]. > > __NEW__ > Implementations MUST support TLS 1.2 [RFC5246] and the > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite [RFC9325]. > > 4. > Implementations SHOULD support TLS 1.3 [I-D.ietf-tls-rfc8446bis] and, if > implemented, MUST prefer to negotiate TLS 1.3 over earlier versions of TLS. > > If a SHOULD is used here, then I do not see the value of this draft. I > suggest to use MUST here. Unless some features in the draft is not in the > scope of TLS1.3. > So we don’t need to assume the case of supporting TLS1.3. > > 5. Section 5 > > The Security Considerations of PCEP [RFC5440], [RFC8231], [RFC8281], and > [RFC8283]; TLS 1.2 [RFC5246]; TLS 1.3 [I-D.ietf-tls-rfc8446bis], and; > [RFC9325] apply here as well. > > __NEW__ > The Security Considerations of PCEP [RFC5440], [RFC8231], [RFC8281], and > [RFC8283]; TLS 1.2 [RFC5246]; TLS 1.3 [I-D.ietf-tls-rfc8446bis], and; > [RFC9325] apply to this document as well. > > I am not sure that the second paragraph should be added or it will be better > to add into the introduction? > > The rest looks good to me. > > Many thanks, > Cheng > > > > > -Original Message- > From: Pce On Behalf Of julien.meu...@orange.com > Sent: Tuesday, September 5, 2023 11:10 AM > To: pce@ietf.org > Subject: [Pce] WGLC for draft-ietf-pce-pceps-tls13-01 > > Dear PCE WG, > > This message starts a 2-week WG last call on > draft-ietf-pce-pceps-tls13-01 [1]. Please, be express any comments you have > about this document using the PCE mailing list. > > This WGLC will end on Wednesday 20th September 2023. > > Thanks, > > Julien > > -- > [1] https://datatracker.ietf.org/doc/draft-ietf-pce-pceps-tls13/ > ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Review of draft-dhody-pce-pceps-tls13
Stephane, Thanks for the comments and sorry it’s taken me so long to respond. These comments made me entirely rethink what’s in the I-D. I was way too focused on maintaining alignment with draft-ietf-netconf-over-tls13 and that should not have been something to fixate on. > On Sep 19, 2023, at 09:26, Stephane Litkowski (slitkows) > wrote: > > Hi WG, > > Chairs requested me to review draft-dhody-pce-pceps-tls13. > Here are couple of comments regarding the draft, I’m not an expert in this > area, so my comments may sometimes be inaccurate: > > Intro: > • As RFC8253 is already making TLS 1.2 as required (Section 3.4 of > RFC8253), why does this draft cares about “address support requirements for > TLS 1.2” ? What is missing in RFC8253 ? > > > > Section 4: > • The two first paragraph related to TLS1.2 are already covered by > RFC8253 section 3.4, what is changing ? > > • Regarding: “Implementations that support TLS 1.3 > [I-D.ietf-tls-rfc8446bis] are REQUIRED to support the mandatory-to-implement > cipher suites listed in Section 9.1 of [I-D.ietf-tls-rfc8446bis].¶ > • This is already mandated as per TLS1.3 draft (Section 9.1), > so is the purpose of defining specific requirement for PCEP app ? In thinking about what’s missing, I have come to realization that really only two things are: 1) A statement about what to do if an PCEPS implementation supports more than one version of TLS. I tend to think that if a connection can support a later version it should. 2) A statement about not supporting TLS 1.3’s early data. And, maybe some text about what early data is and why we’re saying anything about it at all. I think we can do that by adding two restrictions to those that are already listed in s3.4 Step 1 and a couple of notes. So, I thought what if we recast the entire draft to do exactly that. Let me know what you think about the following PR: https://github.com/ietf-wg-pce/draft-ietf-pce-pceps-tls13/pull/11 > Security considerations: > • I don’t see Security considerations of RFC8253 referred in the > section ? shouldn’t the draft build on top of it ? Is there any new > consideration compared to RFC8253 brought by TLS1.3? Yeah those ought to be there too. See the following PR: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/ > > Brgds, > > Stephane Cheers, spt ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce