Re: [Pce] Review of draft-dhody-pce-pceps-tls13

[Sean Turner <[e-mail]>]

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) <[e-mail]> 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