IETF Logo Mail Archive

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

Eric Rescorla <ekr@rtfm.com> Tue, 12 March 2024 22:06 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 C160EC14F6B3 for <tls@ietfa.amsl.com>; Tue, 12 Mar 2024 15:06:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level:
X-Spam-Status: No, score=-6.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_HI=-5, 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 i7eeS6Kp453J for <tls@ietfa.amsl.com>; Tue, 12 Mar 2024 15:06:38 -0700 (PDT)
Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) (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 D481AC14F690 for <tls@ietf.org>; Tue, 12 Mar 2024 15:06:38 -0700 (PDT)
Received: by mail-yb1-xb29.google.com with SMTP id 3f1490d57ef6-dbed179f0faso248690276.1 for <tls@ietf.org>; Tue, 12 Mar 2024 15:06:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20230601.gappssmtp.com; s=20230601; t=1710281197; x=1710885997; 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=ojZIdcWVldDc14Rb521ptJXLJ30g+P1Ycy66XB/mXTs=; b=bP7apFArqLwEVQH0r5ZXvyF2TJf7bnLfhucCV97zmd3U6i/CCbgogqrLoJbzUtQm7P Hm/dB6GgvXKxMCSeTg6W8wIzwIvS/oDpiRzt2Iy427sbM+99QzcwLyETPngd8JGe/sjG i/jw2g5DDuSj/IebepgDNe2RAAPSjJYcgbMspqUMxeU3liXL7sYxy9z14kyOBkLTXvMT /ygS24+6nAAjoWQ8jpysDxVnc5zmdHzyq1xYnzHwJLl3l01RqZJQu+ab8dKv30ZN5v9n Yvr+EHLsIGo3pqzHJNPz4kGxqA4RrMNiXHESMMbuaz4nn4b0QBfWT68Mg9Kws13kmQ7V RTrw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710281197; x=1710885997; 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=ojZIdcWVldDc14Rb521ptJXLJ30g+P1Ycy66XB/mXTs=; b=XHNQSZYsKzOScCf1LC1LLm1ZqMLAiTz13Z72zDDULhJ2a4JVJ8OAXN+unpQbRohmO6 Ze215tQCXDSrzNxsbCUEUOt5BAlZNdYXBn7IYrxtHlzHQg6cSXXabQpjwG2gHaoPmxdy tvVW+6nugcjdT9RH7pLFUkftFxCgZRDEVgF/Sk1/28438gj6v6KNeN8Xi+czUt0iKTPg nnsR0YAFPY6uof2T29o/Jl0hzIE5g8GmchM8NZxBOt2flvuOIx0YsWcD+CZFZNCZScf/ ps+lOKPfbKGY/JgA1A+6DvU0HGsF08kzGTOFXvi8TLWJwFP0yZKFr74dV25V/04F4sl+ b3fw==
X-Forwarded-Encrypted: i=1; AJvYcCXOvqEuBmCmx1x+BLL1DdMtvRNVdXSWheOPVX753LvEcDDvoohlPlUP3zyfB1clas3GyPn9n3vYpRAjCfg=
X-Gm-Message-State: AOJu0YzA+7wvSAcR5sraveWLm2zsiSBa3pc5jY61V9TjaJKxH+5A1r+Z TQs1eF0BldWmUYxSxzD0AjnzpZd/ffS+PU1XCtnnoFwvveNac9bE3hzFVvr5IjDkGemN1q0ISVn mK9IJkStzuOD4V+4SwA0g3mbvBX0dfpRL7Dnt67X0rCve+6C1
X-Google-Smtp-Source: AGHT+IFfpFlQJo/o8g+43bmZtznvpMhyL/sUsZybKtogoyiVXrhBOYzz596DtbcOu+DB3GoUOG09CGhw0Y9vsA9jQMk=
X-Received: by 2002:a0d:db54:0:b0:609:840c:4d2 with SMTP id d81-20020a0ddb54000000b00609840c04d2mr504183ywe.14.1710281197513; Tue, 12 Mar 2024 15:06:37 -0700 (PDT)
MIME-Version: 1.0
References: <01AF00B4-F9A5-4A25-A6CB-E1D84CF8D11F@sn3rd.com> <cb4d17c5-b2ce-458c-b14f-9882951d2528@cs.tcd.ie>
In-Reply-To: <cb4d17c5-b2ce-458c-b14f-9882951d2528@cs.tcd.ie>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 12 Mar 2024 15:06:00 -0700
Message-ID: <CABcZeBPX6g=MhvaVHZ5ThpctWCbD5dN1wq98DsW2btm7B0K5Xg@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Sean Turner <sean@sn3rd.com>, TLS List <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003e884106137ddf37"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/zIb-yV8Fkr01GvcWJNnWnLnvl9w>
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 22:06:42 -0000

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

>
> Hiya,
>
> On 12/03/2024 14:57, Sean Turner wrote:
> > This is the working group last call for the SSLKEYLOGFILE Format for
> > TLS Internet-Draft [1]. Please indicate if you think the I-D is ready
> > to progress to the IESG and send any comments to the list by 31 March
> > 2024.
>
> This is not my fav thing, but I guess I've also benefited from
> it during development, so with a bit of nose-holding, I suppose
> it's ready. (Apologies to Martin for the grudging acceptance of
> his worthy effort;-)
>
> 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 don't think we should make statements about regulatory requirements
in this kind of specification. That's not our lane.

-Ekr


> Another thought occurred to me that I don't recall being mentioned
> before: given we're defining a mime type, that suggests sending
> these files by mail or in an HTTP response. Doing that could
> be leaky, esp. if only one side of the TLS connection reflected in
> the file were aware that logging was being done and if the other
> side then sends the file via unencrypted email. I guess one
> could also envisage a weird case where a server did this and
> also located the log file inside the DocRoot enabling some
> clients to see the secrets of some other clients (or their own).
> I'm not sure if either scenario, or any similar scenario justifies
> an additional warning to be careful where you send files using
> that mime type? If it seems worth including, grand. If not, that's
> ok.
>
> Cheers,
> S.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

v2.23.0 | Report a Bug | By Email