Re: [Uta] Comments as draft-rsalz-uta-require-tls13

Alan DeKok <aland@deployingradius.com> Tue, 26 March 2024 00:59 UTC

Return-Path: <aland@deployingradius.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 66553C14F68C for <uta@ietfa.amsl.com>; Mon, 25 Mar 2024 17:59:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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] autolearn=ham autolearn_force=no
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 SuQFy4OVFgcY for <uta@ietfa.amsl.com>; Mon, 25 Mar 2024 17:59:28 -0700 (PDT)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (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 A0A6EC14F61A for <uta@ietf.org>; Mon, 25 Mar 2024 17:59:27 -0700 (PDT)
Received: from smtpclient.apple (135-23-95-173.cpe.pppoe.ca [135.23.95.173]) by mail.networkradius.com (Postfix) with ESMTPSA id 19D53611; Tue, 26 Mar 2024 00:59:22 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <6BD396CD-E223-4A90-8E84-D99C6EAB5F08@akamai.com>
Date: Mon, 25 Mar 2024 20:59:21 -0400
Cc: "uta@ietf.org" <uta@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9FD21A85-4778-445D-8129-29C5F50EA081@deployingradius.com>
References: <3E6241EB-24CB-4B42-9B7F-7AB32DCC290C@deployingradius.com> <6BD396CD-E223-4A90-8E84-D99C6EAB5F08@akamai.com>
To: "Salz, Rich" <rsalz@akamai.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/cPE2cUJY0NP1vnfBkMsqQW4y-aQ>
Subject: Re: [Uta] Comments as draft-rsalz-uta-require-tls13
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: Tue, 26 Mar 2024 00:59:30 -0000

On Mar 25, 2024, at 8:29 PM, Salz, Rich <rsalz@akamai.com> wrote:
> 
>> Speaking as non-chair (and my first post to the list).
> 
> Welcome.

  Thanks!

> I think in all but special cases specifying just the minimum is fine. The only reason I can think of for specifying the max version is that you have regulatory/compliance issues to comply with.

  We ran into this in EMU with EAP-TLS.  The EAP application derived application-specific keys based on TLS key exporter constructs.  Those constructs changed with TLS 1.3, and all of the code which supported "TLS 1.2 or higher" broke in weird ways.

  Applications had to add a "maximum TLS version" configuration to explicitly avoid using TLS 1.3, until such time as the EAP-TLS standards were updated.  The maximum needed to be set because by default, OpenSSL would negotiate the highest available TLS version, which usually ended up with 1.3.

  Once EAP-TLS was updated to use the key exporters defined for TLS 1.3, the implementations could be updated.  First the code to support the new functionality, and then the "maximum TLS version" was relaxed to allow TLS 1.3.

  I recall also discussion in the EMU mailing list that the EAP-TLS document needed to forbid systems from automatically updating to the latest TLS version.  The idea was to avoid a similar issue as we saw from the TLS 1.2 to 1.3 transition.  But on reading RFC 9190, I can't see any text to that effect. :(

> The problem with "or higher" is that it needs context and timelines to be useful. Let us suppose that I sell a program, Foobar, that uses the system TLS provider but it is a DLL/.so because I want my customers to be able to install updates that their OS vendor provides.  Now suppose the IETF specifies TLS 1.4 at T0. OS Vendor A supports it at T2, vendor B at T3, and FreeTLS provides it at T1. And of course the events could happen in a different order (except the RFC always comes first :)
> 
> Who becomes non-compliant with the "or higher" construct and at what Tn+delta? And if you say "the highest version available" you're making it even more intractable/worse.
> 
> The current wording seems the least disruptive to me. Yes, in some number of years we'll have to do an update that says TLS 1.4, but that's a lot less work.

  I think removing the "or higher" is the correct thing to do.

  Alan DeKok.