[TLS]Re: [⚠️] Re: [EXTERNAL] Adoption call for SSLKEYLOG Extension file for ECH
Bob Beck <bbe@google.com> Thu, 25 July 2024 17:54 UTC
Return-Path: <bbe@google.com>
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 46F1DC15106F for <tls@ietfa.amsl.com>; Thu, 25 Jul 2024 10:54:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.605
X-Spam-Level:
X-Spam-Status: No, score=-17.605 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 nKCbnHUfy3yb for <tls@ietfa.amsl.com>; Thu, 25 Jul 2024 10:54:16 -0700 (PDT)
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87CD1C14F689 for <tls@ietf.org>; Thu, 25 Jul 2024 10:54:16 -0700 (PDT)
Received: by mail-qt1-x82f.google.com with SMTP id d75a77b69052e-44e534a1fbeso19511cf.1 for <tls@ietf.org>; Thu, 25 Jul 2024 10:54:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1721930055; x=1722534855; 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=tuDn9BjCcDAGcdu60tn9O0XCDIbI7xlACNqPb7x5JjA=; b=muVsV+6t7alctemGwTBdWXvL4nwPJI3SGsMRcyd5jKEzDYm1Aac8Bq+6U5JGYemCZY BMsxShnRAnRZZuYro+9zjMqXlu7LWzboUhDMHmvlx8fKzId7TfdQMa1CrLE+IYyV/Gqp zQxyFOU3e7Q4sxxeAF3ys03ToGxJSfpP0DQNOT43X4ytk/cHRCpccGOLp29quTUjolRQ 7rrJcAoev9HlMggS/vhuvyyB7wNc4OdkvB+oMv5Y1An+ajOLv8bvU4bj3Tb/zCnhn9Uu drJ3FCmdCnsIUasuzWT3+JAwVsK6JIun8N1fDNgSsWBCZLFY3D/f/8TNW00Xty77iFrS UpuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721930055; x=1722534855; 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=tuDn9BjCcDAGcdu60tn9O0XCDIbI7xlACNqPb7x5JjA=; b=ocuLZSNFE+Jdatm/2+JhQbD4KtTNqWHCqfdEzviS3fYdAgpJhGTg8XpZ/T+U2PHU8n 4UQtrkCuZRn/D5S5w68VjtiJtabqtnna5vBzOCLrp6ALf90I+vmfOJ5m23O+bEScRYoP FHhEGcoGQvk5XrlPD/13YnAnHW6a01zHYCNYt5WrDvOjWzJlXutEoMvr0cOBGffOmJqd TYWxPgvOlxwwNqn/9MPUmLH0Bpe+XA17C/UIZZpybIXk1ELcNmkjcpHCvN4OHHeJgB38 Lcdr7mGpjzrM7vfK6fx3LyPC0gdQFgWCmkndbTW1tmQxFXxc8o/3Ri6N6vmBKMLc42Xn w6hQ==
X-Forwarded-Encrypted: i=1; AJvYcCW6lZ07KWKp2/3HEBtZ8SdPZWqoeeWJTCfkggr3Y5x/kcgzKDF3r/BZOrDLYsC+vHbt4DPJMmbZgvd5CZk=
X-Gm-Message-State: AOJu0Yx5M42nA9GlfSaXUYskEmXkMFhoECEVg7mIM+qcbPVs3+SfTEon FwrElI4By/ip5CzvTJPzC2nGQvMQ2xtY8r6TznmBNyca6/MKvUepeghMbg3nHCNYAL3I1xnASHT Kk6VBlA8pWkACC6PhFcHWoStmo3YP52o02KxRxyapqOOzWMByUf4w
X-Google-Smtp-Source: AGHT+IGBXh2pqK6kXkStg5DxBNdH8p4lyfttGuUad7pB2nF/bg026LPpehKWxL8xGfg5bkArN9f3fdkLApuUUB6ZJdg=
X-Received: by 2002:a05:622a:589:b0:447:d97f:9765 with SMTP id d75a77b69052e-44ff3a94192mr81951cf.16.1721930055035; Thu, 25 Jul 2024 10:54:15 -0700 (PDT)
MIME-Version: 1.0
References: <7CC88431-A71A-455B-A7A7-BA4AD3C8502C@sn3rd.com> <MN0PR21MB3147C2C3EE7B9115F339ADDE8CAB2@MN0PR21MB3147.namprd21.prod.outlook.com> <CAMtubr19E_faBnx47OhXsGZSJ1iiJjkOjRjdfOqiv9OB2ng+UA@mail.gmail.com>
In-Reply-To: <CAMtubr19E_faBnx47OhXsGZSJ1iiJjkOjRjdfOqiv9OB2ng+UA@mail.gmail.com>
From: Bob Beck <bbe@google.com>
Date: Thu, 25 Jul 2024 10:54:04 -0700
Message-ID: <CALA6n3GUeUXX6xhBL6uGiWa2cv=WrWqMND+OYVrvsYR4pfkUdw@mail.gmail.com>
To: Yaroslav Rosomakho <yrosomakho=40zscaler.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="00000000000042991c061e1615cc"
Message-ID-Hash: GRTDYX25JCOMIMUR54455LONGXNTIJPL
X-Message-ID-Hash: GRTDYX25JCOMIMUR54455LONGXNTIJPL
X-MailFrom: bbe@google.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: Andrei Popov <Andrei.Popov=40microsoft.com@dmarc.ietf.org>, TLS List <tls@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [TLS]Re: [⚠️] Re: [EXTERNAL] Adoption call for SSLKEYLOG Extension file for ECH
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/3mzsV0TBiqxOPE0cnFGo4A-LEw4>
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 Thu, Jul 25, 2024 at 10:15 AM Yaroslav Rosomakho <yrosomakho= 40zscaler.com@dmarc.ietf.org> wrote: > Thank you for the feedback, Andrei. > > Yes, it is intended to stay on the informational track as an extension > to draft-ietf-tls-keylogfile-02. We tried to keep wording in line with the > keylogfile draft - for instance in the applicability statement it is worded > that "this mechanism MUST NOT be used in a production system". Happy to add > stronger wording if that helps. > No matter what your opinion on standardizing SSLKEYLOGFILE, https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ does not contain this MUST NOT guidance as in this draft. MUST NOT guidance for only this portion of SSLKEYLOGFILE functionality that is not present for the rest of specification calls into question how an application developer shipping SSLKEYLOGFILE functionality in an application is supposed to follow this guidance. Is only this portion of the functionality supposed to be removed in "production" It seems to me like if this is what the IETF wants to advise, This advice is being given in the wrong draft. -Bob > > The ultimate goal is to simplify adoption of ECH for both developers of > TLS software and implementers. Without a standard approach to > troubleshooting every developer has to build an individual set of bespoke > troubleshooting tools. Ability to inspect ECH negotiation in off the shelf > tools such as Wireshark during development or tests would significantly > help adoption. > > > Best Regards, > Yaroslav > > On Thu, Jul 25, 2024 at 9:31 AM Andrei Popov <Andrei.Popov= > 40microsoft.com@dmarc.ietf.org> wrote: > >> I do not support adoption, because I believe the IETF should not >> standardize tools and techniques for decrypting TLS-protected data. >> It is harder for a TLS implementer to reject requests for IETF-blessed >> functionality. >> >> (As long as this remains on the Informational track, I believe it's >> somewhat less harmful.) >> >> Cheers, >> >> Andrei >> >> -----Original Message----- >> From: Sean Turner <sean@sn3rd.com> >> Sent: Thursday, July 25, 2024 9:16 AM >> To: TLS List <tls@ietf.org> >> Subject: [EXTERNAL] [TLS]Adoption call for SSLKEYLOG Extension file for >> ECH >> >> At the IETF 120 TLS session there was interest in adopting the SSLKEYLOG >> Extension file for ECH I-D ( >> https://datatracker.ietf.org/doc/draft-rosomakho-tls-ech-keylogfile/) >> This message starts a two-weekl call for adoption. If you support adoption >> and are willing to review and contribute text, please send a message to the >> list. If you do not support adoption of this I-D, please send a message to >> the list and indicate why. This call will close on 8 August 2024. >> >> Thanks, >> Sean >> _______________________________________________ >> TLS mailing list -- tls@ietf.org >> To unsubscribe send an email to tls-leave@ietf.org >> >> _______________________________________________ >> TLS mailing list -- tls@ietf.org >> To unsubscribe send an email to tls-leave@ietf.org >> > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-leave@ietf.org >
- [TLS]Adoption call for SSLKEYLOG Extension file f… Sean Turner
- [TLS]Re: [EXTERNAL] Adoption call for SSLKEYLOG E… Andrei Popov
- [TLS]Re: [⚠️] Re: [EXTERNAL] Adoption call for SS… Yaroslav Rosomakho
- [TLS]Re: [⚠️] Re: [EXTERNAL] Adoption call for SS… Bob Beck
- [TLS]Re: [⚠️] Re: [EXTERNAL] Adoption call for SS… Salz, Rich
- [TLS]Re: [⚠️] Re: [EXTERNAL] Adoption call for SS… Steven Valdez
- [TLS]Re: [EXTERNAL] Adoption call for SSLKEYLOG E… Stephen Farrell
- [TLS]Re: [⚠️] Re: [EXTERNAL] Adoption call for SS… Andrei Popov
- [TLS]Re: Adoption call for SSLKEYLOG Extension fi… Christopher Patton
- [TLS]Re: [⚠] Re: [EXTERNAL] Adoption call for SSL… Christian Huitema
- [TLS]Re: [⚠] Re: [EXTERNAL] Adoption call for SSL… Amir Omidi
- [TLS]Re: [⚠] Re: [EXTERNAL] Adoption call for SSL… Salz, Rich
- [TLS]Re: [EXTERNAL] Adoption call for SSLKEYLOG E… hannes.tschofenig
- [TLS]Re: [EXTERNAL] Adoption call for SSLKEYLOG E… Tim Bray
- [TLS]Re: [EXTERNAL] Adoption call for SSLKEYLOG E… Eric Rescorla
- [TLS]Re: [EXTERNAL] Adoption call for SSLKEYLOG E… Stephen Farrell
- [TLS]Re: [EXTERNAL] Adoption call for SSLKEYLOG E… Christian Huitema
- [TLS]Re: [EXTERNAL] Adoption call for SSLKEYLOG E… Ilari Liusvaara
- [TLS]Re: [EXTERNAL] Adoption call for SSLKEYLOG E… Amir Omidi
- [TLS]Re: [EXTERNAL] Adoption call for SSLKEYLOG E… Andrei Popov
- [TLS]Re: Adoption call for SSLKEYLOG Extension fi… Kyle Nekritz
- [TLS]Re: [EXTERNAL] Adoption call for SSLKEYLOG E… Mike Shaver