Re: [Syslog] Use Of RFC 5425 In IEC 62351

[Sean Turner <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 
> Sent: Sunday, November 28, 2021 10:22 PM
> To: Arijit Bose <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Cc: IEC 62351 WG15 ([e-mail]) <[e-mail]>; [e-mail]; [e-mail]
> 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 [e-mail] for this same query.
> 
> 
> 
> With best regards
> Arijit
>  
>  
> From: Arijit Bose 
> Sent: Monday, November 22, 2021 2:40 PM
> To: [e-mail]; [e-mail]; [e-mail];[e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Cc: IEC 62351 WG15 ([e-mail]) <[e-mail]>
> 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: [phone]
> E-mail: [e-mail]
> 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: [e-mail]
> Cc: IEC 62351 WG15 ([e-mail]) <[e-mail]>
> 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: '[e-mail]' <[e-mail]>
> Cc: IEC 62351 WG15 ([e-mail]) <[e-mail]>
> 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: [e-mail]
> Cc: IEC 62351 WG15 ([e-mail]) <[e-mail]>
> Subject: RE: Use Of RFC 5425 In IEC 62351
>  
> Dear Joseph,
>  
> Since I got a computerized automatic generated reply stating an undelivered message [e-mail] and [e-mail] 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: [e-mail]; [e-mail]; [e-mail]
> 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: [phone]
> E-mail: [e-mail]
> 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.