Hi Deb, On Thu, Nov 21, 2024 at 5:13 AM Deb Cooley via Datatracker <[email protected]> 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 :) 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. And what you state is also true! > 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."? Thanks! Dhruv (as document shepherd)
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
