IETF Logo Mail Archive

Re: [TLS] Working Group Last Call for SSLKEYLOG File

Eric Rescorla <ekr@rtfm.com> Tue, 12 March 2024 23:08 UTC

Return-Path: <ekr@rtfm.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 CB8EBC14F5EC for <tls@ietfa.amsl.com>; Tue, 12 Mar 2024 16:08:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20230601.gappssmtp.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 HkaEy9TeukPJ for <tls@ietfa.amsl.com>; Tue, 12 Mar 2024 16:08:22 -0700 (PDT)
Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) (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 3F296C14F6B5 for <tls@ietf.org>; Tue, 12 Mar 2024 16:08:22 -0700 (PDT)
Received: by mail-yb1-xb30.google.com with SMTP id 3f1490d57ef6-dcbc00f6c04so4327096276.3 for <tls@ietf.org>; Tue, 12 Mar 2024 16:08:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20230601.gappssmtp.com; s=20230601; t=1710284901; x=1710889701; 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=ihNsVdFtZUnQkq8d0UgsPCkhZLZqMN2AaXkt2hrpvv0=; b=a+t3VRHrqJ5crq19p2XenZZedQxQRFXT80rPz9Vv64+QZDg7lOp7UT0AlRuGAyFSXr DZjxxH2lzgEZUmgF756iLfhQzI5r1ltHqpI9Zqr8ciEKEK9tq+33Fdy4IiLakbvKwlXh VMubHi1nj2o15hmeif5SIKUab11HpH3s2JqIGMfdOXQWPm11BWneQG1FH8YgmqPj7RX5 shhGEq7mHWpYDTQJyRK5aHN9L9cWnrSp1Zrp8TGuprywHkEZN28Bt8/qwvscx1tnKEfx AkNBeDcjIrRKPemd0Mh59FHZEkRyepHjUT7PN/JZiv9oSh5aNl6XuyYt1IWRM1OiP/jA wxLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710284901; x=1710889701; 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=ihNsVdFtZUnQkq8d0UgsPCkhZLZqMN2AaXkt2hrpvv0=; b=E/QbrfF9gRv0DAhVUt/4+1jRMhKs+6uZpBiZRTi7LVPQCrB4bVbnl27eD0X3lqXtJd rn2KyXjVvefMbMT2q7LiB1RfW128/3ONpYj1aNZNwtNKXidKR4cYiSZmmu0UPw2e0AnE TnW8NOb5SDTcfvcQcn4/MNBT1oUqBtptIPDxC31EnCgbDb6MKlWZpfDJJddyu7cCJZNj lU+EVYBFdwyybPnj8itSkOzMjKJ/jMkTl5Amm6OYf+NQrIT+u7gDTck8L9WrLhoRoGty 6Ai3xwoV/QN0mZHaUFRayXpN7W6SZ3TPc1Vhnkqqq/DjFCVy7tTb/vQdLd63hotb2YWN UW5w==
X-Forwarded-Encrypted: i=1; AJvYcCWvZUPAlqOiLPRyaH/CK9RULiXp6BDdZWNi3U5EvWWaaZ2wuO6SJNa05zXjbKpSTDHUouj1qC4Ar6ztiqI=
X-Gm-Message-State: AOJu0Yxda2ZDhf0TEyUmVL65zAHD67nYfFSx4cqtOL8XlW2n98XSWOs8 JyQIPccCrSGMZJGir7WvpuHAGa8h4OkdtCiVoHs6+cQPZimAxvA8vKBQrKmeppJw2W+eVMwvAjJ 6HPcRpHT0OkgvHUxPvmo64nwW0Ny9ab9pxe3eUvD8DpwGXxvI
X-Google-Smtp-Source: AGHT+IFwIU5PF0072i9ocLPkW/8TpeZCY24aylihTK3Q/e/e85eFLePoENMpSOQBW6xzHmFwj5foqAVOFR3TTA/CHn4=
X-Received: by 2002:a25:aae6:0:b0:dcd:ef35:91d5 with SMTP id t93-20020a25aae6000000b00dcdef3591d5mr865990ybi.2.1710284901209; Tue, 12 Mar 2024 16:08:21 -0700 (PDT)
MIME-Version: 1.0
References: <01AF00B4-F9A5-4A25-A6CB-E1D84CF8D11F@sn3rd.com> <cb4d17c5-b2ce-458c-b14f-9882951d2528@cs.tcd.ie> <5027880d-bf70-42e4-8974-7c148db5d737@betaapp.fastmail.com> <f1f0cce1-7d10-442e-b27e-235912b2a4af@cs.tcd.ie>
In-Reply-To: <f1f0cce1-7d10-442e-b27e-235912b2a4af@cs.tcd.ie>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 12 Mar 2024 16:07:45 -0700
Message-ID: <CABcZeBNjEZP1E5mVtcby500_vDBP=omzoeVgDoXcrY_JMYadsg@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Martin Thomson <mt@lowentropy.net>, Sean Turner <sean@sn3rd.com>, TLS List <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000000759106137ebc0b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/w9ZBRRg6loudJFCPUYmBG1hYFn0>
Subject: Re: [TLS] Working Group Last Call for SSLKEYLOG File
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Mar 2024 23:08:22 -0000

On Tue, Mar 12, 2024 at 4:04 PM Stephen Farrell <stephen.farrell@cs.tcd.ie>
wrote:

>
> I'll argue just a little more then shut up...
>
> On 12/03/2024 22:55, Martin Thomson wrote:
> >
> >> Sorry also for a late suggestion, but how'd we feel about adding
> >> some text like this to 1.1?
> >>
> >> "An implementation, esp. a server, emitting a log file such as this
> >> in a production environment where the TLS clients are unaware that
> >> logging is happening, could fall afoul of regulatory requirements
> >> to protect client data using state-of-the-art mechanisms."
>
> > I agree with Ekr.  That risk is not appreciably changed by the
> > existence of a definition for a file format.
> I totally do consider our documenting this format increases
> the risk that production systems have such logging enabled,
> despite our saying "MUST NOT." So if there's a way to further
> disincentivise doing that, by even obliquely referring to
> potential negative consequences of doing so, then I'd be for
> doing that.


Aside from this particular case, I don't think technical specifications
should "obliquely" refer to things. Technical specifications should be
clear.

-Ekr

Hence my suggestion.
>
> S.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

v2.23.0 | Report a Bug | By Email