[TLS] Should new SSLKEYLOGFILE entries require IETF Review

Martin Thomson <mt@lowentropy.net> Wed, 11 December 2024 22:54 UTC

Return-Path: <mt@lowentropy.net>
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 C81FBC18DB83 for <tls@ietfa.amsl.com>; Wed, 11 Dec 2024 14:54:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-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=lowentropy.net header.b="qnri7Gnw"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="EIxLVHVG"
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 qq7c8VXsXHgF for <tls@ietfa.amsl.com>; Wed, 11 Dec 2024 14:54:03 -0800 (PST)
Received: from fhigh-a6-smtp.messagingengine.com (fhigh-a6-smtp.messagingengine.com [103.168.172.157]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13E93C180B6D for <tls@ietf.org>; Wed, 11 Dec 2024 14:54:02 -0800 (PST)
Received: from phl-compute-05.internal (phl-compute-05.phl.internal [10.202.2.45]) by mailfhigh.phl.internal (Postfix) with ESMTP id D486D11401C8 for <tls@ietf.org>; Wed, 11 Dec 2024 17:54:01 -0500 (EST)
Received: from phl-imap-01 ([10.202.2.91]) by phl-compute-05.internal (MEProxy); Wed, 11 Dec 2024 17:54:01 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:message-id:mime-version:reply-to :subject:subject:to:to; s=fm2; t=1733957641; x=1734044041; bh=VP kc+X49BXKJQDqsI2s3JzLdxX9ZPxheImMihjFtcEU=; b=qnri7Gnw/vG3tOVraC iyxiYMDj1+8IkwNZcT4/WZLkk1nmEP7TMlTc4xhxEzUxZzRwEjzxw67dC9Czz735 xmR7Vg7BLbKvKRF7N8vrUG0oDVJS3V8QuF+yuCeiRmqFKTFYQSrlC3JK9RWmb+ii ps9y0IYsh1CZ63pmbp9n1LQ7ldU8lmFNpeDoYjcsx7nJsrXJL6KBw+eu3CszN2UA uVfQquFYlVmwO6bBJD8RHw8rAQxlqxhgCNTyhReYFVfuPxTUmi1MABgRprne7F4E hZsx2C2s6pH6hv8D/Ik9GnE7lqH2MQNOtb7WsXVqrZ3Y1NcTdjOzlqLWW36slb1M hFSA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:message-id:mime-version:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1733957641; x=1734044041; bh=VPkc+X49BXKJQDqsI2s3JzLdxX9ZPxheImM ihjFtcEU=; b=EIxLVHVGZ+U+cxvVs/VaZ8vBaBzVsk1LPNsyh/Bg3s7g7nfIjbs 9ZrMYOeZD3RIYYTWf9gnq+p70jaFUQVfObdgxTtZX+I9efFJ5f9C4ccMZLXvgKs1 ixcKbWirtTy8VVy06+SIY0tb3lNTyxJmKHp5LgEwk9cnSarrcwQVepg53wJjDdYM SAx8slTdZHv2UK7oFsRlQNEZ5hPccGQtBJEiABQp5MSDTmj0FEmOT7+mJ8kx2yTi 5D95I5xn4JPE3bVB4uE9q4sg0hTHKMyL1GICmhBupNlhWx8Wm6OjEuJSPjQB/X5k jmHiP+jc05y4OVg8M/eh2Lfdz71i7Z+LoFg==
X-ME-Sender: <xms:CRhaZ7CObQAa_5YA2_w2OGv31pJX0fN10P_2uZMw73g_J-90FmZl2w> <xme:CRhaZxj9DQ9SkPlmj9H9JeWnyKfS_g2GUupX26M8FxEhfW0i14edMj8d_eJ_uxfoJ EZhMxSLo-oPmVx8wlg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrkedugddtfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdpuffr tefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecunecujfgurhepofggfffhvf fkufgtgfesthejredtredttdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdf uceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepveejvd dvhfehgeelffehhfetleegledtfeeggeeljeefudeufeekhfefvdetjeeunecuvehluhhs thgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnth hrohhphidrnhgvthdpnhgspghrtghpthhtohepuddpmhhouggvpehsmhhtphhouhhtpdhr tghpthhtohepthhlshesihgvthhfrdhorhhg
X-ME-Proxy: <xmx:CRhaZ2mr2BN3UAcKXGuC4q0SeMXIqthfc0gk7a1vdoLZ2_69b2fCmA> <xmx:CRhaZ9y98HSSGP1BpoL1UsDFceCC4yRS1tzgJ06xUeVI_YP8mSa4Fw> <xmx:CRhaZwRDKCDH1LJp6aO2FbUWm9JrEE0zzaZDqbfoFauxiwkIr57PFQ> <xmx:CRhaZwa98J0b-oMOiq7uiHvo8klR_LLll7ADKT5MDj8wAgz4tCwzzA> <xmx:CRhaZ55s3kbW0cs3f7vzHbK27B4Ibm7Jsxc1rMRGVYV7dl3HB9uHLJm3>
Feedback-ID: ic129442d:Fastmail
Received: by mailuser.phl.internal (Postfix, from userid 501) id 8B7853360079; Wed, 11 Dec 2024 17:54:01 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
MIME-Version: 1.0
Date: Thu, 12 Dec 2024 09:53:41 +1100
From: Martin Thomson <mt@lowentropy.net>
To: tls@ietf.org
Message-Id: <011408f5-9ee8-4974-b616-4dddd398b694@betaapp.fastmail.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-ID-Hash: T35ETPKBG3D7VLGTT6PLGUPRHEP64FAY
X-Message-ID-Hash: T35ETPKBG3D7VLGTT6PLGUPRHEP64FAY
X-MailFrom: mt@lowentropy.net
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
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Should new SSLKEYLOGFILE entries require IETF Review
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/VCCmjU6py0-nbf7fJf0kUK4SPDk>
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>

The current editor's copy of the keylogfile draft says:

> New assignments in the "SSLKEYLOGFILE Labels" registry 
> will be administered by IANA through IETF Review procedure [RFC8126].

I want to ask if we think that this is the right choice.  Generally, we've learned to pick more open registration policies in this working group.

My inclination is to suggest that we pick Specification Required, with a recommendation to experts to reject registrations if the secret can be used to derive other secrets.  For instance, we don't define a label for the resumption secret or any of the secrets that form the main trunk of the key schedule.

I think that's the main reason you would push for IETF Review.  I suggest we codify it, while making the registration more permissive.  And we can always override any rule in an IETF consensus RFC if we really needed to (though we should not).