Subject: [Syslog] Fwd: I-D Action: draft-ciphersuites-in-sec-syslog-00.txt

From: "Fries, Steffen" <[email-masked]>
Date: Mon, 13 Dec 2021 15:43:13 +0000

Hi all,

Sorry for jumping in late into the discussion. First of all, thank you Chris for the prompt reaction updating the two related RFCs. Also thanks for the acknowledgements.
Just as a side note, we (IEC TC57 WG15) had a similar discussion with the RADEXT WG a while ago as we use the RADSEC RFC 6614 in WG 15 as well and were unsure if we can utilize a stronger cipher suite than stated in the RFC and still use the port specified in the RFC. RFC 6614 has not been updated, yet.

Chris, I understand the hesitation about key strength. I think there are other documents available like from NIST or the German BSI, which provide recommendations. So leaving it to the actual operational environment or a domain specific standard would also be fine from my point of view.

Tom, I think you are right about the reference to RFC 8446 regarding DTLS 1.0. Maybe it would sufficient to simply reference this RFC as reminder, that the deprecation of DTLS 1.0 has already been done. That it would be sufficient to only state the updated mandatory to implement cipher suite.

Regarding the draft I have some smaller comments:

  *   Section 4/5 mentions cipher suites, which must not be offered.
     *   Stating just one cipher suite seems incomplete and may also change over time.  Or was the reason that it was explicitly requested in the original RFC? Would it be better to provide a recommendation that the cipher suites listed under IANA: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4 with the recommendation SHOULD not be used? There is a similar kind of statement for the cipher suites used in TLS 1.3.
     *   A proposal for section 4 would be to replace

Implementations of [RFC5425] MUST NOT offer TLS_RSA_WITH_AES_128_CBC_SHA.  The mandatory to implement cipher suite is REQUIRED to be TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.

With:

While [RFC5425] required mandatory support for TLS_RSA_WITH_AES_128_CBC_SHA, this document deprecates this cipher suite. Moreover, implementers are pointed to the IETF recommendation for cipher suites under IANA: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4. The mandatory to implement cipher  suite is REQUIRED to be TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.

     *   Likewise a proposal for section 5 would be to replace

Implementations of [RFC6012] MUST NOT offer TLS_RSA_WITH_AES_128_CBC_SHA.  The mandatory to implement cipher suite is REQUIRED to be TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.

With:

While [RFC6012] required mandatory support for TLS_RSA_WITH_AES_128_CBC_SHA, this document deprecates this cipher suite. Moreover, implementers are pointed to the IETF recommendation for cipher suites under IANA: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4. The mandatory to implement cipher  suite is REQUIRED to be TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.

     *   The reason for deprecation instead of disallowing (MUST NOT) is to let it a security policy decision of an operator to allow migration towards stronger crypto or to support legacy servers with new clients without violating the updated RFC. This would also align with the text in the security consideration section.
  *   Section 4/5 now includes (D)TLS 1.3 optionally, which is good. Regarding 0-RTT, I would share your opinion. In WG15 we also do not allow 0-RTT to always use fresh keys.

Please let me know, what you think about it.

Best regards
Steffen

On Sat, Dec 11, 2021 at 12:44:53PM +0000, tom petch wrote:

> ________________________________________

> From: Syslog <[email-masked]><mailto:&lt;[email-masked]&gt;> on behalf of Chris Lonvick <[email-masked]><mailto:&lt;[email-masked]&gt;>

> Sent: 10 December 2021 23:27

> To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Joe Salowey; Arijit Bose

> Subject: [Syslog] Fwd: I-D Action: draft-ciphersuites-in-sec-syslog-00.txt

> Hi Folks,

> As Tom and Jurgen noted, Arijit Kumar Bose did send some notes to the Syslog mailing list. By the time I had snapped to, the system had timed most of them out. I finally got that last one approved and forwarded to the mailing list.

> Arijit (and the IEC WG15) rightly notes that the RFCs are using deprecated cipher suits and the DTLS RFC is using a deprecated version.

> <tp>

> Chris et al

> This is flawed.  The use of DTLS1.0 was noted by a security AD a long time ago and is now deprecated  and the syslog RFC have been updated accordingly so anyone saying that syslog uses a deprecated version is wrong; they need to understand the IETF process.

