From: Syslog <[email protected]> on behalf of Fries, Steffen
<[email protected]>
Sent: 13 December 2021 15:43
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.
<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
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 protected]><mailto:<[email protected]>> on behalf
> of Chris Lonvick
> <[email protected]><mailto:<[email protected]>>
> Sent: 10 December 2021 23:27
> To: [email protected]<mailto:[email protected]>;
> [email protected]<mailto:[email protected]>; 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 protected]<mailto:[email protected]<mailto:[email protected]%3cmailto:[email protected]>>
> Reply-To:
> [email protected]<mailto:[email protected]<mailto:[email protected]%3cmailto:[email protected]>>
> To:
> [email protected]<mailto:[email protected]<mailto:[email protected]%3cmailto:[email protected]>>
>
>
>
> 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 protected]<mailto:[email protected]<mailto:[email protected]%3cmailto:[email protected]>>
> 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 protected]<mailto:[email protected]>
> 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/
_______________________________________________
Syslog mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/syslog
