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

2023-10-17 Thread Sean Turner


> 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

2023-10-17 Thread Sean Turner
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

2023-10-17 Thread Sean Turner
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