[TLS] Re: 2nd Working Group Last Call for The SSLKEYLOGFILE Formatfor TLS
Aaron Zauner <azet@azet.org> Mon, 24 February 2025 22:27 UTC
Return-Path: <azet@azet.org>
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 E9B1CA2412 for <tls@mail2.ietf.org>; Mon, 24 Feb 2025 14:27:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=azet-org.20230601.gappssmtp.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 EJM_ywVgrM5Z for <tls@mail2.ietf.org>; Mon, 24 Feb 2025 14:27:23 -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 9B1EDA23F7 for <tls@ietf.org>; Mon, 24 Feb 2025 14:27:23 -0800 (PST)
Received: by mail-yw1-x112a.google.com with SMTP id 00721157ae682-6efe4e3d698so45071097b3.0 for <tls@ietf.org>; Mon, 24 Feb 2025 14:27:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet-org.20230601.gappssmtp.com; s=20230601; t=1740436043; x=1741040843; 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=bAQsCKUZrzbOm1nCfql+5GSymXrSjMhMR51+v4JxjZk=; b=R4njoSppo8Gv7x2SKxdIoDQDWAi/8VRdS2tjd7l2ejk1QdrCMtBiFqTHOFLDjLUh0T KqXLgJ2WrxGpJ9PP+l96RiqY1TNa3WzYx221I1j5vjXr4ZNEPkZae72DHdOXUHBT+Jmi P0oasLj7daRnbIv8+GfeQ1iT1unYkXhv8xTRg0E+Yaz54Yo+XgBvrW//OP7miUJJ3uB8 DiG1EUSCiKnYUhSLVGo1iNZ8GYhUEmKIvQ/fU1HiPSJtBHGFxwABKTKGm7kq6dR8Jj/j UIl5dQh33Inks6u6MaXpzMU7yFd0CrINFlUurRQpG47zdw81eab+Vr/Y7++XfZJtBLZW cs7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740436043; x=1741040843; 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=bAQsCKUZrzbOm1nCfql+5GSymXrSjMhMR51+v4JxjZk=; b=K2l3W952ecEArvFxl5XcihBMekW3rFQNEwShQT2Rp1wRr+NcmAlzUYH27l+HHPEW1a eLBMYiCyJr6JvlLHtC9wAo4o0f0JdD5S/gv39t+wYZVWBD4MvwjdAeIVpXEmEPuq3o9Z H3DGijZDsNVp1b2p+1VFL7Q54HuK/sGbrrRVF+axwimVisXKfzdwGX1yzdYZuDbopUAy 07ivZJOoJTyaIX9vk8R4M7EIGYy7kR7LwnIYBWbeNPYYstQW+PZKvrwJPYODzeFgLqdI 9n88z2vi1syPsT1zrc8QC/SzH+WUHETDEwPVZKWuPI7GOC0q7L/ImdWRLXPwMnEqheZs ugog==
X-Forwarded-Encrypted: i=1; AJvYcCVAa1xiXP7G9hoUq7oUmOmnkDaEUjiBAUY2lwqxD/HJZR8C7d9ciMdX3YHDrH6aIqOnBXc=@ietf.org
X-Gm-Message-State: AOJu0Yy0hfDGnreuzSO+y03L1f2Ui/2ltNrKP/X0ZmWM7sBCF9kAf5RF 92nsECa026J5MxRf7bvPMwv/WuexnFw7glJ3iRubmS7/+2qQeaETuFBc3oj7cRVRuK2lDg4AblN 5KshAoxyz3jxmdM3dc5CqNf3l6o+6G+e7hYTa
X-Gm-Gg: ASbGncvL1uLgAoT7Ldjh5DfGo65Srsdc9HvpwVZcwAqQ+eun1JNKUs+07pEKCmW7lGh tfrSQGWaY4tc8/8mgFQz3J6GT98iV0UfI6afAhS5D+7KKR7sE92xN9moqVbJibkp3ZvjDp8apss 6y+Ke63Vv+pnPByziqIF1ZTELkbswWJ0yVRvDO
X-Google-Smtp-Source: AGHT+IGqRx1U3XfwUgUlXnP4mUAEiOLhEAmmByniOx7YVPqVIO0LgZLVrVsmYPXINQtGwMJIDlF8vAq4av2V9QGoPoo=
X-Received: by 2002:a05:690c:6310:b0:6fb:968b:d8f5 with SMTP id 00721157ae682-6fbcc3a43b2mr128811597b3.36.1740436043122; Mon, 24 Feb 2025 14:27:23 -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: Aaron Zauner <azet@azet.org>
Date: Mon, 24 Feb 2025 23:27:11 +0100
X-Gm-Features: AWEUYZlOXdI1pYAoHvKSmouYqbt9zafxZgrHaaln-5E9p1e6C9U1fWDzpGqYMew
Message-ID: <CAN8NK9GhzyfjE3-pEJfTqDMDvo98v9EcW3ZZKea_YZVid-RJow@mail.gmail.com>
To: Martin Thomson <mt@lowentropy.net>
Content-Type: multipart/alternative; boundary="0000000000001aed8c062eead863"
Message-ID-Hash: T7TYKFV3ZZQA5WEHHYTSR5DLESKLH5AG
X-Message-ID-Hash: T7TYKFV3ZZQA5WEHHYTSR5DLESKLH5AG
X-MailFrom: azet@azet.org
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/OyCO2g_2_TmZ-Y7CLZj0u2-SOVc>
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>
Hey, On Mon 24. Feb 2025 at 22:54, 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 I understand your point and just like config formats I see why you'd want to have a published document. But just like with configs it's part of the local tool chain and not a wire format. Open source projects have been able to work with them and use them without involving IETF. I'm just not sure this is the right place for the document. You've done the work and documentation anyway already, and you're interoperable. What do you really gain by having this in IETF? It's also a fringe topic; With that I mean in this case that it's debug specific to a few projects related to TLS and while this is the TLS WG it's still a tooling issue in my estimate. I'm really not sure what the big upside is of having it published here. A lot of chrome, openssl and other tool chain specifics are likewise only documented in the relevant project documents and it works fine for everyone involved; Is there any precedent that showed we need this in IETF - ie. where interop and debugging didn't work out because you couldn't already agree on a format and document it? Because it seems to me the community has already achieved all of this due to your and other people's contribution without adding it as an IETF doc. Thanks, Aaron >
- [TLS] 2nd Working Group Last Call for The SSLKEYL… Sean Turner
- [TLS] Re: 2nd Working Group Last Call for The SSL… Salz, Rich
- [TLS] Re: 2nd Working Group Last Call for The SSL… David Benjamin
- [TLS] Re: 2nd Working Group Last Call for The SSL… Salz, Rich
- [TLS] Re: 2nd Working Group Last Call for The SSL… David Benjamin
- [TLS] Re: 2nd Working Group Last Call for The SSL… David Benjamin
- [TLS] Re: 2nd Working Group Last Call for The SSL… Salz, Rich
- [TLS] Re: 2nd Working Group Last Call for The SSL… Sean Turner
- [TLS] Re: 2nd Working Group Last Call for The SSL… Salz, Rich
- [TLS] Re: 2nd Working Group Last Call for The SSL… David Benjamin
- [TLS] Re: 2nd Working Group Last Call for The SSL… Stephen Farrell
- [TLS] Re: 2nd Working Group Last Call for The SSL… Bellebaum, Thomas
- [TLS] Re: 2nd Working Group Last Call for The SSL… Ben Smyth
- [TLS] Re: 2nd Working Group Last Call for The SSL… Bellebaum, Thomas
- [TLS] Re: 2nd Working Group Last Call for The SSL… Stephen Farrell
- [TLS] Re: 2nd Working Group Last Call for The SSL… Salz, Rich
- [TLS] Re: 2nd Working Group Last Call for The SSL… Bellebaum, Thomas
- [TLS] Re: 2nd Working Group Last Call for The SSL… Ben Smyth
- [TLS] Re: 2nd Working Group Last Call for The SSL… Bellebaum, Thomas
- [TLS] Re: 2nd Working Group Last Call for The SSL… Andrei Popov
- [TLS] Re: 2nd Working Group Last Call for The SSL… _ _
- [TLS] Re: 2nd Working Group Last Call for The SSL… Martin Thomson
- [TLS] Re: 2nd Working Group Last Call for The SSL… Stephen Farrell
- [TLS] Re: 2nd Working Group Last Call for The SSL… David Adrian
- [TLS] Re: 2nd Working Group Last Call for The SSL… Alicja Kario
- [TLS] Re: 2nd Working Group Last Call for The SSL… Muhammad Usama Sardar
- [TLS] Re: 2nd Working Group Last Call for The SSL… Aaron Zauner (azet)
- [TLS] Re: 2nd Working Group Last Call for The SSL… Arnaud Taddei
- [TLS] Re: 2nd Working Group Last Call for The SSL… Achim Kraus
- [TLS] Re: 2nd Working Group Last Call for The SSL… S Moonesamy
- [TLS] Re: 2nd Working Group Last Call for The SSL… Alicja Kario
- [TLS] Re: 2nd Working Group Last Call for The SSL… Alicja Kario
- [TLS] Re: 2nd Working Group Last Call for The SSL… Aaron Zauner
- [TLS] Re: 2nd Working Group Last Call for The SSL… Arnaud Taddei
- [TLS] Re: 2nd Working Group Last Call for The SSL… Stephen Farrell
- [TLS] Re: 2nd Working Group Last Call for The SSL… Arnaud Taddei
- [TLS] Re: 2nd Working Group Last Call for The SSL… Ben Smyth
- [TLS] Re: 2nd Working Group Last Call for The SSL… Sean Turner
- [TLS] Re: 2nd Working Group Last Call for The SSL… Christian Huitema
- [TLS] Re: 2nd Working Group Last Call for The SSL… Bellebaum, Thomas
- [TLS] Re: 2nd Working Group Last Call for The SSL… Aaron Zauner
- [TLS] Re: 2nd Working Group Last Call for The SSL… Martin Thomson
- [TLS] Re: 2nd Working Group Last Call for The SSL… Aaron Zauner
- [TLS] Re: 2nd Working Group Last Call for The SSL… Arnaud Taddei
- [TLS] Re: [EXTERNAL] Re: 2nd Working Group Last C… Yaakov Stein
- [TLS] Re: [EXTERNAL] Re: 2nd Working Group Last C… Andrei Popov
- [TLS] Re: [EXTERNAL] 2nd Working Group Last Call … Alicja Kario
- [TLS] Re: 2nd Working Group Last Call for The SSL… Salz, Rich
- [TLS] Re: 2nd Working Group Last Call for The SSL… Ilari Liusvaara