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

Achim Kraus <achimkraus@gmx.net> Mon, 24 February 2025 11:45 UTC

Return-Path: <achimkraus@gmx.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 DA90543C37 for <tls@mail2.ietf.org>; Mon, 24 Feb 2025 03:45:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.795
X-Spam-Level:
X-Spam-Status: No, score=-2.795 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=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=gmx.net
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 htl4_db1y9Ps for <tls@mail2.ietf.org>; Mon, 24 Feb 2025 03:45:32 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id C56B3422F3 for <tls@ietf.org>; Mon, 24 Feb 2025 03:09:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.net; s=s31663417; t=1740395371; x=1741000171; i=achimkraus@gmx.net; bh=q8blpp5mMRuNz41V91pGP9+ZOLcitjri1YqsvKClcug=; h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:Subject:To: References:From:In-Reply-To:Content-Type: Content-Transfer-Encoding:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=tHH19ld5nqyJ/SSXbx6Ajv1/Gv+sroWEGlMvoPavNggdYv7R3D2DlEVUoX5tw/fh tQafP07flauiBlmuyvZJ/reGfkxlfOxFtmQ/bU8iBGvf7Zvo41578TlZiA6eLX3gr a8w3Wfquj82V/q2OiJl7mZNDfIqo2zVdh4RN5lBLkQI6R/bpKA3phdlWucJpX8898 O/HpIHSQ9zl0oQPdiELkLSTtqYGa868mSkiqZ/7x7KeZ9kLSH3OURSN3XFC6656zQ g9XhH3v3wH/Q980gTwgZWamulIK+M3YXqjB+wVKj71BoXpA8/6sI3RNn4DlFpnsTZ CDYONDumUsPpUsnN3w==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.178.10] ([5.146.193.180]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MuDXp-1tRxa72RIL-017hLS for <tls@ietf.org>; Mon, 24 Feb 2025 11:03:26 +0100
Message-ID: <c7b7eafb-dab8-499b-8e54-2ad797ad1bd4@gmx.net>
Date: Mon, 24 Feb 2025 11:03:26 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: tls@ietf.org
References: <EB37B761-8575-43E4-AAE7-0FA301BC066D@azet.org>
Content-Language: de-AT-frami, en-US
From: Achim Kraus <achimkraus@gmx.net>
In-Reply-To: <EB37B761-8575-43E4-AAE7-0FA301BC066D@azet.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: base64
X-Provags-ID: V03:K1:6ufOGgkN9yr4u1Cbejqwy3CNKH1UqaIXvQU2Ed0jyvpkR5uRBml yzJz1UEWitkWdnid7zLNskpliHBxcmutt9580T03b44VKCuwQppQUaQ36zOxJLNj/awChLJ gPi8mkyFpHLUZQsU2yVw9ymycTQoW5Gwr9fIlwmcAXx8W+2deDGFI0/SGz6i0wnYlni6NiP +32XsIPlRtxwpyMd/vWiA==
UI-OutboundReport: notjunk:1;M01:P0:yYGCZDyi7sk=;fKTnNtqY2V9diXJzXKXybGrXP39 P12NOZ/zsHJQP8pCGoabA2M/yR0d8S/bikGZ2CdThXIEf2s0GA2LM9+hFWMrQex0jYY63fTwO AaNgDTvTM097iHNKAhCuDMtUjUg3caIV5zKK1nn8Da5EaOXOxIbaR31LrE/Li+KeBtHlnlKKS wpBl4WmJ8R/CO4VN5to7NJnXvS8e2HWasnwVNtZztmZj1cWLb9YAbpTggH2ViYSZZzKDDgel+ 5/erEjLN6f2dNlGTFA/G7hZv9CXY7lf32yvNbPP01J4tDsaA1mJ/xu5qKOv0/UWfgiDX+uvrR cgedZwd3qHOfA5L2tdVd+HRwxOAXMYj+0rMY+oUo9FW10DTyzSXDqScio030NI33sjnVKqrSU kj0AqOKLCW5OusRI8K7JtcwQiB2UHziFyQWAlorW+PcYvWD0hU9Vw2FWdRPjRLOJtomxrVXRq CCQonPNXZFKt31NCR4YgjYEtYT1nc5u3CZyHu11JfNLeyU9oGLS5gBklD5s9SJh1Ix4R+2Rvp T7tnNuee8NVOq5RYU/Hc4iacms0KL1iIzDxcdJLGXDmLHHE2SycBLIilGlxHbNsKmKEjJGH9f MdIVj/OEy57c8TKZ7RKtzD9qDiv17O/bHaH8ixld6+2/AP2001Y7VPOo1idSiGxjY9W9dbOwL kHqUGexCQDP301lpihP7OyOkfzbr7XliBW03fjLh0gJwV+eDRJ+TvfRme6qrDX0zBoUzRHVTt 9GyFFw+2KVkdAXWzAwhx3Jdaas9AD6N2bpv9ozBlVP3D+v5gauxyRzBGmfIli86iy5HVechnf E5B+ZhZZvEso6KTpEWadE7uoeVbv13pstJ/xiS8VXm7r0ObL1bU+ZSQYA1N5xu+8LPiYSCmQo OSeJNyvxPqZn5Y9z6LdH7gHjsYlqcvNOStroPiBALUdFApBwytl9BXCq7zOgic64ThbPLCzO/ Sc1Hln+L2g5iTfTdn921C+WyhK3K/n0lpK7PK8izRwehF68O7plGYCk/Ng0EMGntjiZYdsZv1 ZLXKDvMLLO5BCuh/ZwTke44ApRL5y8/BG5L6FKe1OIa8iaqzb7/1JUOmau4fw/89rk1OiS8Zd H4ob5LDT2+bcgRq2QiR4LW8dFMk5tur5rS4eGmpfDhtypzOIRWatiIMOWlBqcO3G0+JqOABz7 RWqcGFA1/hdyk3r6zoGwmZgxlKlMCxw43Unbg6w8bIiLebiaMsPwyFQrvADRfDd9PnAZMlqoN kk+GZjsl56ZixOkjwLcRv+mqmMUbC5fhc267cqtfIkhOMORYV29FtReW2w6zDs1U2Id9JcQkG L0JNC41u0YAi6Fp9/WQDW6qTdFPagtVDdqrvy6TEO6a7bYo9KapWs7ByOl0O+6lnAAl7iA0bE CtZdZP8/HquUx9orOBUPZeZUM5OPDQZ9Sp/b4O/KA9RlstHDCMu8fK5uuP
Message-ID-Hash: 6BBNYGCNM4IJHX5SMYZLGHTIZQ4XCYAE
X-Message-ID-Hash: 6BBNYGCNM4IJHX5SMYZLGHTIZQ4XCYAE
X-MailFrom: achimkraus@gmx.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] 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/ek3gnmFDMyD4CWP3iw_r_g0bpSo>
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>

