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) <slitk...@cisco.com> > 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
