with [dc] in front... On Thu, Nov 21, 2024 at 1:28 AM Dhruv Dhody <d...@dhruvdhody.com> wrote:
> Hi Deb, > > On Thu, Nov 21, 2024 at 5:13 AM Deb Cooley via Datatracker < > nore...@ietf.org> wrote: > >> Deb Cooley has entered the following ballot position for >> draft-ietf-pce-stateful-pce-vendor-12: 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-stateful-pce-vendor/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Section 7, para 2: The last () is a bit puzzling. Is there something >> specific >> that is anticipated? It might need some explanation. RFC8253 is old >> enough >> that TLS1.3 wasn't published yet, but RFC 9325 obviously covers both TLS >> 1.2 >> and 1.3. >> >> > Dhruv: As clarified to John [ > https://mailarchive.ietf.org/arch/msg/pce/1iIo5KlwH6pEIEsgEwa84Jztr7Q/], > we have been sticking to this text that had an agreement with past Sec ADs > :) > > [dc] obviously that 'agreement' wasn't in place for RFC 8553... I'd like a pointer to that agreement. > There are some details in Section 3.4 of RFC 8253 that might not be > matching exactly to RFC 9325 - such as MUST for > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 in RFC 8253 where as RECOMMENDED in > RFC 9325. > [dc] so you are tell me that changing a 'MUST' for a 'RECOMMENDED' warrants an exception clause? Seems odd. > > And what you state is also true! > [dc] indeed. The reason we update security RFCs are to ensure that security is maintained, not frozen in some past state. > > >> Section 7, para 3, sentence 1: "The use of vendor-specific information as >> defined in [RFC7470] and in this document may provide a covert channel >> that >> could be misused by PCEP speaker implementations or by malign software at >> PCEP >> speakers." Perhaps it should be malicious vs malign? >> >> > Dhruv: Agree, “malicious” is more appropriate as it describes intentional > and harmful actions instead of something inherently evil! > > >> Section 7, para 3, Sentences 2 and 3: Depending on the signaling design >> of the >> covert channel, detection by an overworked operator while in use is >> difficult. >> Prevention of malicious software at the PCEP speaker might be easier (not >> easy, >> just easier). Software that is required to be protected by integrity, >> authentication and authorization techniques will make the installation of >> malicious software harder. While I'm sure this is out of scope for this >> draft, >> it is a valid mitigation. >> >> >> > Dhruv: Are you thinking of text like this - "Appropriate steps need to be > taken to prevent the installation of malicious software at the PCEP speaker > by implementing robust integrity, authentication, and authorization > techniques, which are out of scope of this draft."? > [dc] or "Appropriate steps need to be taken to prevent the installation of malicious software at the PCEP speaker by implementing robust integrity, authentication, and authorization techniques *for installation and updating*, which are out of scope of this draft." > Thanks! > Dhruv (as document shepherd) >
_______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
