From nobody Mon Nov 29 08:10:01 2021 Return-Path: X-Original-To: syslog@ietfa.amsl.com Delivered-To: syslog@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 044D13A0B9B for ; Mon, 29 Nov 2021 08:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwTwaxs7483n for ; Mon, 29 Nov 2021 08:09:53 -0800 (PST) Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 157323A0B9C for ; Mon, 29 Nov 2021 08:09:52 -0800 (PST) Received: by mail-qv1-xf32.google.com with SMTP id gu12so14990798qvb.6 for ; Mon, 29 Nov 2021 08:09:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5C5i8lIdTPPFhLRb0sJDFN0DMCuiwUWQ34a9CVnbJVE=; b=OOTxUf77d/SDXWTtlJJp7fvTo7rLd8+vhAnxb3Szvl68P+3jbLP1loZeY17xNLwS1n yspQkA7SspWv7iFQPCFo91QJaoTcu2bQvG3CgZZKsj8vpyvGfuAKxFMhXMehl+nf17/W zJaSjY7PAhL6X2K5jSStFReYCPVcnEyGGoyLE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5C5i8lIdTPPFhLRb0sJDFN0DMCuiwUWQ34a9CVnbJVE=; b=bqnqS5zJFPyk38ZQE3fx9Tu6qPlh2p8/rw9dFWQFUk8kPgUGZqA6pGuP+0YtGAi70h Dt5ijt2IBjapevTvhg7lMziWfv1ekfyvkaRzzRdwNPaE8D/8RkDucFH4tQJOJwCwsN5T LA5l83WtAM1VHDfhoo36tRwdIyK817ORxiYKs7VwkBBqOIvx8suWfSWTqiMcKrEuU+u9 spJ9nHLOfgudOd0igPyCTS7mNA4EG25R383BW+Tdu/CmDiJlt6y+N/cuZIfqU7WJObIg +2/sUIXiTrVXJyXYPeB7QcjR/T7tAbT8PJq+WECEiNlFgkE1Hp4tVFTvb+csEx6sI5du E8+Q== X-Gm-Message-State: AOAM5319t2aJb4JoY0oHpu7dslkDrvLxpTeHz/TsAz4W8sknZ5yPPpXW J9vCxpLyBpHrW5wt/4m15eT2sg== X-Google-Smtp-Source: ABdhPJzrM0klVLGBkYxOLt6BUQeMwvcxcyw9tuCfNt7K+ZC5TIAgnsO7WCamISXqO8mJK6SumuytQA== X-Received: by 2002:a05:6214:27ca:: with SMTP id ge10mr42589952qvb.46.1638202191501; Mon, 29 Nov 2021 08:09:51 -0800 (PST) Received: from smtpclient.apple (pool-71-178-177-131.washdc.fios.verizon.net. [71.178.177.131]) by smtp.gmail.com with ESMTPSA id 196sm8147224qkd.61.2021.11.29.08.09.50 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Nov 2021 08:09:51 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Sean Turner In-Reply-To: Date: Mon, 29 Nov 2021 11:09:49 -0500 Cc: Chris Lonvick , "sean+ietf@sn3rd.com" , "syslog@ietf.org" , "ietf-action@ietf.org" , Joe Salowey , "IEC 62351 WG15 (WG15@iectc57.org)" , Benjamin Kaduk , Roman Danyliw Content-Transfer-Encoding: quoted-printable Message-Id: <63DDB634-6F27-4CBB-8195-32EEBC3953CB@sn3rd.com> References: <64c34d64-5982-0df8-f057-1b3f53166e77@gmail.com> To: Arijit Bose X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [Syslog] Use Of RFC 5425 In IEC 62351 X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2021 16:09:59 -0000 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 = wrote: >=20 > Dear Chris, > =20 > =20 > Thanks for providing us(WG15) with your feedback! > We(WG15) will further discuss among us on this topic and accordingly = come back to IETF. > =20 > What are the prerequisites and procedure to create a new IETF draft = =E2=80=93 in this case updating an existing RFC ? >=20 >=20 > With best regards > Arijit > =20 > =20 > =20 > From: Chris Lonvick =20 > Sent: Sunday, November 28, 2021 10:22 PM > To: Arijit Bose ; sean+ietf@sn3rd.com; = sean@sn3rd.com; syslog@ietf.org; ietf-action@ietf.org; joe@salowey.net > Cc: IEC 62351 WG15 (WG15@iectc57.org) ; = kaduk@mit.edu; rdd@cert.org > Subject: Re: Use Of RFC 5425 In IEC 62351 > =20 > 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. > =20 > Hello Arijit and All, >=20 > 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: >=20 > - create a new Internet Draft that will deprecate the insecure cypher = suite from the RFC; and >=20 > - 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. >=20 > I'm cc'ing the current IETF Security ADs and adding Joe's contact = email. >=20 > Best regards, >=20 > Chris >=20 > On 11/22/21 10:30 AM, Arijit Bose wrote: > Dear all, >=20 >=20 > =20 > I am also looping the email address ietf-action@ietf.org for this same = query. >=20 >=20 >=20 > With best regards > Arijit > =20 > =20 > From: Arijit Bose=20 > Sent: Monday, November 22, 2021 2:40 PM > To: jsalowey@cisco.com; clonvick@cisco.com; = lonvick.ietf@gmail.com;ietfdbh@comcast.net; turners@ieca.com; = sean+ietf@sn3rd.com; sean@sn3rd.com; syslog@ietf.org > Cc: IEC 62351 WG15 (WG15@iectc57.org) > Subject: RE: Use Of RFC 5425 In IEC 62351 > Importance: High > =20 > Dear all, >=20 > =20 > My name is Arijit Kumar Bose and I am a member of IEC 62351 TC 57 WG15 = : IEC 62351 - Wikipedia. > =20 > 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. >=20 > 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 ? >=20 > I and WG15 are looking forward to your answer on this topic. = Appreciate your any input on the same. >=20 > Thanks in advance! >=20 > With best regards > Arijit >=20 > =20 > =20 > > Arijit Kumar Bose=20 > Global Cyber Security Architect - Power Grids High Voltage | Software = Development Independent Expert=20 >=20 > ul. Pawia 7 > malopolskie > 31-154 Krakow, Poland=20 > Mobile: +48 666 881 680 > E-mail: arijit.bose@hitachienergy.com > www.hitachienergy.com > = > =20 > > =20 > From: Arijit Bose=20 > Sent: Monday, November 22, 2021 11:49 AM > To: jsalowey@cisco.com > Cc: IEC 62351 WG15 (WG15@iectc57.org) > Subject: RE: Use Of RFC 5425 In IEC 62351 > =20 > Dear Joseph, > =20 >=20 > A second friendly reminder for this below aspect. We(WG15) are looking = forward to your reply on this. > =20 >=20 > With best regards > Arijit > =20 > =20 > From: Arijit Bose=20 > Sent: Wednesday, November 17, 2021 12:49 PM > To: 'jsalowey@cisco.com' > Cc: IEC 62351 WG15 (WG15@iectc57.org) > Subject: RE: Use Of RFC 5425 In IEC 62351 > =20 > Dear Joseph, > =20 > A friendly reminder for your input/suggestion on this topic as = expressed below. > =20 > With best regards > Arijit > =20 > =20 > From: Arijit Bose=20 > Sent: Friday, November 12, 2021 11:17 AM > To: jsalowey@cisco.com > Cc: IEC 62351 WG15 (WG15@iectc57.org) > Subject: RE: Use Of RFC 5425 In IEC 62351 > =20 > Dear Joseph, > =20 > Since I got a computerized automatic generated reply stating an = undelivered message tomiaofy@huawei.com and myz@huawei.com 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. > =20 > We are looking forward to your reply on this! > =20 > With best regards > Arijit > =20 > =20 > From: Arijit Bose=20 > Sent: Wednesday, November 10, 2021 10:48 AM > To: miaofy@huawei.com; myz@huawei.com; jsalowey@cisco.com > Subject: Use Of RFC 5425 In IEC 62351 > =20 > Dear all, > =20 > My name is Arijit Kumar Bose and I am a member of IEC 62351 TC 57 WG15 = : IEC 62351 - Wikipedia. > =20 > 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. >=20 > 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 ? >=20 > I and WG15 are looking forward to your answer on this topic. = Appreciate your any input on the same. >=20 > Thanks in advance! >=20 > With best regards > Arijit >=20 > > Arijit Kumar Bose > Global Cyber Security Architect - Power Grids High Voltage | Software = Development Independent Expert=20 >=20 > ul. Pawia 7 > malopolskie > 31-154 Krakow, Poland=20 > Mobile: +48 666 881 680 > E-mail: arijit.bose@hitachienergy.com > www.hitachienergy.com > = > =20 > > =20 >=20 >=20 > Hitachi Energy Services Sp. z o. o. z siedzib=C4=85 w Warszawie, = adres: Warszawa 04-713, ul. =C5=BBega=C5=84ska 1, wpisana do Rejestru = Przedsi=C4=99biorc=C3=B3w Krajowego Rejestru S=C4=85dowego prowadzonego = w S=C4=85dzie Rejonowym dla m. st. Warszawy, XIV Wydzia=C5=82 = Gospodarczy Krajowego Rejestru S=C4=85dowego pod nr KRS 0000787719, nr = REGON: 383431370, nr NIP: 9522196923, nr BDO: 000147611, kapita=C5=82 = zak=C5=82adowy 14 403 850,00 z=C5=82. > Hitachi Energy Services Sp. z o. o. with registered seat at 1 = =C5=BBeganska 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.=20 >=20 >=20 > Hitachi Energy Services Sp. z o. o. z siedzib=C4=85 w Warszawie, = adres: Warszawa 04-713, ul. =C5=BBega=C5=84ska 1, wpisana do Rejestru = Przedsi=C4=99biorc=C3=B3w Krajowego Rejestru S=C4=85dowego prowadzonego = w S=C4=85dzie Rejonowym dla m. st. Warszawy, XIV Wydzia=C5=82 = Gospodarczy Krajowego Rejestru S=C4=85dowego pod nr KRS 0000787719, nr = REGON: 383431370, nr NIP: 9522196923, nr BDO: 000147611, kapita=C5=82 = zak=C5=82adowy 14 403 850,00 z=C5=82. > Hitachi Energy Services Sp. z o. o. with registered seat at 1 = =C5=BBeganska 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.