[TLS] Re: Working Group Last Call for TLS 1.2 is in Feature Freeze

Eric Rescorla <ekr@rtfm.com> Sat, 07 December 2024 11:43 UTC

Return-Path: <ekr@rtfm.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 A5FF0C169410 for <tls@ietfa.amsl.com>; Sat, 7 Dec 2024 03:43:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Level:
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20230601.gappssmtp.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 Cg0zNTcTUBu5 for <tls@ietfa.amsl.com>; Sat, 7 Dec 2024 03:43:38 -0800 (PST)
Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 784A0C14F695 for <tls@ietf.org>; Sat, 7 Dec 2024 03:43:38 -0800 (PST)
Received: by mail-yb1-xb2d.google.com with SMTP id 3f1490d57ef6-e3985aabf43so2357661276.3 for <tls@ietf.org>; Sat, 07 Dec 2024 03:43:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20230601.gappssmtp.com; s=20230601; t=1733571817; x=1734176617; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=g4q7GN4jgR7oADadT3eXn2vk+O6FJBkucWf3+NE7dn0=; b=gDcX7CTudzqv43Uac5H3oMzlxqrPuQF6oQXMsklS6m7M58nu6Abujjsjz2PXTHm0tg xxzzpzqpYohx8PsFanJa41FYMI3rQeR5C4CYS+6twnJssSSQMwqzZptpOu3ucqXYllod Of4fEas3ZE9m1hhqDmJ9pjIaWlMgfoc/mbhW1c0SzAavTPkRx1osbpnOvyK2nfIwe3rE EUHEXj6j+E5o7ORmzG7WKbFnfNwkTcHS0D3tS3N3YCYDVO9gplBNbUnAoMSMeandQIUJ Wgk7nvtTR62JHp8HDMcaeFPNqEIUbZDpX88TNGAizAZvKMqz5P0rjUY1TwFmqnEYvorB GwPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733571817; x=1734176617; h=cc: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=g4q7GN4jgR7oADadT3eXn2vk+O6FJBkucWf3+NE7dn0=; b=j1f/lU94D77Cd00OSXYPJyl89YaZ/cqLAKLWNEYgP8O2SiATxbe2JmnoiDZhdjtiHZ Nq/Za+GIArf/CNqAWJLqtFWNI5L6wUMa1pCngVIHxj7honuEsogeijElS9/REvbM5Pk6 k5dZm30By/tfYWeEDYiAtmLNylUTbtIUYVdY0u9r3TWKEUwbcXuUYBa8RBSScYox54ZH a5BPKBOE1s1xETFmo4vM2243BjejKUAy1Xcdy783hkbkjc86i4Q1TevOgyTPztQqLjNQ HiQTaWrrcU4Mj/NQUrjGQPVOOX3/1IlTf216nvoRPVOoygAOcx7aJFIzdWL8HxtW/LSJ b45g==
X-Forwarded-Encrypted: i=1; AJvYcCWc8kOe1stGHw2vFI+xhpGPRwLQYAeArTh+PuRPM8GgrI2P7Esh0NdC6E9y+aWYmTH9pIs=@ietf.org
X-Gm-Message-State: AOJu0YwPrKP5j5st+qaQqh3yM4jkJ03vK8K4uyvwui8j9mkEByI4HRSy BFMbwsrr16lfsyHElhbTf59zfmfPypwoc64ikfWYRYk3V6uXppFibmRs5DsT/hOfL9VX3UJJ5SF TcEHHIiTM5z0TOsWjZfBSPhaOSu4Xdcg9JNPicA==
X-Gm-Gg: ASbGncv4m+cW2syrV798r40Y5T3HOHm9gL3KkYilVoOPPznptfOM91w6ls865IQ5gX/ 2q/n40AVYLsVYeyQrqlS7AIrSP8f3hwA=
X-Google-Smtp-Source: AGHT+IHDoVOpa5ok7h1pe16Q0YrwOEMJ+IUl/g1pMI0jEe2VETYZZanpr4Q91qWBykJQywByoPyQKKw4w+vXqVnqG/c=
X-Received: by 2002:a05:6902:138d:b0:e39:7b55:ff7d with SMTP id 3f1490d57ef6-e3a0b6bbabfmr4275596276.49.1733571817369; Sat, 07 Dec 2024 03:43:37 -0800 (PST)
MIME-Version: 1.0
References: <F98C87B7-B31D-4702-B694-0CB1A8FB38C5@sn3rd.com> <07fa01db461a$b2f05330$18d0f990$@gmail.com> <cc74d2fa-c452-4267-900f-41dee05dd9c6@tu-dresden.de> <GVXPR07MB9678AE6A1DD7953668BE73DF89322@GVXPR07MB9678.eurprd07.prod.outlook.com>
In-Reply-To: <GVXPR07MB9678AE6A1DD7953668BE73DF89322@GVXPR07MB9678.eurprd07.prod.outlook.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 07 Dec 2024 03:43:01 -0800
Message-ID: <CABcZeBMCx+xxssw4iqYUsLp1Cr1XSxw1HXjrnP-yWq-VZA9AFw@mail.gmail.com>
To: John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005e0f5f0628aca424"
Message-ID-Hash: UIMCQFUACNAYQNME6HMD3XNTSRLF66VC
X-Message-ID-Hash: UIMCQFUACNAYQNME6HMD3XNTSRLF66VC
X-MailFrom: ekr@rtfm.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: TLS List <tls@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: Working Group Last Call for TLS 1.2 is in Feature Freeze
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/r5iKOKXeHvDbubAP4uRXf5NnCbY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Owner: <mailto:tls-owner@ietf.org>
List-Post: <mailto:tls@ietf.org>
List-Subscribe: <mailto:tls-join@ietf.org>
List-Unsubscribe: <mailto:tls-leave@ietf.org>

