[TLS] How are we planning to deprecate TLS 1.2?
Nimrod Aviram <nimrod.aviram@gmail.com> Fri, 03 March 2023 18:18 UTC
Return-Path: <nimrod.aviram@gmail.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 6AC28C1516FF for <tls@ietfa.amsl.com>; Fri, 3 Mar 2023 10:18:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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, 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=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 NgxfSQyhb5dm for <tls@ietfa.amsl.com>; Fri, 3 Mar 2023 10:18:07 -0800 (PST)
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 D4D9CC1516E9 for <tls@ietf.org>; Fri, 3 Mar 2023 10:18:07 -0800 (PST)
Received: by mail-ed1-x52d.google.com with SMTP id s11so13758291edy.8 for <tls@ietf.org>; Fri, 03 Mar 2023 10:18:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1677867486; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=MMwhrtR+7Nz9AtrcFwWYGeDxYL8gYSM4Oxdv4zxiPQA=; b=lXtBvgE/hmYQxr9RWkEARL+iBD3TatnGSA3HRUCw3vEf1ZlAfOFii8fcqzQWoMHqGu n0yJKfaqfOS0PejiJvHlkC9p7Ku5/ABWxSlBRJsoq5nkB/1LQnxmqZ6cyheBhEAt7DHY 8XmLZBMUwAXgfrP7QFG1PdNw+7ac3PTycM4aATBI5UMc5+esGDBjqmYTz5SWlc7EkFKN sv/BZvGFgqghGD5pT9J2mGasDE48qeU3GOrtG68QXaw63iXL8S0V2JNOaaTjNyEtchNG 7MCpq1oy6XkbCYFM5gohAYHul1eqVtveQqEwfNRdyuvSnRvVgMXKLgFNrlvSq2fCp9V+ Kgnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677867486; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=MMwhrtR+7Nz9AtrcFwWYGeDxYL8gYSM4Oxdv4zxiPQA=; b=OD856yEdllFJlb86LbnQe4U/5SQswIDS5KNUbenV9ToLJaOFfMdWUU/a3ACbcSc5Q/ +TxSgTiHejpJmtvFZO9HhgcyM+aMcI+DOGr47KgC/CWUPYJ4bXGWyqbxxNFUDE60z+OJ 4fen1uwfloQHNiUikFEd345KzBy0O+XqgyEG0jpDXZDafWdzkdc9IsBEoretISVrfd1/ 5NvAlOGGFD3HVaDApFs4S2aPBxMK68lssfrvB0k1B18f9u/a8zhB59V7bJsvSg4B2TiR vVM4+PACErz7ph8l0v7EbrHLGM50MD35y8SSiXVj93RmCI8OveNi+iX9+Uc7gKc4hMNZ 42lQ==
X-Gm-Message-State: AO0yUKV1UsqLCjGwH+gormwIxzbWib5UuBuyuZ45eFWNpN4OmuqyW0Ke lmSLxzEleawt/+PIm707RXFj5caUh7WeZq29NGFHaf+06kH30A==
X-Google-Smtp-Source: AK7set9fT+uliZ4RLqdLDhjU2sYdHq5Xm27VhLRddCclsNxLlmYOK6HvmNscySG94ZYGNh1x528jjdWdXU+OuxNM4Rg=
X-Received: by 2002:a17:906:a0d8:b0:8b1:2ebf:386b with SMTP id bh24-20020a170906a0d800b008b12ebf386bmr1314469ejb.12.1677867485958; Fri, 03 Mar 2023 10:18:05 -0800 (PST)
MIME-Version: 1.0
From: Nimrod Aviram <nimrod.aviram@gmail.com>
Date: Fri, 03 Mar 2023 20:17:55 +0200
Message-ID: <CABiKAoTN-Y2317qZi6vwyOvhMwtTjtY9wROorNXEjEEegg-zfg@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007b15ca05f602f7f5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Orh6A2cMNUhvh_1wE9QR-1av9JY>
Subject: [TLS] How are we planning to deprecate TLS 1.2?
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: Fri, 03 Mar 2023 18:18:08 -0000
Hi Everyone, We’ve recently had a brief side discussion around the issue of letting vendors (or operators) know when something is expected to be deprecated: https://mailarchive.ietf.org/arch/msg/tls/Djk35kp5P5Z1WfmN8_OJj_eYRLo/ Currently, there is no expected deprecation timeline for any specific primitive or protocol version. As one example, it seems like we plan to deprecate RSA key exchange in TLS 1.2 soon (as part of draft-ietf-tls-deprecate-obsolete-kex). However, so far we did not explicitly communicate this to vendors, and it seems like vendors either have to follow the mailing list and deduce the likelihood of an upcoming deprecation, or face a deprecation RFC at some random point in time (from their point of view). And whatever the specifics of RSA key exchange deprecation, this will likely not be the last time we deprecate something :-) Specifically, we will have to decide when/if to deprecate version 1.2 of TLS within, say, the next 20 years. One possible solution is to publish “expected deprecation timeline” documents: Let’s fix some timeframe which “is enough for everyone to upgrade at least once” (famous last words, I know). I think of this timeframe as 3 or 5 years, but it could as well be 8 or 10 years, and this solution would still be viable; let’s denote the number of years as X. So, an “expected deprecation timeline” document could specify that within X years, implementations MUST support TLS 1.3, and within 2X years, implementations MUST NOT support TLS 1.2. (If X=8 years, then we specify that by 2031 implementations MUST support TLS 1.3, and by 2039 implementations MUST NOT support TLS 1.2.) This would clarify the WG’s expectations to vendors, and would save the WG valuable time discussing whether enough implementations in the field support the new protocol/primitive. Is there interest here in such a solution? Credit where it’s due: This is based on an idea I heard from Dan Bernstein - thanks Dan. Best, Nimrod
- [TLS] How are we planning to deprecate TLS 1.2? Nimrod Aviram
- Re: [TLS] How are we planning to deprecate TLS 1.… Eric Rescorla
- Re: [TLS] How are we planning to deprecate TLS 1.… Kenneth Vaughn
- Re: [TLS] How are we planning to deprecate TLS 1.… Sean Turner
- Re: [TLS] How are we planning to deprecate TLS 1.… Bas Westerbaan
- Re: [TLS] How are we planning to deprecate TLS 1.… Ilari Liusvaara
- Re: [TLS] How are we planning to deprecate TLS 1.… Viktor Dukhovni
- Re: [TLS] How are we planning to deprecate TLS 1.… Rob Sayre
- Re: [TLS] How are we planning to deprecate TLS 1.… Peter Gutmann
- Re: [TLS] How are we planning to deprecate TLS 1.… Watson Ladd
- Re: [TLS] How are we planning to deprecate TLS 1.… Rob Sayre
- Re: [TLS] How are we planning to deprecate TLS 1.… Viktor Dukhovni