Re: [Pce] I-D Action: draft-ietf-pce-pceps-tls13-04.txt
Hi! This version addresses comments from the IESG. I believe this I-D is now ready for the RFC Editor’s queue. Cheers, spt > On Jan 9, 2024, at 12:14, internet-dra...@ietf.org wrote: > > Internet-Draft draft-ietf-pce-pceps-tls13-04.txt is now available. It is a > work item of the Path Computation Element (PCE) WG of the IETF. > > Title: Updates for PCEPS: TLS Connection Establishment Restrictions > Authors: Dhruv Dhody >Sean Turner >Russ Housley > Name:draft-ietf-pce-pceps-tls13-04.txt > Pages: 6 > Dates: 2024-01-09 > > Abstract: > > Section 3.4 of RFC 8253 specifies TLS connection establishment > restrictions for PCEPS; PCEPS refers to usage of TLS to provide a > secure transport for PCEP (Path Computation Element Communication > Protocol). This document adds restrictions to specify what PCEPS > implementations do if they support more than one version of the TLS > protocol and to restrict the use of TLS 1.3's early data. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-pce-pceps-tls13/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-pce-pceps-tls13-04.html > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-pceps-tls13-04 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > ___ > I-D-Announce mailing list > i-d-annou...@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Murray Kucherawy's No Objection on draft-ietf-pce-pceps-tls13-03: (with COMMENT)
More inline... > On Jan 4, 2024, at 01:02, Murray Kucherawy via Datatracker > wrote: > > Murray Kucherawy has entered the following ballot position for > draft-ietf-pce-pceps-tls13-03: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-pce-pceps-tls13/ > > > > -- > COMMENT: > -- > > Further to Eric's comment, I'm completely confused by question #4 of the > shepherd writeup. While the document claims there are no implementations > known, the shepherd writeup says there's at least one (and it was easy), and > makes another "Yes" remark that I don't understand. Addressed in an earlier email. > Forwarding a comment from Orie Steele, incoming ART Area Director: > > Noting the comment on 0-RTT / early data regarding secrecy, and the comment on > https://datatracker.ietf.org/doc/html/rfc8253#section-3.4 > > * Negotiation of a ciphersuite providing for confidentiality is RECOMMENDED. > > I'm not an expert on PCEPS, but I wonder why the need for the note at all > given > PCEPs only recommends confidentiality, and the requirement above states early > data is forbidden. Ah okay I see you saying the bit about not forward secret isn’t really needed here if confidentiality is just recommended. I think practical terms though confidentiality is a MUST because all the ciphersuites in s3.4 of RFC 8253 use AES_GCM. In terms of this I-D thought, we could do: OLD: In particular, early data is not forward secret, and there is no protection against the replay of early data between connections. NEW: In particular, no replay protection is provided for early data. However, the sentence as written is true. So …. should I take out the reference to FS or leave it in? spt ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Murray Kucherawy's No Objection on draft-ietf-pce-pceps-tls13-03: (with COMMENT)
> On Jan 4, 2024, at 01:12, Dhruv Dhody wrote: > > Hi Murray, > > On Thu, Jan 4, 2024 at 11:30 AM Murray Kucherawy via Datatracker > wrote: > Murray Kucherawy has entered the following ballot position for > draft-ietf-pce-pceps-tls13-03: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-pce-pceps-tls13/ > > > > -- > COMMENT: > -- > > Further to Eric's comment, I'm completely confused by question #4 of the > shepherd writeup. While the document claims there are no implementations > known, the shepherd writeup says there's at least one (and it was easy), and > makes another "Yes" remark that I don't understand. > > > > Dhruv: The shepherd writeup mentions this email response on the mailing list > - https://mailarchive.ietf.org/arch/msg/pce/dLdcUan2psssBUgzCtXPluEr_ok/ that > mentions some implementation experience. When we asked to include that > information in the implementation section we did not get a confirmation back. > Soo that's that :) > > We could update the implementation section to say - > > OLD: >At the time of posting the -02 version of this document, there are no >known implementations of this mechanism. > NEW: >At the time of posting the -04 version of this document, there are no >known implementations of this mechanism. It is believed that one >vendor has implementation, but these plans are too vague to make >any further assertions. > END > > Thanks! > Dhruv see: https://github.com/ietf-wg-pce/draft-ietf-pce-pceps-tls13/pull/21 spt ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Paul Wouters' Yes on draft-ietf-pce-pceps-tls13-03: (with COMMENT)
> On Jan 3, 2024, at 17:13, Paul Wouters via Datatracker > wrote: > > Paul Wouters has entered the following ballot position for > draft-ietf-pce-pceps-tls13-03: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-pce-pceps-tls13/ > > > > -- > COMMENT: > -- > > Implementations that support multiple versions of the TLS protocol MUST > prefer to negotiate the latest version of the TLS protocol. > > I'm a little confused why this needs to be stated as an update, as this is a > general requirement of TLS (or any versioned protocol really) I hear this phrase all the time: There is no document that specifies how to do protocol X with Y. You can reply that the “normal” updates procedure addresses this issue, but 99 times out of 100 times you’re going to get a quizzical look. This statement closeout that discussion. > It might be useful to point to > https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.1 that deals with > how > to negotiate allowing TLS 1.2 when also supporting and preferring TLS 1.3. I mean if everybody read and remembered all the detail … More seriously, without this document there are some I believe that wouldn’t ever have read RFC 8446 and happy move along. I can add a ref to 4.2.1; see the following PR: https://github.com/ietf-wg-pce/draft-ietf-pce-pceps-tls13/pull/20 Cheers, spt ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Éric Vyncke's No Objection on draft-ietf-pce-pceps-tls13-03: (with COMMENT)
> On Jan 2, 2024, at 08:58, Dhruv Dhody wrote: > > Hi Èric, > > Happy 2024! > > On Tue, Jan 2, 2024 at 6:03 PM Éric Vyncke via Datatracker > wrote: > Éric Vyncke has entered the following ballot position for > draft-ietf-pce-pceps-tls13-03: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-pce-pceps-tls13/ > > > > -- > COMMENT: > -- > > > # Éric Vyncke, INT AD, comments for draft-ietf-avtcore-rtp-scip-05 > > Thank you for the work put into this document. It was an easy and simple read > for my first document review in 2024! > > Please find below some non-blocking COMMENT points (but replies would be > appreciated even if only for my own education). > > Special thanks to Andrew Stone for the shepherd's detailed write-up including > the WG consensus and the justification of the intended status. > > I hope that this review helps to improve the document, > > Regards, > > -éric > > # COMMENTS (non-blocking) > > ## Section 1 > > Is it a `Editor's Note:` or a "Note to the IESG" or a "Note to the RFC > Editor" ? > > Dhruv: It was an Editor's note while we were working on the I-D. At this > stage perhaps we can just remove the note now and stick it out with the fate > of RFC8446bis (which is in the post-WGLC stage). Sean and Russ should chime > in if they disagree :) I was a note to everybody ;) Well technically the audience changed as we marched through the process. It can safely be deleted post IESG comments: https://github.com/ietf-wg-pce/draft-ietf-pce-pceps-tls13/pull/18 > ## Section 3 > > `MUST prefer to negotiate the latest version` is of course the preferred > behavior for the initiator, but should the document clearly specify that the > responser "MUST select the latest version" ? (please bear with me as English > is > not my primary language). > > Dhruv: FWIW I see the phrase usage in RFC 9325 as well as in the netconf tls > 1.3 I-D which was in a recent IESG telechat! ¯\_(ツ)_/¯ Yes it’s in 9325 and negotiate is a two way thing. > ## Section 6 > > I wonder about the usefulness of an implementation section having `there are > no > known implementations of this mechanism.` > > Dhruv: PCE WG set out an Implementation Section Policy listed at > https://wiki.ietf.org/group/pce/ImplementationPolicy > We wanted the WG and the IETF community to be aware of known implementations > (or lack thereof) at the time of approval, at publication the section is > anyway removed. Yep will remove this when we get to the RFC editor queue. Cheers, spt ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] I-D Action: draft-ietf-pce-pceps-tls13-03.txt
Hi! This version incorporates the IETF LC comments received to date. spt > On Dec 19, 2023, at 21:31, internet-dra...@ietf.org wrote: > > Internet-Draft draft-ietf-pce-pceps-tls13-03.txt is now available. It is a > work item of the Path Computation Element (PCE) WG of the IETF. > > Title: Updates for PCEPS: TLS Connection Establishment Restrictions > Authors: Dhruv Dhody >Sean Turner >Russ Housley > Name:draft-ietf-pce-pceps-tls13-03.txt > Pages: 6 > Dates: 2023-12-19 > > Abstract: > > Section 3.4 of RFC 8253 specifies TLS connection establishment > restrictions for PCEPS; PCEPS refers to usage of TLS to provide a > secure transport for PCEP (Path Computation Element Communication > Protocol). This document adds restrictions to specify what PCEPS > implementations do if they support more than one version of the TLS > protocol and to restrict the use of TLS 1.3's early data. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-pce-pceps-tls13/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-pce-pceps-tls13-03.html > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-pceps-tls13-03 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] AD review of draft-ietf-pce-pceps-tls13-02
John, Now that the I-D has been placed on the 1/4 telechat should I spin a new version that incorporates the outstanding PRs: https://github.com/ietf-wg-pce/draft-ietf-pce-pceps-tls13/pulls spt > On Dec 5, 2023, at 12:03, John Scudder wrote: > > Hi Authors, > > Thanks for this document. Looks good, I've requested IETF last call. > > A couple of notes below, they didn't seem worth holding up the last call for, > but please consider them for your next revision. > > - "what PCEPS implementations do if a PCEPS supports more than one version". > I don't think PCEPS (second occurrence) takes an article (i.e. referring to > "a PCEPS" is weird). Some rewrite seems called for, perhaps s/a PCEPS/one/. > > - "neither the PCC nor the PCE should establish a PCEPS with > TLS connection with an unknown, unexpected, or incorrectly identified > peer;" > > Isn't "PCEPS with TLS" redundant, doesn't the ess in PCEPS imply TLS? In > which case, just drop "with TLS". (See also, "ATM machine" :-) > > Thanks, > > —John ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] AD review of draft-ietf-pce-pceps-tls13-02
> On Dec 5, 2023, at 12:03, John Scudder wrote: > > Hi Authors, > > Thanks for this document. Looks good, I've requested IETF last call. > > A couple of notes below, they didn't seem worth holding up the last call for, > but please consider them for your next revision. > > - "what PCEPS implementations do if a PCEPS supports more than one version". > I don't think PCEPS (second occurrence) takes an article (i.e. referring to > "a PCEPS" is weird). Some rewrite seems called for, perhaps s/a PCEPS/one/. This was also noted during the RTGDIR review. I suggested the following change: https://github.com/ietf-wg-pce/draft-ietf-pce-pceps-tls13/pull/13/files > - "neither the PCC nor the PCE should establish a PCEPS with > TLS connection with an unknown, unexpected, or incorrectly identified > peer;" > > Isn't "PCEPS with TLS" redundant, doesn't the ess in PCEPS imply TLS? In > which case, just drop "with TLS". (See also, "ATM machine" :-) It is! It would also be like saying HTTPS with TLS :) I did end deleting that para though while addressing the RTGDIR comments. > Thanks, > > —John Cheers, spt ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] RtgDir Early review: draft-ietf-pce-pceps-tls13-02
> On Nov 13, 2023, at 04:07, Tal Mizrahi wrote: > > Hello > > I have been selected to do a routing directorate “early” review of this draft. > https://datatracker.ietf.org/doc/draft-ietf-pce-pceps-tls13/ Hi! And, thanks for your review. I have created an issue to track this review: https://github.com/ietf-wg-pce/draft-ietf-pce-pceps-tls13/issues/15 > The routing directorate will, on request from the working group chair, > perform an “early” review of a draft before it is submitted for > publication to the IESG. The early review can be performed at any time > during the draft’s lifetime as a working group document. > > For more information about the Routing Directorate, please see > https://wiki.ietf.org/en/group/rtg/RtgDir > > Document: draft-ietf-pce-pceps-tls13-02 > Reviewer: Tal Mizrahi > Review Date: Nov 13, 2023 > Intended Status: Standards Track > > Summary: > I have some concerns about this document that I think should be > resolved before it is submitted to the IESG. > > Comments: > The draft is clear and straightforward. There is one main comment that > needs to be addressed. > > Major comment: > The "Security Considerations" section needs to describe the security > considerations that are specific to the current document. For example, > the second note of Section 3, and perhaps some more text that explains > why this is important. The existing text in this section is not > helpful to the reader. The section cites 9 references with a brief > description of each reference, but without the description of the > security considerations of each reference. The last paragraph of the > section - is it relevant to the current document? It would be best to > stick with security considerations that are strictly relevant to the > current document, and not to PCE in general. Ah yes, I “fixed” the main body and ignored the Security Considerations. I tend to agree we should edit it. Since this I-D is essentially adding a couple of bullets to an existing RFC, we are adopting all of those considerations and the PCEP considerations. This I-D also addresses TLS 1.2 and TLS 1.3 protocols and recommendations for those protocols. So, that’s the 1st para. Note the WG asked to add more PCEP related security considerations; see: https://github.com/ietf-wg-pce/draft-ietf-pce-pceps-tls13/pull/10/files I tend to think the 2nd and 3rd paragraph can be dropped entirely now. As for repeating/expanding on the 2nd NOTE in s3: if the text of this I-D was incorporated in a replacement for RFC 8253 and was 10 pages away from the security considerations. I could see repeating/expanding it. As it is right now, that bullet is immediately proceeds the Security Considerations. Further, that text is additionally incorporated by reference from TLS 1.3 and RFC 9325 so I tend to think it’s kind of covered and doesn’t need more text. Again, I could see repeating the bullet or moving that bullet, but because this document is so short it seems like overkill. I created a PR that incorporates these changes: https://github.com/ietf-wg-pce/draft-ietf-pce-pceps-tls13/issues/15 >> https://www.ietf.org/archive/id/draft-ietf-pce-pceps-tls13-02.html#name-security-considerations >> ? >> >> As for expanding on the 2nd note, I think repeating the text is a bad idea - >> I’d rather refer there again as follows: >> >> As noted in Section 3, Section 2.3 of [I-D.ietf-tls-rfc8446bis] identifies >> that the security properties for early data are weaker than those for >> subsequent TLS-protected data. In particular, early data is not forward >> secret, and there is no protection against the replay of early data between >> connections. > Nits: > - "if a PCEPS supports more than one version" - the sentence is not > clear. Perhaps "if a PCEPS implementation supports more than one > version"? > - Section 4 - second paragraph - there is a missing period at the end > of the paragraph. Fixed these via: https://github.com/ietf-wg-pce/draft-ietf-pce-pceps-tls13/pull/13 Cheers, spt ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
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
Re: [Pce] Shepherd Review of draft-ietf-pce-pceps-tls13-01
> On Oct 1, 2023, at 22:34, Andrew Stone (Nokia) wrote: > > Hi Russ, WG, > > Responses inline below. > > Thanks > Andrew > > From: Russ Housley > Date: Wednesday, September 27, 2023 at 11:50 AM > To: "Andrew Stone (Nokia)" > Cc: "draft-ietf-pce-pceps-tl...@ietf.org" > , "pce@ietf.org" > Subject: Re: Shepherd Review of draft-ietf-pce-pceps-tls13-01 > > > CAUTION: This is an external email. Please be very careful when clicking > links or opening attachments. See the URL nok.it/ext for additional > information. > > > > >> On Sep 27, 2023, at 11:02 AM, Andrew Stone (Nokia) >> wrote: >> >> Hi authors of draft-ietf-pce-pceps-tls13, >> >> I’ve been selected as the document shepherd for this draft. >> >> Thank you for the work on this document. The direct references to >> draft-ietf-tls-rfc8446bis sections were useful and the document is well >> written. >> >> From a quick peak at messages from [1], it seems like WGLC consensus was >> reached on draft-ietf-tls-rfc8446bis + some follow up discussions which >> appear to be resolved(?) thus draft-ietf-tls-rfc8446bis is also pending a >> Shepherd writeup. It seems both documents are in similar same state (?). >> Given the size and complexity differences I assume draft-ietf-tls-rfc8446bis >> will progress slower than this document (as hinted by editor note in the >> introduction as well), is the plan to still continue with the bis as a >> normative reference? >> >> Taking into consideration the outstanding review comments [2], [3], some >> additional comments/questions from reading -01: >> >> # From ID NITS: >> >> • >Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) >> • (Considering the use inside the document and what is intended >> by referencing it I believe this is okay, but still wanted to point it out >> that it’s been picked up by the tool) > > This reference is correct. > > ACK > >> # Comments: >> >>> >> • Abstract: uses "TLS" abbreviation, should be changed to: "..PCEP >> messages with Transport Layer Security (TLS) 1.2..." >> >> • I was similarly unclear as Stephane regarding what does this document >> update for TLS 1.2 on RFC8253, but after going over it a few times, >> concluded this updates RFC8253 by bringing in RFC9325 recommendations and >> applying it to TLS 1.2 in the RFC8253 context. Is that the case? If so, it >> would be clearer in the introduction to make the point that RFC8253 TLS. 1.2 >> usage is being updated with recommendations from RFC5246. > > We originally wrote a document that only talked about TLS 1.3, but the WG > felt that it was better to update RFC 8253 to cover TLS 1.2 and TLS 1.3. > > ACK, Sounds good to me then. > > >> • Editor Note in the Introduction should remark also updating appendix >> references in the document if draft-ietf-tls-rfc8446bis normative referenced >> is reduced to RFC8446 >> >> • Section 3 paragraph 2 – Replace E.5 with F.5 for the bis reference >> (…not use early data without a profile..). E.5 is correct for rfc8446, but >> is F.5 in draft-ietf-tls-rfc8446bis. >> >> • Similar question to Stephanes regarding why no reference to RFC8253 >> in the security considerations? is one required and does this actually >> update RFC8253 security considerations? As well, the second paragraph seems >> like it can be removed as all it seems to dop is re-describe what PCE/PCEP >> is without discussing the security considerations or any explicit >> consideration updates. > > Do we want to be blocked on the publication of draft-ietf-tls-rfc8446bis? > > At this moment I suspect not, but would defer this to the WG as a > whole and the PCE WG chairs. My own opinion is this doesn’t seem to have an > explicit requirement on the BIS and happy to see it move forward with the > base RFC8446 reference. Chairs, WG input? I should note that 8446 is pinned on the TLS chairs getting their act together, which hopefully shouldn’t take all that long to unwind. I’m also not sure there’s harm in waiting a bit. But, I will totally bend to the will of the WG :) spt >> # Suggestion: >> >>> >> OLD: >> Note that TLS 1.3 can be used without early data as per Appendix F.5 of >> [I-D.ietf-tls-rfc8446bis]. In fact, early data is permitted by TLS 1.3 only >> when the client and server share a Pre-Shared Key (PSK), either obtained >> externally or via a previous handshake. >> >> NEW: >> TLS 1.3 can be used without early data as per Appendix F.5 of >> [I-D.ietf-tls-rfc8446bis], and allows early data only if both the client and >> server possess a shared Pre-Shared Key (PSK) obtained externally or from a >> previous handshake. > > This depends on the answer to blocking on the publication of > draft-ietf-tls-rfc8446bis. > > Russ ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] IPR poll for draft-ietf-pce-pceps-tls13
Hi Andrew, I am not aware of any IPR applicable to this draft that should be disclosed in accordance with IETF IPR rules. Thanks! spt Sent from my iPhone > On Sep 5, 2023, at 11:26, Andrew Stone (Nokia) wrote: > > > Hi Authors, > > In preparation for WGLC on this draft, we'd like all authors and contributors > to confirm on the list that they are in compliance with IETF IPR rules. > > Please respond (copying the mailing list) to say one of: > > - I am not aware of any IPR applicable to this draft that should be disclosed > in accordance with IETF IPR rules. > - I am aware of the IPR applicable to this draft, and it has already been > disclosed to the IETF. > - I am aware of IPR applicable to this draft, but that has not yet been > disclosed to the IETF. I will work to ensure that it will be disclosed in a > timely manner. > > Thanks, > Andrew ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] IPR Poll on draft-dhody-pce-pceps-tls13
Hari, I too am unaware of any IPR associated with this I-D. spt > On Apr 6, 2023, at 08:14, Russ Housley wrote: > > Hart: > > I am unaware of any IPR associated with this draft. > > Russ > > >> On Apr 5, 2023, at 11:30 PM, Dhruv Dhody wrote: >> >> Hi Hari, >> >> I am not aware of any IPR applicable to this draft that should be disclosed >> in accordance with IETF IPR rules. >> >> Thanks! >> Dhruv >> >> >> On Thu, Apr 6, 2023 at 6:03 AM Hariharan Ananthakrishnan >> wrote: >> Hi Authors, >> In preparation for WG adoption on this draft, I'd like all >> authors and contributors to confirm on the list that they are in compliance >> with IETF IPR rules. >> >> Please respond (copying the mailing list) to say one of: >> I am not aware of any IPR applicable to this draft that should be disclosed >> in accordance with IETF IPR rules. >> >> I am aware of the IPR applicable to this draft, and it has already been >> disclosed to the IETF. >> >> I am aware of IPR applicable to this draft, but that has not yet been >> disclosed to the IETF. I will work to ensure that it will be disclosed in a >> timely manner. >> >> Thanks, >> - Hari >> > ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Call for slot in the PCE WG at IETF 116
Hi PCE! Here’s the info on my requested slot: - the draft(s) you want to discuss: https://datatracker.ietf.org/doc/draft-dhody-pce-pceps-tls13/ - the expected presenter name: Sean Turner - will you be attending in-person or remote: in-person - the requested duration, including question time as part of the slot: 10min (might need less) - the reason why you want to be on the agenda; What do you want to achieve? Why is a presentation necessary to achieve it? Provide a summary of changes Cheers, spt ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Call for slot in the PCE WG at IETF 116
Hi PCE! Here’s the info on my requested slot: - the draft(s) you want to discuss: https://datatracker.ietf.org/doc/draft-dhody-pce-pceps-tls13/ - the expected presenter name: Sean Turner - will you be attending in-person or remote: in-person - the requested duration, including question time as part of the slot: 10min (might need less) - the reason why you want to be on the agenda; What do you want to achieve? Why is a presentation necessary to achieve it? As this I-D is in the WG adoption queue (https://wiki.ietf.org/en/group/pce), wanted update the WG on changes. Cheers, spt ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] Thinking about draft-dhody-pce-pceps-tls13
I also submitted a CR to fix my spelling mistake :) spt > On Oct 14, 2022, at 19:23, Dhruv Dhody wrote: > > Thanks Russ & Adrian! > > I have updated the working copy with this commit -> > https://github.com/dhruvdhody/draft-dhody-pce-pceps-tls13/commit/05027a5251a0290bd8c960b2c03aa2b13ae01c79 > > > Dhruv > > On Fri, Oct 14, 2022 at 8:10 PM Adrian Farrel wrote: > Wfm, thnx > > -Original Message- > From: Russ Housley > Sent: 14 October 2022 14:58 > To: Adrian Farrel > Cc: draft-dhody-pce-pceps-tl...@ietf.org; pce@ietf.org > Subject: Re: Thinking about draft-dhody-pce-pceps-tls13 > > Maybe the phrase should be: PCEP implementations that support TLS 1.3 MUST > ... > > Russ > > > On Oct 14, 2022, at 9:28 AM, Adrian Farrel wrote: > > > > Thanks, Rus. > > > > What I didn't express well (don't write emails when you have been doing > hard > > concentration work for 9.5 hours straight!) is that it is possible to > think > > that this work is telling all PCEP implementations what they must do. I > have > > spoken to one person who was very worried that this was updating what > their > > existing implementation would need to do. > > > > I'm clear that the intention is to describe what PCEPS implementations > that > > support TLS 1.3 are supposed to do, and that doesn't have any knock-on for > > other work, but, yes, a very simple addition of "of this specification" > > makes all the concerns go away. > > > > Cheers, > > Adrian > > > > -Original Message- > > From: Russ Housley > > Sent: 14 October 2022 13:46 > > To: Adrian Farrel > > Cc: draft-dhody-pce-pceps-tl...@ietf.org; pce@ietf.org > > Subject: Re: Thinking about draft-dhody-pce-pceps-tls13 > > > > Adrian: > > > > TLS 1.2 does not have early data, and the algorithm registries arefor TLS > > 1.2 and TLS 1.3 are separate, o I do not think there is confusion. That > > said, I do not object to adding the phrase. > > > > Russ > > > >> On Oct 13, 2022, at 5:42 PM, Adrian Farrel wrote: > >> > >> Hi, > >> > >> Thanks for kicking off work to get PCEP able to work with TLS1.3. > >> > >> This is important. > >> > >> However... :-) > >> > >> I think it would be helpful to clarify that statements about what > >> implementations must or must not do (etc.) should be scoped as > >> "implementations of this document." That is, you are not constraining > PCEP > >> implementations in general, and I don't even thing you are constraining > >> TLS1.2 PCEP implementations. Well, if it was your intent to do otherwise, > >> you really need to be clear that you are updating the base specs, but I > > hope > >> you're not. > >> > >> Further, I am worried about the use of draft-ietf-tls-rfc8446bis as a > >> normative reference. I understand that the long term intention is that > > that > >> draft will obsolete RFC 8446, but it seems to be moving slowly (if at all > > - > >> it has expired). I think that implementers wanting to apply TLS1.3 to > > their > >> PCEP code will want to pick up TLS1.3 implementations that are stable > > (i.e., > >> based on RFCs). Now, by the time this draft gets to completion, it is > > quite > >> possible that 8446bis will have completed, and the draft can be updated > to > >> reference it and pick any additional points it makes. On the other hand, > > if > >> this draft makes it to the RFC Editor queue before 8446bis is complete, I > >> don't think you'd want it to sit around, and a subsequent bis can be made > >> when 8446bis becomes an RFC. > >> > >> What do you think? > >> > >> Cheers, > >> Adrian > >> > >> > > > > ___ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
