* This is currently the only comment we have seen outside of support for
the draft being WGLC complete.
Viktor is the only person who has brought this up. Now I know there hasn’t been
a lot of discussion, but I’m not sure consensus is with his position.
_
Sorry if I was not clear, I was hoping to see the comment responded to,
even if the consensus is to not make changes.
Once we can see the group position on it, I think we will have addressed
comments raised during WGLC.
OS
On Wed, Sep 6, 2023 at 9:02 AM Salz, Rich wrote:
>
>- This is curre
Hi Viktor and all,
I see your point.
How about if the phrases "MUST NOT offer TLS_RSA_WITH_AES_128_CBC_SHA" in
Sections 4 and 5 be changed to "SHOULD NOT offer..."?
This seems to be more consistent with Section 4.2.1 of RFC 9325 (BCP 195)
and will continue to allow devices to offer that algorith
Chair hat off, this suggestion makes sense to me, I would support making
the change, unless a strong counter argument is presented.
OS
On Wed, Sep 6, 2023 at 11:54 AM Chris Lonvick
wrote:
> Hi Viktor and all,
>
> I see your point.
>
> How about if the phrases "MUST NOT offer TLS_RSA_WITH_AES_12
On Wed, Sep 06, 2023 at 12:53:39PM -0400, Chris Lonvick wrote:
> Hi Viktor and all,
>
> I see your point.
>
> How about if the phrases "MUST NOT offer TLS_RSA_WITH_AES_128_CBC_SHA" in
> Sections 4 and 5 be changed to "SHOULD NOT offer..."?
>
> This seems to be more consistent with Section 4.2.1
Hi Ilari,
If a syslog server MUST NOT offer the only cipher suite that an associated
client has available then the client will not be able to securely convey
syslog messages to that server. That would break things. Changing that to
"SHOULD NOT" allows an administrator to evaluate the risks. The
ad