On Sat, Dec 7, 2024 at 12:14 AM John Mattsson <john.mattsson=
40ericsson.com@dmarc.ietf.org> wrote:

> Muhammad Usama Sardar wrote:
>
> >Do we have an I-D which defines how long do we consider as long-term
> connections? or I-D which gives recommendations or best practices for how
> long do we consider TLS 1.3 to provide excellent security?
>
>
>
> - One clear timepoint is when the server certicate expires. TLS 1.3
> removed the ability to do server reauthentication.
>
- RFC 4253 recommends rekeying with PFS after each gigabyte of transmitted
> data or after each hour of connection time.
>
- French ANSSI recommends periodic rekeying with PFS, e.g. every hour and
> every 100 GB of data, in order to limit the impact of a key compromise.
>
> https://cyber.gouv.fr/sites/default/files/2015/09/NT_IPsec_EN.pdf
>

TLS 1.3 KeyUpdate provides forward security: if you recover key N+1, you do
not get key N. What it does not provides is post-compromise security,
namely, if you recover key N, then you also can recover key N+1, etc. PCS
requires a new asymmetric exchange.


-Ekr



>
>
> >If the intention of draft was #2 above, cross-reading with this sentence,
> are we implying that PQC is not an urgent security issue?
>
>
>
> That is a very good point. I suggest changing this to
>
> OLD: “This document specifies that outside of urgent security fixes, no
> new features will be approved for TLS 1.2”
>
> NEW: “This document specifies that, no new features will be approved for
> TLS 1.2”
>
> (TLS WG can always make a future RFC overriding this anyway…)
>
>
>
> >It looks like a more detailed version of tls12-frozen draft. Is there a
> good reason not to merge the two documents?
>
>
>
> I had the same thought. I think they would be better as a single document.
> But I don’t care very much.
>
>
>
> >What does the capitalization of WILL NOT mean?
>
>
>
> Yes, and it is not in RFC 6919 either… ;)
>
>
>
> Cheers,
> John
>
>
>
> *From: *Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de>
> *Date: *Friday, 6 December 2024 at 18:33
> *To: *Valery Smyslov <smyslov.ietf@gmail.com>, 'Sean Turner' <
> sean@sn3rd.com>, 'TLS List' <tls@ietf.org>
> *Subject: *[TLS] Re: Working Group Last Call for TLS 1.2 is in Feature
> Freeze
>
> A few quick questions. Sorry if I am missing something obvious or some
> background.
>
> On 04.12.24 08:04, Valery Smyslov wrote:
>
> note, that UTA WG has issued a WGLC for draft-ietf-uta-require-tls13-02 (New Protocols Must Require TLS 1.3) [1].
>
>
>
>  [1] https://datatracker.ietf.org/doc/draft-ietf-uta-require-tls13/
>
> Thanks for pointer to this. It looks like a more detailed version of
> tls12-frozen draft. Is there a good reason not to merge the two documents?
> Is it due to different WGs? or different intended status? or something
> else?
>
>
>
>
>
> On 04.12.24 10:36, John Mattsson wrote:
>
> as-is, TLS 1.3 does not provide excellent security for long-term
> connections.
>
> Do we have an I-D which defines *how long* do we consider as long-term
> connections? or I-D which gives recommendations or best practices for *how
> long *do we consider TLS 1.3 to provide excellent security?
>
> ---
>
> Considering the following two statements in I-D, I have two questions:
>
> >   For TLS it is important to note that the focus of these efforts is
>
> >   TLS 1.3 or later.  Put bluntly, post-quantum cryptography for TLS 1.2
>
> >   WILL NOT be supported.
>
> To me the two sentences are contradicting. Which one of the following is
> intended?
>
>    1. (My understanding from 1st sentence) Some PQC support for TLS 1.2
>    will still continue but it will not be the focus.
>    2. (My understanding from 2nd sentence) We will exclusively work on
>    PQC for TLS 1.3 or later.
>
> What does the capitalization of WILL NOT mean? I did not find any such
> capitalization in RFC 2119 and RFC 8174. Please add the relevant RFC in
> section 2 or define it.
>
> >   This
>
> >   document specifies that outside of urgent security fixes, no new
>
> >   features will be approved for TLS 1.2.
>
> If the intention of draft was #2 above, cross-reading with this sentence,
> are we implying that PQC is not an urgent security issue?
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org
>