Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'
David Benjamin <davidben@chromium.org> Mon, 11 December 2023 23:38 UTC
Return-Path: <davidben@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B37E2C15108B for <tls@ietfa.amsl.com>; Mon, 11 Dec 2023 15:38:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.258
X-Spam-Level:
X-Spam-Status: No, score=-9.258 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.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 5iX2PssBEuei for <tls@ietfa.amsl.com>; Mon, 11 Dec 2023 15:38:24 -0800 (PST)
Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (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 F2202C151086 for <tls@ietf.org>; Mon, 11 Dec 2023 15:38:22 -0800 (PST)
Received: by mail-yb1-xb32.google.com with SMTP id 3f1490d57ef6-db549f869a3so5357568276.1 for <tls@ietf.org>; Mon, 11 Dec 2023 15:38:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1702337902; x=1702942702; darn=ietf.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=1V15YlPdp5T1fQhaZBnhBMzGofi8AN4g3/m+EHwiZa8=; b=lCfJtsWwWNbnEZk85NSnThAdeOTskX4IXamwOHo65Jt5ecLVwoFkZuyFq+Xecn1aj7 AOek6E9VT08BKeC7++NgcMInjsyn1j3ewmQ2KAjUBOVkCwFDQI8BKGzhpbAO1zLgLie9 ypExQiUPi/gBwgjebHoVjhszSxCN5jQVw2rhw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702337902; x=1702942702; h=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=1V15YlPdp5T1fQhaZBnhBMzGofi8AN4g3/m+EHwiZa8=; b=ePLnPyhxjTp+sZzLd8HIJCbDYwiGJZNl4s04T62W/6KBck1lBIKXVMz7YpVkah9NEe ruSCAxorAYEAUCMSVq4ADdyIvfIVmiwVJ189x+OWjGIVryyeQoQ4C6ZKsqwXIjL/azzn SGt55Sjj8FLHlqSghf0f+mWkSV5fHxsUANWSnQLrUKSdCeZGm+zlBzCNXOCap8Uqt7uY /anGJBBI0E1QA3eTLJK+umpGP3Awlj1/6L6ibUovNbtDgR7KtNpXdIWRdWUbvWORxn2g zQS7K9KdUloTYLFHee2hCvsT5pwNZG/RQMi17giF0qiAOrmfoemCSVlxNaS4BKMKm3c+ K77g==
X-Gm-Message-State: AOJu0Yzhb4Ey+sMwNNatqQq4mAXVwPRpiQnohkDfJtvw3wNfeU462VJK dCq/p52IL2GbDH0QmYubqv3d6wCq1x3cqVbrDX2hxEnqBe57iPvtSNRw
X-Google-Smtp-Source: AGHT+IGLY1JycogElme31b/LU66nYpovFoV2ZGwfJEsE1LPvAL+EGrQoDBbyyydDrq09P7kS/b2GXvza3yMC9tUndjo=
X-Received: by 2002:a5b:206:0:b0:db7:dacf:ed9d with SMTP id z6-20020a5b0206000000b00db7dacfed9dmr3070527ybl.126.1702337901642; Mon, 11 Dec 2023 15:38:21 -0800 (PST)
MIME-Version: 1.0
References: <CAChr6Szq5vBgcea2+BHcT3ZK_Smk+L2jLsQ2L7kiAKjPXxaRsA@mail.gmail.com> <ZXeGEzoOr9somacx@straasha.imrryr.org>
In-Reply-To: <ZXeGEzoOr9somacx@straasha.imrryr.org>
From: David Benjamin <davidben@chromium.org>
Date: Mon, 11 Dec 2023 18:38:05 -0500
Message-ID: <CAF8qwaAXSEWTAOk9xP6TbFkAPzkkPdhcT7vY725pCMAPoByGWw@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000eb9aa9060c446dfe"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/rdTMdUvNoUu6erxF1dxmaeUfTO0>
Subject: Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Dec 2023 23:38:27 -0000
I don't think that quite captures the tradeoffs. Sure, TLS 1.2 will be around for quite some time, but that *does not mean it is worth adding new features to TLS 1.2*. Those two statements are not directly related. Protocol changes generally require both client and server changes to take effect. Pre-existing deployments, by simply pre-existing, will not have those changes. If we add, say, post-quantum options for TLS 1.2, it will benefit zero existing TLS 1.2 deployments. If we add post-quantum options for TLS 1.3, it will benefit zero existing TLS 1.3 deployments. That's not why we make these changes. We make them to benefit *future* TLS deployments, e.g. when server operators update their software. Although it can be a slow progress, pre-existing deployments gradually cycle into updated deployments. So when we decide whether to make a change to TLS 1.2 or TLS 1.3, the pre-existing deployments of both protocols are irrelevant. What matters is what will be used in new TLS software. At this point, now that TLS 1.3 is well-established, we should broadly expect new TLS software to be TLS-1.3-capable. Thus is it not worth our time to backport such changes to TLS 1.2. When I say "our", I don't mean just this working group, but also TLS implementers, application software that configures TLS implementations, and server operators who must somehow navigate the sea of options that comes from everyone else's indecision. Together, those costs are significant. More than that, we (the WG) should communicate this expectation. We did it once by publishing RFC 8446 and obsoleting RFC 5246. hence this document. But communication is hard, and now that the expectation is stronger, we should repeat it more strongly. There will always be stragglers and misunderstandings. Perhaps some more obscure TLS implementation has yet to implement TLS 1.3. (Or DTLS 1.3.) Perhaps some application has a hardcoded TLS 1.2 setting that needs to be updated. Perhaps some config files are stale. Publishing this document helps clear up what was already the WG's expectation. If it reminds a chunk of those folks to move to TLS 1.3, it will have been worthwhile. That is also why mentioning PQC is valuable, as it is the extension that is most likely to be on server operators' minds. Finally, communicating this is useful to us. Perhaps some new deployments are TLS 1.2 not out of inertia, but because something in TLS 1.3 inadvertently made migration difficult for those folks. In that case, us publishing this document helps invite such feedback. For example, draft-ietf-tls-tls13-pkcs1 addresses a migration challenge. (That specific example long predates this and, judging by the list discussion in 2019, it was perhaps a little ahead of its time, but we all got there eventually. :-D) This has nothing to do with raising the floor. This is about not bothering to start a new, shorter tower on the side while we raise the main ceiling. On Mon, Dec 11, 2023, 16:58 Viktor Dukhovni <ietf-dane@dukhovni.org> wrote: > On Mon, Dec 11, 2023 at 12:32:36PM -0800, Rob Sayre wrote: > > > PS - I have to say, not in this message, but sometimes it seems like the > > goal of TLS 1.2 advocates is weaker encryption. So, for them, the flaws > in > > TLS 1.2 that the draft describes are desirable. If that's the case, > > participants are not working toward the same goal. Writing down the > > consensus seems worth it. > > For what it is worth, my agenda/perspective has never been to weaken > encryption. Rather, it has always been about making usable encryption > ubiquitous. While we continue work on raising the ceiling, one can be > legitimately weary of raising the floor so high that encryption is > unusable, and communication happens in the clear instead. > > Given that TLS 1.2 will be around for quite some time, it is not obvious > that a feature freeze will in practice improve security. It is good > that there's ongoing effort to make TLS 1.3 better, and I accept that it > may well not be possible to deliver on required TLS 1.3 work and to also > make some occasional modest improvements to TLS 1.2, but if the goal is > to deliver secure products to users, a realist might accept that TLS 1.2 > is likely to continue to be used for some time, and that those users > could be better served if some improvements continued to take place. > > The contrarian possition of course assumes that such improvements > wouldn't be a significant drain on scarce resources. That assumption is > a matter for debate, and the "right" trade-offs are not completely > obvious. Some difference of perspectives can be expected. > > Whatever else we do, we should not default to questioning the motives of > others who would make somewhat different tradeoffs. Worry more when > everyone is in violent agreement, perhaps something is then being > missed. > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
- [TLS] Adoption call for 'TLS 1.2 Feature Freeze' Deirdre Connolly
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Salz, Rich
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Arnaud Taddei
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Stephen Farrell
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Peter Gutmann
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Nimrod Aviram
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Dmitry Belyavsky
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Sean Turner
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… David Benjamin
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… David Schinazi
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Chris Barber
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… John Mattsson
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Salz, Rich
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Dennis Jackson
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Arnaud Taddei
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Christopher Patton
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… John Mattsson
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Bob Beck
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Rob Sayre
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Marten Seemann
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Loganaden Velvindron
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Hannes Tschofenig
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Hannes Tschofenig
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Watson Ladd
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Viktor Dukhovni
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Rob Sayre
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Viktor Dukhovni
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Rob Sayre
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Viktor Dukhovni
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Peter Gutmann
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Peter Gutmann
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… hannes.tschofenig
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Rob Sayre
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Viktor Dukhovni
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Peter Gutmann
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Ilari Liusvaara
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Bas Westerbaan
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Salz, Rich
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Watson Ladd
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Peter Gutmann
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Viktor Dukhovni
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Peter Gutmann
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Watson Ladd
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Loganaden Velvindron
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Nimrod Aviram
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… William Stratton Apsokardu
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Salz, Rich
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Bas Westerbaan
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Peter Gutmann
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Arnaud Taddei
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… David Benjamin
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Deirdre Connolly
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Tim Hollebeek
- Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Fe… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Ira McDonald
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Peter Gutmann
- Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Fe… Salz, Rich
- Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Fe… Martin Thomson
- Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Fe… Rob Sayre
- Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Fe… Eric Rescorla
- Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Fe… Salz, Rich
- Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Fe… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Fe… Salz, Rich
- Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Fe… Salz, Rich
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Arnaud Taddei
- Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Fe… Bas Westerbaan
- Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Fe… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Fe… Eric Rescorla
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Achim Kraus
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Peter Gutmann
- Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Fe… Tim Hollebeek
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Peter Gutmann
- Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Fe… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Salz, Rich
- Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Fe… Peter Gutmann
- Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Fe… David Benjamin
- Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Fe… Martin Thomson
- Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Fe… Rob Sayre
- Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Fe… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Fe… Eric Rescorla
- Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Fe… Benjamin Kaduk
- Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Fe… Eric Rescorla
- Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Fe… Martin Thomson
- Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Fe… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Fe… Rob Sayre
- Re: [TLS] Adoption call for 'TLS 1.2 Feature Free… Rob Sayre