Hi List,

In my experience, this is mainly use to feed the "TlsKeyLog" from some
application into wireshark. And it's curious to me, that not having a
specified format within the IETF/TLS will provide any security.

For me this sounds more like,

"we know it's done, but we don't want to be aware of it"

(In my case (new function in Eclipse/Californium 4.0.0-M3) it helps
people to debug their CoAP traffic regardless of the used DTLS
cipher suite and without exchanging credentials ahead.)

br
Achim


Am 24.02.25 um 06:00 schrieb Aaron Zauner (azet):
> Hi,
> 
> I haven't been active on IETF lists in a while but would also like to state my clear intention not to have any feature as such standardized. As has been discussed and pointed out in this thread repeatedly: this *is* already and can always be a (preferably) default disabled implementation specific feature. Any standardization and proliferation of features like these will cause maybe otherwise unintended harm towards unsuspecting end users. It took many in the community years past 2013 to disable, compile-out/redact or otherwise remove many of the previously enormous amount of options some Linux and Unix flavors distributed open source crypto libs or network services for that enabled users to make stupid, unreflected decisions when configuring otherwise standard network services like http or smtp/imap etc.: from RNG inputs to DH params and exponent files. As far as I know on eg. AIX even today OpenSSH still builds in the most peculiar ways. But otherwise on most modern production distributions and end user / development focused operating systems and programming languages this has been ironed out over long discussions, amendments to man pages and a complete Linux kernel RNG redesign. Please let's not do this all over again. it's just another easy entry point for supply chain attacks or might serve as a rationale for vendors like pegasus that their intentions are really ours as long as they are under LI / gov contract no matter what's the end result.
> 
> All the best,
> Aaron Zauner
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org