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

Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 18 September 2023 01:26 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 17824C14CF18 for <uta@ietfa.amsl.com>; Sun, 17 Sep 2023 18:26:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dukhovni.org
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 AYVl76GyWLao for <uta@ietfa.amsl.com>; Sun, 17 Sep 2023 18:26:33 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 115ABC14CE4A for <uta@ietf.org>; Sun, 17 Sep 2023 18:26:32 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 24494137E85; Sun, 17 Sep 2023 21:26:31 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dukhovni.org; s=f8320d6e; t=1695000391; bh=s4KLGFMKAkDm5j8Bc8vyv/WR+0i8yeb8TqmgjyYCSMU=; h=Date:From:To:Subject:Reply-To:References:In-Reply-To; b=GV2fcbFEfX9P/k4F9gwAl65ADpU3oZ4QaiPWGkM1RkRX8X0RTNap71yfQs9awRYNy TRpC+GZbO0AZWIXdcziOTQ5bZKbdMuJ2DYbdNo3E8JJvJaLsPPawijzF10phDeO6U1 Ouf/5CWMXUhIV9hYcbaFuaCo6G4ITe+4a/4STN18=
Date: Sun, 17 Sep 2023 21:26:31 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: uta@ietf.org
Message-ID: <ZQenRxD6q0MfQ007@straasha.imrryr.org>
Reply-To: uta@ietf.org
References: <CADPQ2UH81rQSbLhfZMCm9o_KZysWXpBhESS7Bv53XRL=ifUSaA@mail.gmail.com> <ZPC0qrEEdwsFeQBt@straasha.imrryr.org> <CADPQ2UEjj-xCkeVwF0P1uwgGxzc++8knmTQpc3fDBzdhxxBE-Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CADPQ2UEjj-xCkeVwF0P1uwgGxzc++8knmTQpc3fDBzdhxxBE-Q@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/ROBcD1hlT1bgKXaU4unbcIVxP1k>
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:26:38 -0000

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.
> 
> We're still looking for more reviews and discussion on this topic.

I do think that "SHOULD NOT" is a step in the right direction.  And I
expect, based on prior experience with other IETF deprecation
activities, that this is likely the best bargain I can hope to reach.

However, a close reading of my orignal post will show that I believe
that even that is needlessly prescriptive.

Security improves primarily when we raise the ceiling, not the floor
(there are exceptions when not raising the floor opens opportunities for
downgrade or cross-protocol attacks).

The outcome we're looking for is that stronger ciphers be implemented
and used.  Punishing the long tail of slow adopters is rather a
secondary goal.

And IMHO with syslog, where I would prioritise availability over maximal
channel security, if this were my text to write, I'd would say:

    * Peers MUST implement the new MTI ciphers (tautology given MTI).

    * Must negotiate the MTI ciphers in preference to the deprecated
      ciphers (MAY also negotiate equally strong or stronger
      alternatives to the MIT ciphers).

Note, this does not say anything about requiring non-support of the
legacy ciphers.  But it could be reasonable to add:

    * Operators SHOULD consider disabling the deprecated ciphers once
      no longer needed to support any of the expected clients.

In other words, an orderly transition with no disruptive removal of
interoperability before all the expected peers are ready.

-- 
    Viktor.