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

"Salz, Rich" <rsalz@akamai.com> Tue, 26 March 2024 00:29 UTC

Return-Path: <rsalz@akamai.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 98E05C18DBBF for <uta@ietfa.amsl.com>; Mon, 25 Mar 2024 17:29:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 (2048-bit key) header.d=akamai.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 mYXij3OzoSwI for <uta@ietfa.amsl.com>; Mon, 25 Mar 2024 17:29:33 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2EAEC180B47 for <uta@ietf.org>; Mon, 25 Mar 2024 17:29:32 -0700 (PDT)
Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.17.1.24/8.17.1.24) with ESMTP id 42PHuZNf000957; Tue, 26 Mar 2024 00:29:25 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h= from:to:subject:date:message-id:references:in-reply-to :content-type:content-id:content-transfer-encoding:mime-version; s=jan2016.eng; bh=aoBvOq4smWAGYLx1XuycjRWKZe9GEfdowHfdQTePb9k=; b= LQ6KH3kokDn/YFtktBw66Hgs6LhhbfgATqW24Y9BHgcPvuzLpN8MbSUM6IrSqhED VUI6NTPGeVxnSL0WlvElHUT7NwwkZHvL1LUusgkGJfvkkB0NBK+JKPltzzH0UkxV rgcEONidy5H6jm+lSHZ0m4J75NDqAXbJEtgCqQ0OhAA2zG2M3AJqA6O4zx1u4UHU M270+R73nFpU4LrGPULAZzDqwP6dT7j1dfT7XItiOiAVJLg+UcdvlciP32FH3NAa vLN/Sxj5dxcGT8KAbt/0h/++GQdIdOKhNQPra8QXKCvwKCmoHzdoiBw2dmg/S2xF KND+wyrADsD3NJGMM2RBUQ==
Received: from prod-mail-ppoint8 (a72-247-45-34.deploy.static.akamaitechnologies.com [72.247.45.34] (may be forged)) by mx0a-00190b01.pphosted.com (PPS) with ESMTPS id 3x1q7cfc7s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 26 Mar 2024 00:29:25 +0000 (GMT)
Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.17.1.19/8.17.1.19) with ESMTP id 42PLhKIh031192; Mon, 25 Mar 2024 20:29:24 -0400
Received: from email.msg.corp.akamai.com ([172.27.50.206]) by prod-mail-ppoint8.akamai.com (PPS) with ESMTPS id 3x1tdyc3rp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 25 Mar 2024 20:29:24 -0400
Received: from ustx2ex-dag4mb4.msg.corp.akamai.com (172.27.50.203) by ustx2ex-dag4mb7.msg.corp.akamai.com (172.27.50.206) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Mon, 25 Mar 2024 17:29:24 -0700
Received: from ustx2ex-dag4mb4.msg.corp.akamai.com ([172.27.50.203]) by ustx2ex-dag4mb4.msg.corp.akamai.com ([172.27.50.203]) with mapi id 15.02.1258.028; Mon, 25 Mar 2024 17:29:24 -0700
From: "Salz, Rich" <rsalz@akamai.com>
To: Alan DeKok <aland@deployingradius.com>, "uta@ietf.org" <uta@ietf.org>
Thread-Topic: [Uta] Comments as draft-rsalz-uta-require-tls13
Thread-Index: AQHafqBI8lUE/2sMiUKl+cPkfcbHj7FJXlUA
Date: Tue, 26 Mar 2024 00:29:23 +0000
Message-ID: <6BD396CD-E223-4A90-8E84-D99C6EAB5F08@akamai.com>
References: <3E6241EB-24CB-4B42-9B7F-7AB32DCC290C@deployingradius.com>
In-Reply-To: <3E6241EB-24CB-4B42-9B7F-7AB32DCC290C@deployingradius.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.81.24012814
x-originating-ip: [172.27.118.139]
Content-Type: text/plain; charset="utf-8"
Content-ID: <23CF155E0226C047A0D9229A04059470@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-03-25_25,2024-03-21_02,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 spamscore=0 adultscore=0 suspectscore=0 mlxlogscore=956 phishscore=0 mlxscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2403210000 definitions=main-2403260000
X-Proofpoint-GUID: XT717ZWPUDO7U_0sTYEmoPsAG4RHntBk
X-Proofpoint-ORIG-GUID: XT717ZWPUDO7U_0sTYEmoPsAG4RHntBk
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-03-25_25,2024-03-21_02,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 clxscore=1011 mlxscore=0 lowpriorityscore=0 phishscore=0 malwarescore=0 priorityscore=1501 spamscore=0 adultscore=0 bulkscore=0 mlxlogscore=876 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2403210001 definitions=main-2403260001
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/kqdBIlYCO-R9cmQoHbQJSlFdO48>
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:29:36 -0000

> Speaking as non-chair (and my first post to the list).

Welcome.

Yes, distinguishing between the standard (or protocol spec) and the implementation is a (hopefully slight?) source of confusion within the draft.

> New standards MUST require TLS 1.3 or higher.

The problem with the "or higher" construct, one Jonathan Hoyland strongly favors, is that it doesn't get you what you want, or at least what he wants. 

> These implementations SHOULD have a way to configure the minimum allowable TLS version to use. If this setting is configurable, any default example MUST use TLS 1.3. If the TLS versions are not set in any configuration, then the implementation MUST use TLS 1.3 or higher.

Except for "or higher" (see below) this seems nice.

OpenSSL used to allow "holes" in the protocols, which you said is what wpa_supplicant allows. I think it was in 1.1 that OpenSSL moved to a min/max approach. That is better because the common meaning of omitting the max version is "the highest one available."

The problem with the "holes" approach is that it tends to be "explicitly enable the versions you want" because at first glance that's more flexible.  But when a new version comes along, your configuration is now outdated until you go edit to add the new version. If you use the "explicitly disable the versions you want" it turns out that almost all the time what you are disabling is a sequence of old versions. In which case, setting the min version is simpler. It is hard to see a scenario, except for bugs, where "1.1,1.3" are allowed and "1.2" is a reasonable configuration to have.

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.

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.

Hope this helps.