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

Arnaud Taddei <arnaud.taddei@broadcom.com> Tue, 25 February 2025 09:22 UTC

Return-Path: <arnaud.taddei@broadcom.com>
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 46D6CDE5D2 for <tls@mail2.ietf.org>; Tue, 25 Feb 2025 01:22:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.539
X-Spam-Level:
X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.442, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietfa.org (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.com
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 YabFaLg3s-v5 for <tls@mail2.ietf.org>; Tue, 25 Feb 2025 01:22:53 -0800 (PST)
Received: from mail-yw1-x112a.google.com (mail-yw1-x112a.google.com [IPv6:2607:f8b0:4864:20::112a]) (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 mail2.ietf.org (Postfix) with ESMTPS id 8CF89DE5BA for <tls@ietf.org>; Tue, 25 Feb 2025 01:22:53 -0800 (PST)
Received: by mail-yw1-x112a.google.com with SMTP id 00721157ae682-6f9625c0fccso46126057b3.1 for <tls@ietf.org>; Tue, 25 Feb 2025 01:22:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; t=1740475373; x=1741080173; 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=z4Ds0gXMIu4FBVHJ3ThS3RP5ky8+emO12TVLU7PHY7M=; b=eWpy/D24gxMXhsSMrvgNLVGYDuWjZTZZMDc5Yt9zTRx1Yjg0ckyH6+DiBsYkjTUYIK eb3HcubOLojdzW+FzPik95NcRk2I+Yl8ZZU+4fQD+U4d4N73JHb3asyPeI/4T7lKFBJq qAeUADffeb3XBVTYq2LzGiRGSMZzSVMTskHeg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740475373; x=1741080173; 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=z4Ds0gXMIu4FBVHJ3ThS3RP5ky8+emO12TVLU7PHY7M=; b=rNDPfOsjv+YjSj3O3BgwWv9/L8t8lHm/ME8IWSHZdraK/PLLPg3nN5wTISdhHy6yL5 fQIe64YMWEn4pBXNcoXZa6FQdG6Nt30M0dK+Jq6ujy5+ROaSdhXtU4OyiqRKIYCAity9 w5Hs15/UvlL3xwPLAWKgjRo2Bh4lFoPdrgFostdc7TuKvv3PKL0a6/La99lY6Rlx6UN3 3rrU3ktrhKjMg12KmpU/Rw72e9HKDxJAUzmPejbICqw2hRgUbbTozF5my46/jjf+TlN1 0KeCrPGFX/chpJmZJog8phAtyN7OAAEX1orbrHukTwFv9nr7N5pcmNsWckHWGNJWFEF/ VjfA==
X-Forwarded-Encrypted: i=1; AJvYcCXlOCSB/08lif6yejnpA4E5IDY6nkTDSuINtVbV1tePbVh/8OPmpkMTG+RV7U5nxThRtAQ=@ietf.org
X-Gm-Message-State: AOJu0YyU+aIycGSZhJUGFu04JqwqXFQ0RcDaJ/FqOlBBJhEAyTQcOwyu 60ZXX+SbMydnUUI9WTg4aHHP7L0672SLsaSZNvN+NIbcClF9hgTJOurBWJLPxYj1mKe3SVI+Wd/ 9xckNi1fv6cZj+A5ysAmK8Yfd20L+8NnjettH/2SXUGjshEO95hO24xUJNzxOX7yugnBeXcTj2l BO3TD3
X-Gm-Gg: ASbGnctaO+hysqY9izGrfuRpbFVIPuK8ckLoKgkvnzyPE8Z+ImZdqpp9SdWrInsKG+p nLb9OQqC2l3xvGmCBBSu5reMSyoKSdpGNhnWHChmks31MZBL8NCsVV3HkJmQx5zq2etMZQRiStS zmqSeC7P8=
X-Google-Smtp-Source: AGHT+IHAoj98iZe1n106Xl3oGFY2AIG5GAJf1OnwpoMXp3NEaCoKKFsld+OYp8OsVJYZiSZHgiHl4obH0JnvY4hnKHk=
X-Received: by 2002:a05:6902:1201:b0:e58:493c:e9c0 with SMTP id 3f1490d57ef6-e607a4f9f0bmr1958620276.22.1740475373003; Tue, 25 Feb 2025 01:22:53 -0800 (PST)
MIME-Version: 1.0
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> <e2b73144-8ccb-4ff8-a32c-2c7aefefc7d1@betaapp.fastmail.com>
In-Reply-To: <e2b73144-8ccb-4ff8-a32c-2c7aefefc7d1@betaapp.fastmail.com>
From: Arnaud Taddei <arnaud.taddei@broadcom.com>
Date: Tue, 25 Feb 2025 10:22:40 +0100
X-Gm-Features: AWEUYZl3kpDUBl0MlTc4B5xsfA--hP3FyCesDjgjlKIi1-g7nUraNw7A4LM8kCE
Message-ID: <CAMTNNNcq8cG+4SOj=zeJCCOL8SZr20ZpZOD=iz+iuZW31k4-Ag@mail.gmail.com>
To: Martin Thomson <mt@lowentropy.net>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="0000000000005dc522062ef400c2"
Message-ID-Hash: TN7M6C7KU2RCQTZ5LIHLCGFLNWJX77RU
X-Message-ID-Hash: TN7M6C7KU2RCQTZ5LIHLCGFLNWJX77RU
X-MailFrom: arnaud.taddei@broadcom.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: Aaron Zauner <azet=40azet.org@dmarc.ietf.org>, "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/TXi0AZZs8VQNkpO7EUPUfEsdGC8>
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>

+1

Arnaud Taddei

Global Security Strategist | Enterprise Security Group | ITU-T SG17 chair

mobile: +41 79 506 1129

Geneva, Switzerland

arnaud.taddei@broadcom.com | broadcom.com


On Mon, Feb 24, 2025 at 10:55 PM Martin Thomson <mt@lowentropy.net> wrote:

> 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.
>
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org
>

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.