Re: [Uta] Reviews requested - draft-ietf-uta-ciphersuites-in-sec-syslog

Chris Lonvick <lonvick.ietf@gmail.com> Mon, 18 September 2023 01:08 UTC

Return-Path: <lonvick.ietf@gmail.com>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D0CC14CE22 for <uta@ietfa.amsl.com>; Sun, 17 Sep 2023 18:08:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oy9E9E14HMQU for <uta@ietfa.amsl.com>; Sun, 17 Sep 2023 18:08:14 -0700 (PDT)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CEECC14F738 for <uta@ietf.org>; Sun, 17 Sep 2023 18:08:13 -0700 (PDT)
Received: by mail-lf1-x135.google.com with SMTP id 2adb3069b0e04-50300cb4776so2473190e87.3 for <uta@ietf.org>; Sun, 17 Sep 2023 18:08:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1694999292; x=1695604092; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=41hQcfDAMbzIH+Di82aG3QZor26lNcNaoi63usaLQ5Y=; b=PCfTaZpjuejsUin379Yh5/188I7RV4sS2wpJl0R5BZ4oooZkrdOXJOSiCgR/aY1sw7 GS7gn1zTSox7YgCRS6mJF00+rKYlj7NpNyELhTZNtUQWdKsE9boQvAf30ZQ+u0ysRtQ3 96PDNAesDWIktEvWpW3NyQ+f1m+/Y5JSwtcNfG9x8azpy4aH5gTvCPhv51xTP+yOFUbe erE0equs9KpyOBH4oPiKI+mupmgBXDNiNgsXmmRJeAGvEVTdRfkoJ+iPZyPXDNVww3fg CV5+cLJNwYpRRn0QbmfXrEa1aPv4AvvrKBfGG+8uDvpRpfD0tqBx35AirVRB7zTdRKBX U48A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694999292; x=1695604092; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=41hQcfDAMbzIH+Di82aG3QZor26lNcNaoi63usaLQ5Y=; b=QErJmbrR194E7E7jCz3djV85Vjt4cFz4G2/5Qb+huPxxa1VReqEcz0jhvYajTg4ZuN 6053GYJ/CMIy2PiXVF9MstnfwEokxfmnCN807e/3qnKR5aAoY+mynaHcuUF5Qy4PsHO9 Vge8180AHm+/gxlnN8kzwith6blQGQwFuWIgtp6L3zWZJOIcLsdH3eU1mXcsJNR4XIcs bkUb3Z3w18YK6UKqgJszKCzEoj24gVHE0ecW5lUUOUfEIJujxKEyOCQCF4ps0GxUc8oV Q4+EHqkxj4g71l4jL5p99naQ8IqGq9y9ttGOM7EGRauyQT6j6CwIThynk6W61imXpa6n moAg==
X-Gm-Message-State: AOJu0YzTTTj7GWQG7YP+9o1skycO9lN/FXGa+leSOEsyA2DKiowctb0R V+I7JokNGadolfFJlAu8qywZ8CN8ZbUeIHUBJZk=
X-Google-Smtp-Source: AGHT+IFaHdqLkBzs+fsdx4hlLCuaUsh1owPD9g9fr4xzmhSq2jUfPDGprn32JXK6a7DnCjE1srNuEfKkI23Nm+gOfco=
X-Received: by 2002:a05:6512:220e:b0:502:ffff:feff with SMTP id h14-20020a056512220e00b00502fffffeffmr5452482lfu.58.1694999291921; Sun, 17 Sep 2023 18:08:11 -0700 (PDT)
MIME-Version: 1.0
References: <CADPQ2UH81rQSbLhfZMCm9o_KZysWXpBhESS7Bv53XRL=ifUSaA@mail.gmail.com> <ZPC0qrEEdwsFeQBt@straasha.imrryr.org> <CADPQ2UEjj-xCkeVwF0P1uwgGxzc++8knmTQpc3fDBzdhxxBE-Q@mail.gmail.com> <ZPix0xqGefhkej33@LK-Perkele-VII2.locald> <CADPQ2UF4=1eh9cWLCMMMrNwSMoyXQHrawFaYDz4dnzjuRDqY3g@mail.gmail.com> <3be7a750-942d-4a02-9569-6ed79043a8c2@redhat.com>
In-Reply-To: <3be7a750-942d-4a02-9569-6ed79043a8c2@redhat.com>
From: Chris Lonvick <lonvick.ietf@gmail.com>
Date: Sun, 17 Sep 2023 21:08:00 -0400
Message-ID: <CADPQ2UGNzwXhUHoyZcOFUUjWkjA5RD+ad14RdLOFWFypLPKvog@mail.gmail.com>
To: Hubert Kario <hkario@redhat.com>
Cc: Ilari Liusvaara <ilariliusvaara@welho.com>, uta@ietf.org
Content-Type: multipart/alternative; boundary="000000000000b08a6c060597c681"
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/bM1veBlWTNBRmgzxfClcGWF-d-U>
Subject: Re: [Uta] Reviews requested - draft-ietf-uta-ciphersuites-in-sec-syslog
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Sep 2023 01:08:18 -0000

Hi Hubert,

I don't think that the guidance should be "MUST NOT". That would be
exceeding the recommendation of BCP 195 and would leave administrators of
devices that only support TLS_RSA_WITH_AES_128_CBC_SHA with no
interoperability options. Following the guidance of BCP 195 by using
"SHOULD NOT" will (hopefully) give an Administrator some pause to think
about why that guidance was given. I would prefer that rather than having
an Administrator just see that the guidance is "MUST NOT" and then blindly
ignore it with no thought given to any consequences.

Best regards,
Chris

On Wed, Sep 13, 2023 at 8:23 AM Hubert Kario <hkario@redhat.com> wrote:

> RSA key exchange are the worst ciphersuites you can possibly use, they
> should
> be MUST NOT as anything else is an improvement.
>
> If that's the only interoperable ciphersuite that's available in the
> environment
> that the administrator is configuring, they'll ignore any guidance anyway.
>
> On Wednesday, 6 September 2023 22:14:54 CEST, Chris Lonvick wrote:
> > 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 administrator would
> > then be able to decide if the client has to be upgraded to use a
> > secure cipher suite, or if it acceptable for a time to continue
> > using a cipher suite with known problems.
> >
> > Best regards,
> > Chris
> >
> > On Wed, Sep 6, 2023 at 1:07 PM Ilari Liusvaara
> > <ilariliusvaara@welho.com> wrote:
> > 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 of RFC 9325 (BCP
> 195)
> >> and will continue to allow devices to offer that algorithm --and allow
> log
> >> messages to continue to be delivered during a transition.
> >
> > How would having a MUST NOT break things? Servers are already required
> > to ignore any unsupported or disabled ciphersuites.
> >
> >
> >
> >
> > -Ilari
> >
>
> --
> Regards,
> Hubert Kario
> Principal Quality Engineer, RHEL Crypto team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
>
>