> I tracked the work on the TLS list and even posted to that list the fact that the syslog RFC were missing.  I was ignored so I tried again at IETF Last Call and this time got them included (Ignoring me does not make me give up:-)

> So your I-D needs to reflect the existing update.  Reinventing the wheel will likely cause confusion amongst subsequent ADs.

> Tom Petch

> Sean, Joe, and I worked out a -00 draft to address these issues. Like all -00 IDs, it's open to comments. :-) We know that there are some larger efforts underway to address TLS, DTLS and cipher suites. We're not going to try to do that here. Rather, we'd like to update RFCs 5425 and 6012 to get them compliant with current standards with a minimal impact to current implementations.

> Sean is going to run this by the secdispatch group to see if they can make a recommendation on where this may be best addressed and discussed. I'm sure that we'll get some good input from the group here on the Syslog mail list, so please send in your comments and let's get these two RFCs updated to using current best practices.

> Best regards and have a great weekend,

> Chris

> -------- Forwarded Message --------

> Subject:        I-D Action: draft-ciphersuites-in-sec-syslog-00.txt

> Date:   Fri, 10 Dec 2021 14:57:44 -0800

> From:   [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>

> Reply-To:       [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>

> To:     [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>

> A New Internet-Draft is available from the on-line Internet-Drafts directories.

> Title : Updates to the Cipher Suites in Secure Syslog

> Authors : Chris Lonvick

> Sean Turner

> Joe Salowey

> Filename : draft-ciphersuites-in-sec-syslog-00.txt

> Pages : 8

> Date : 2021-12-10

> Abstract:

> This document updates the cipher suites in RFC 5425, Transport Layer

> Security (TLS) Transport Mapping for Syslog, and RFC 6012, Datagram

> Transport Layer Security (DTLS) Transport Mapping for Syslog. It

> also updates the transport protocol in RFC 6012.

> The IETF datatracker status page for this draft is:

> https://datatracker.ietf.org/doc/draft-ciphersuites-in-sec-syslog/

> There is also an HTML version available at:

> https://www.ietf.org/archive/id/draft-ciphersuites-in-sec-syslog-00.html

> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

> _______________________________________________

> I-D-Announce mailing list

> [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>

> https://www.ietf.org/mailman/listinfo/i-d-announce

> Internet-Draft directories: http://www.ietf.org/shadow.html<https://www.ietf.org/shadow.html>

> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt<http://ftp:/ftp.ietf.org/ietf/1shadow-sites.txt>

> _______________________________________________

> Syslog mailing list

> [email-masked]<mailto:[email-masked]>

> https://www.ietf.org/mailman/listinfo/syslog

--

Juergen Schoenwaelder           Jacobs University Bremen gGmbH

Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany

Fax:   +49 421 200 3103         https://www.jacobs-university.de/

---

From: tom petch <[email-masked]>
Date: Mon, 13 Dec 2021 16:58:52 +0000

From: Syslog <[email-masked]> on behalf of Fries, Steffen <[email-masked]>
Sent: 13 December 2021 15:43

Hi all,

<tp>
On this one narrow point, what a registry entry can be used for depends on what it is registered to be used for.  The registration could say that a port is only valid for authentication with X.509 certificates, or with PSK or ...  AFAIK there are no such registrations and so a port can be used with any ciphersuite  be it for Radsec or secure syslog or ..  A more carefully written RFC might anticipate changes in security and give guidelines as to what is and is not acceptable - eg with new ciphersuites - but most do not and that approach could be fraught when there are other factors to be considered  - DH Group or a random seed or.  So  port is tied to the use of TLS and syslog but not to a ciphersuite IMHO. I cannot recall seeing this discussed before.

I think that this new I-D should mention the deprecation of DTLS1.0 but if users have missed the fact that RFC8996 updates e.g. RFC6614 then they will likely miss the fact that this I-D is performing an update:-(  It is all there in the Datatracker, on the RFC Editor site, in the RFC-Index ...

Tom Petch

With:

With:

Best regards
Steffen

On Sat, Dec 11, 2021 at 12:44:53PM +0000, tom petch wrote:

--