Arijit, Hi! Some of what Chris is suggesting is already in the works one a broader scale. For example, TLS_RSA_WITH_AES_128_CBC_SHA is intended to be decorated by [1], which is out for WG adoption by the TLS WG. As you point out TLS_RSA_WITH_AES_128_CBC_SHA, is weak and has been known to be weak for sometime. Because of that, [2] was published. As security is a moving target [2], is now in the process of being updated by [3].
You will note though that neither [2] nor [3] changes the TLS 1.2 MTI, but they do recommend using AEAD algorithms (see Section 4.2). I would not expect any RFC to update the TLS 1.2 MTI. Instead standards/implementations should look to refer to TLS 1.3 [4] because it removed the insecure suites. I would think that you ought to be able to put some text in that says something like: TLS_RSA_WITH_AES_128_CBC_SHA is now considered insecure (see [3]), instead support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for TLS 1.2 as specified in [3]. For TLS 1.3, use the algorithms specified therein. Cheers, spt [1] https://datatracker.ietf.org/doc/draft-aviram-tls-deprecate-obsolete-kex/ [2] https://datatracker.ietf.org/doc/rfc7525/ [3] https://datatracker.ietf.org/doc/draft-ietf-uta-rfc7525bis/ [4] https://datatracker.ietf.org/doc/rfc8446/ > On Nov 29, 2021, at 03:00, Arijit Bose <[email protected]> wrote: > > Dear Chris, > > > Thanks for providing us(WG15) with your feedback! > We(WG15) will further discuss among us on this topic and accordingly come > back to IETF. > > What are the prerequisites and procedure to create a new IETF draft – in this > case updating an existing RFC ? > > > With best regards > Arijit > > > > From: Chris Lonvick <[email protected]> > Sent: Sunday, November 28, 2021 10:22 PM > To: Arijit Bose <[email protected]>; [email protected]; > [email protected]; [email protected]; [email protected]; [email protected] > Cc: IEC 62351 WG15 ([email protected]) <[email protected]>; [email protected]; > [email protected] > Subject: Re: Use Of RFC 5425 In IEC 62351 > > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > Hello Arijit and All, > > Speaking as an individual (not representing the IETF or any Working Group), > the work we did for the syslog protocol was never intended to be insecure. I > would make two suggestions: > > - create a new Internet Draft that will deprecate the insecure cypher suite > from the RFC; and > > - specify the implementation and deployment of the cypher suites in your IEC > documents as you suggest below and cite the Internet Draft as updating the > RFC. > > I'm cc'ing the current IETF Security ADs and adding Joe's contact email. > > Best regards, > > Chris > > On 11/22/21 10:30 AM, Arijit Bose wrote: > Dear all, > > > > I am also looping the email address [email protected] for this same query. > > > > With best regards > Arijit > > > From: Arijit Bose > Sent: Monday, November 22, 2021 2:40 PM > To: [email protected]; [email protected]; > [email protected];[email protected]; [email protected]; > [email protected]; [email protected]; [email protected] > Cc: IEC 62351 WG15 ([email protected]) <[email protected]> > Subject: RE: Use Of RFC 5425 In IEC 62351 > Importance: High > > Dear all, > > > My name is Arijit Kumar Bose and I am a member of IEC 62351 TC 57 WG15 : IEC > 62351 - Wikipedia. > > For the development of an IEC cybersecurity standard for electrical power > system, we (WG15) are trying to reference RFC 5425 and adopt its > specifications. However, since RFC 5425 specifies > TLS_RSA_WITH_AES_128_CBC_SHA, which is currently insecure and depreciated > cipher suite Ciphersuite Info. Therefore, we are trying to adopt stronger > cipher suites in accordance with IEC 62351-3 : IEC > 62351-3:2014+AMD1:2018+AMD2:2020 CSV | IEC Webstore. IEC 62351-3 specifies a > set of stronger state of the art cipher suites and thus defines a profile on > how to apply TLS, addressing authentication, cipher suite requirements, > renegotiation, etc. Therefore, we would like to use the state of the art > cipher suites as specified in IEC 62351-3 and also mandatorily refer RFC 5425 > including the usage of its port number 6514 for transporting secure syslog > traffic. Our understanding would be that it does not violate RFC 5425, as it > allows in section 4.2 of RFC 5425 that also stronger cipher suites may be > used. > > Would these be allowed that if we normatively (mandatorily) refer RFC 5425 to > secure SYSLOG traffic including the use of the TCP port number 6514 but adopt > the stronger cipher suites that are specified in IEC 62351-3 instead of the > weak cipher suite as indicated above ? By adopting this, will it make our > IEC standard incompliant with RFC 5425 ? > > I and WG15 are looking forward to your answer on this topic. Appreciate your > any input on the same. > > Thanks in advance! > > With best regards > Arijit > > > > <image011.png> > Arijit Kumar Bose > Global Cyber Security Architect - Power Grids High Voltage | Software > Development Independent Expert > > ul. Pawia 7 > malopolskie > 31-154 Krakow, Poland > Mobile: +48 666 881 680 > E-mail: [email protected] > www.hitachienergy.com > <image012.png> <image013.png> <image014.png> <image015.png> <image016.png> > > <image017.png> > > From: Arijit Bose > Sent: Monday, November 22, 2021 11:49 AM > To: [email protected] > Cc: IEC 62351 WG15 ([email protected]) <[email protected]> > Subject: RE: Use Of RFC 5425 In IEC 62351 > > Dear Joseph, > > > A second friendly reminder for this below aspect. We(WG15) are looking > forward to your reply on this. > > > With best regards > Arijit > > > From: Arijit Bose > Sent: Wednesday, November 17, 2021 12:49 PM > To: '[email protected]' <[email protected]> > Cc: IEC 62351 WG15 ([email protected]) <[email protected]> > Subject: RE: Use Of RFC 5425 In IEC 62351 > > Dear Joseph, > > A friendly reminder for your input/suggestion on this topic as expressed > below. > > With best regards > Arijit > > > From: Arijit Bose > Sent: Friday, November 12, 2021 11:17 AM > To: [email protected] > Cc: IEC 62351 WG15 ([email protected]) <[email protected]> > Subject: RE: Use Of RFC 5425 In IEC 62351 > > Dear Joseph, > > Since I got a computerized automatic generated reply stating an undelivered > message [email protected] and [email protected] indicating that most probably > their email address is no longer valid and thus could not be found, it would > be very helpful, if you can please help us (WG15) with your valuable input / > suggestion on this below topic. > > We are looking forward to your reply on this! > > With best regards > Arijit > > > From: Arijit Bose > Sent: Wednesday, November 10, 2021 10:48 AM > To: [email protected]; [email protected]; [email protected] > Subject: Use Of RFC 5425 In IEC 62351 > > Dear all, > > My name is Arijit Kumar Bose and I am a member of IEC 62351 TC 57 WG15 : IEC > 62351 - Wikipedia. > > For the development of an IEC cybersecurity standard for electrical power > system, we (WG15) are trying to reference RFC 5425 and adopt its > specifications. However, since RFC 5425 specifies > TLS_RSA_WITH_AES_128_CBC_SHA, which is currently insecure and depreciated > cipher suite Ciphersuite Info. Therefore, we are trying to adopt stronger > cipher suites in accordance with IEC 62351-3 : IEC > 62351-3:2014+AMD1:2018+AMD2:2020 CSV | IEC Webstore. IEC 62351-3 specifies a > set of stronger state of the art cipher suites and thus defines a profile on > how to apply TLS, addressing authentication, cipher suite requirements, > renegotiation, etc. Therefore, we would like to use the state of the art > cipher suites as specified in IEC 62351-3 and also mandatorily refer RFC 5425 > including the usage of its port number 6514 for transporting secure syslog > traffic. Our understanding would be that it does not violate RFC 5425, as it > allows in section 4.2 of RFC 5425 that also stronger cipher suites may be > used. > > Would these be allowed that if we normatively (mandatorily) refer RFC 5425 to > secure SYSLOG traffic including the use of the TCP port number 6514 but adopt > the stronger cipher suites that are specified in IEC 62351-3 instead of the > weak cipher suite as indicated above ? By adopting this, will it make our > IEC standard incompliant with RFC 5425 ? > > I and WG15 are looking forward to your answer on this topic. Appreciate your > any input on the same. > > Thanks in advance! > > With best regards > Arijit > > <image018.png> > Arijit Kumar Bose > Global Cyber Security Architect - Power Grids High Voltage | Software > Development Independent Expert > > ul. Pawia 7 > malopolskie > 31-154 Krakow, Poland > Mobile: +48 666 881 680 > E-mail: [email protected] > www.hitachienergy.com > <image019.png> <image013.png> <image014.png> <image015.png> <image016.png> > > <image020.png> > > > > Hitachi Energy Services Sp. z o. o. z siedzibą w Warszawie, adres: Warszawa > 04-713, ul. Żegańska 1, wpisana do Rejestru Przedsiębiorców Krajowego > Rejestru Sądowego prowadzonego w Sądzie Rejonowym dla m. st. Warszawy, XIV > Wydział Gospodarczy Krajowego Rejestru Sądowego pod nr KRS 0000787719, nr > REGON: 383431370, nr NIP: 9522196923, nr BDO: 000147611, kapitał zakładowy 14 > 403 850,00 zł. > Hitachi Energy Services Sp. z o. o. with registered seat at 1 Żeganska > Street, 04-713 Warsaw, Poland, registered in the Register of Entrepreneurs of > the Polish Court Register maintained by the District Court for the Capital > City of Warsaw, XIV Economic Department, under KRS No. 0000787719, REGON No. > (statistical number): 383431370, NIP No. (taxpayer identification number) > PL9522196923, BDO No. (WEEE registration number) 000147611, share capital: 14 > 403 850,00 PLN. > > > Hitachi Energy Services Sp. z o. o. z siedzibą w Warszawie, adres: Warszawa > 04-713, ul. Żegańska 1, wpisana do Rejestru Przedsiębiorców Krajowego > Rejestru Sądowego prowadzonego w Sądzie Rejonowym dla m. st. Warszawy, XIV > Wydział Gospodarczy Krajowego Rejestru Sądowego pod nr KRS 0000787719, nr > REGON: 383431370, nr NIP: 9522196923, nr BDO: 000147611, kapitał zakładowy 14 > 403 850,00 zł. > Hitachi Energy Services Sp. z o. o. with registered seat at 1 Żeganska > Street, 04-713 Warsaw, Poland, registered in the Register of Entrepreneurs of > the Polish Court Register maintained by the District Court for the Capital > City of Warsaw, XIV Economic Department, under KRS No. 0000787719, REGON No. > (statistical number): 383431370, NIP No. (taxpayer identification number) > PL9522196923, BDO No. (WEEE registration number) 000147611, share capital: 14 > 403 850,00 PLN. _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
