[TLS] Re: 2nd Working Group Last Call for The SSLKEYLOGFILE Formatfor TLS

Martin Thomson <mt@lowentropy.net> Mon, 24 February 2025 21:54 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: tls@mail2.ietf.org
Delivered-To: tls@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id E4C369F752 for <tls@mail2.ietf.org>; Mon, 24 Feb 2025 13:54:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level:
X-Spam-Status: No, score=-2.799 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_LOW=-0.7, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietfa.org (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b="qb/1+fPs"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="lv/seoj4"
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietfa.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LAu7Fp06cAu for <tls@mail2.ietf.org>; Mon, 24 Feb 2025 13:54:52 -0800 (PST)
Received: from fhigh-a4-smtp.messagingengine.com (fhigh-a4-smtp.messagingengine.com [103.168.172.155]) (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 mail2.ietf.org (Postfix) with ESMTPS id 3464C9F74C for <tls@ietf.org>; Mon, 24 Feb 2025 13:54:52 -0800 (PST)
Received: from phl-compute-03.internal (phl-compute-03.phl.internal [10.202.2.43]) by mailfhigh.phl.internal (Postfix) with ESMTP id EFD991140224; Mon, 24 Feb 2025 16:54:51 -0500 (EST)
Received: from phl-imap-01 ([10.202.2.91]) by phl-compute-03.internal (MEProxy); Mon, 24 Feb 2025 16:54:51 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=cc:cc:content-transfer-encoding:content-type:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:subject:subject:to:to; s=fm2; t=1740434091; x=1740520491; bh=IDT4bxIJB4oPqglWkGQO9ro5qS48TS2t H170WiAGtUg=; b=qb/1+fPsPBwG2FsKBNFZfv6f6NZw+dOBvH3U2HMPSvSvSfKP nylgRHlUdStNa1MBGR2P1BesgbzDl13D2BhfSawyr8pp6kVu1U1th7mv9zE9uSYJ +BJPuP8VYoL+bKmeN12F70GH12pzbu7Z3kGzJltYFvvhVpreGjB/n7eQ9w2FzWAB fDYe1Ml10ExqnJ2+qIYs4XMiTfYJgxNTSLpr/GIxmhn7skGDv9FQZfTbloma1Zcx ezHDVA7/7ELY2WZfKrxUi0ncE614b+6980O5skudHF9nQEHhP4ijvhfFe7pRo7wR zZPFjS0W44xoSdVKINF9xh5qrwrLcuKpxoE3ew==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1740434091; x= 1740520491; bh=IDT4bxIJB4oPqglWkGQO9ro5qS48TS2tH170WiAGtUg=; b=l v/seoj4UGEsg9IU8jyRvA/6+dR/7HLfqs9BE+oK/PzKF1CjUX9OMGBq9tpn/oJzV q92+HwSxbm4RpQWulEKRxRVIRgUu+e4PpnhcxlGrfG9Bjd4vKIfsgSXXWV5M22dK xFeTvgH5DVppsxAlxfV1/eGNtV3Y4zBOH1Mr56y4rVxDZrG7BBlrG22kTi+/m+5P lVG46jj/wa5r6PgPUC7IEPS43yZlXDErsQ3dtGkL/ML9+eu3BiGtd+aN/Bsgo+0Y 5O083LdkdKtiAgwHdBnalfhTlMnFb3Eu5RKCoSaxOA+CH3de+dwDI+8uAXznx6P0 LlurlE1SuvWDQtTodKmbg==
X-ME-Sender: <xms:quq8ZzwcJQDjxJ5c6EsPf0HeWZT-e3G167XbRgHbYIQhDx4sE-_cJQ> <xme:quq8Z7QJcb50xdksAi0SDisFGXz9T1hAAuuFOT_F6B2DgJws98DNnLQJOOx6mZxNj o5GgGISubdlO1YecI0>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdejleelvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenucfjughrpefoggffhffvvefkjghfufgtgfesthejredtredt tdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnth hrohhphidrnhgvtheqnecuggftrfgrthhtvghrnheptddvteejkeegleelleetkeejhfet iedvkefgueejvdevudffhedvfedtveegffdtnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthdpnhgs pghrtghpthhtohepgedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepthhhohhmrg hsrdgsvghllhgvsggruhhmsegrihhsvggtrdhfrhgruhhnhhhofhgvrhdruggvpdhrtghp thhtoheprgiivghtpeegtdgriigvthdrohhrghesughmrghrtgdrihgvthhfrdhorhhgpd hrtghpthhtohepthhlshesihgvthhfrdhorhhgpdhrtghpthhtohephhhkrghrihhosehr vgguhhgrthdrtghomh
X-ME-Proxy: <xmx:quq8Z9UxKaZgEC8bHYbVSlJCCvJdPe4VLbIJc77AAU35soGlFHCIMw> <xmx:quq8Z9gBj61Tf3_lRgsSXr55Izb5qaFlzYOfPmz-jRQJA2v74nCKsA> <xmx:quq8Z1Cd76DM2NWDIkLPLmf9A2rQhxdwKSvHRVigKxUPd0Tz-5PBFw> <xmx:quq8Z2J3ArTHm0NCgKAcnnjGASnh8FhulqnQ1VJHzLBpyCFU5qj5GQ> <xmx:q-q8Z0OnScGYq9vz1esuypuXRQUO5Ibe_SHDiJh0dfq3-jyiZI9L5o7j>
Feedback-ID: ic129442d:Fastmail
Received: by mailuser.phl.internal (Postfix, from userid 501) id 79ED13360079; Mon, 24 Feb 2025 16:54:50 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
MIME-Version: 1.0
X-ThreadId: T028afa6a2e229ade
Date: Tue, 25 Feb 2025 08:54:30 +1100
From: Martin Thomson <mt@lowentropy.net>
To: Aaron Zauner <azet=40azet.org@dmarc.ietf.org>, Hubert Kario <hkario@redhat.com>
Message-Id: <e2b73144-8ccb-4ff8-a32c-2c7aefefc7d1@betaapp.fastmail.com>
In-Reply-To: <CAN8NK9HvfsoePrW9ft_krVtiAV7aYrf4suD52=pQUmG543W-0Q@mail.gmail.com>
References: <6a27cae41645539b3fa90b5f83a8973c73cdd6a0.camel@aisec.fraunhofer.de> <CA+_8xu1nDDHuqRbh2OvRVkvxPyLcJS==rumo3sxPC56NsWLCMw@mail.gmail.com> <93eb1e78c7348459fc92ff874c7e691baf4a0bf0.camel@aisec.fraunhofer.de> <ee908b7b-da13-4840-b70a-84dd66d4bc1f@redhat.com> <2e57a347-cbfc-487c-8b3e-7ee240913ed2@tu-dresden.de> <8fb60e2e-5103-4511-9c97-6b59bae1c5dc@redhat.com> <CAN8NK9HvfsoePrW9ft_krVtiAV7aYrf4suD52=pQUmG543W-0Q@mail.gmail.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-ID-Hash: IZIIGPQYKWHH6TDXO5TB5MSYYKC2FKW3
X-Message-ID-Hash: IZIIGPQYKWHH6TDXO5TB5MSYYKC2FKW3
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
CC: "Bellebaum, Thomas" <thomas.bellebaum@aisec.fraunhofer.de>, tls@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: 2nd Working Group Last Call for The SSLKEYLOGFILE Formatfor TLS
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/UK2Q9oRyeTdOrLvNx32wIn4Tc4g>
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 Tue, Feb 25, 2025, at 06:56, Aaron Zauner wrote:
> To be clear; I agree with that in principle but have the feeling that 
> the discussion around an applicable threat model misses the issue of 
> what should be in IETF and what should be in development docs, 
> debugging tools etc entirely. I'm not currently working on maintaining 
> a crypto lib as many of you are but you can't honestly tell me it's not 
> possible to work on your end without IETF guidance on debug specifics 
> that allow encrypted traffic detail export -- which you already have in 
> place for debug and dev anyway.

This also misses the point.  The existence of this format (it will exist whether the IETF publishes a document or not) has enabled interoperation between a number of tools.  The point of moving this work to the IETF was to transfer governance from what was ad hoc to something recognized and respected by the community of people who build the interoperating tools.

Some people view interoperable standards as somehow changing the demand and availability of the thing they document.  Maybe that's true in some markets, but my experience is that the demand is what causes the creation of standards, not the other way around.  Also, if there were not already interoperation and you were concerned that interoperation would cause problems, this might be problematic, but this is a case where that interoperation already exists.