From arkiver@protonmail.com Thu Jan 4 04:18:56 2024 Return-Path: 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 65C98C14F5F0 for ; Thu, 4 Jan 2024 04:18:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=protonmail.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 LA-C9Fc15k6q for ; Thu, 4 Jan 2024 04:18:52 -0800 (PST) Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch [185.70.40.134]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 333BDC14F69C for ; Thu, 4 Jan 2024 04:18:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1704370729; x=1704629929; bh=uc7sFWiH3lUfylzPdEjsKyB/NEZyIHbXlxou/acwEr0=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=PlWnxBj58/NiGZYeEHafKlaDhB02j/JT9FaJJfP3TfpAmZN6opNXa8IjR32nKTmJl 9O1c61mNEtNpYZ93cEtmbn1wH6OsqUrKZrrPY4TxSPJmk2tKAu4uNa7vSvMM5dHFol Fp8OtwA8e2AGrReznbSkEp8PrmiRoRLDFwJNYRbakHyUwIevFYcqXa1ry46H7gqKXa Nu8P0ptB1azgxh3o22CfWW/gP11BBk5OVEH24Tt/UIZDkAfCXv2VYYDDWEbU938Col RcVzxG9UyMbZmewPekwwO56+yS9+l5Krw5+J3yN5Be3A+pA4zOjoPP47yJPxsM3f00 T1J1fP6ao1+1Q== Date: Thu, 04 Jan 2024 12:18:26 +0000 To: "Salz, Rich" From: arkiver Cc: "tls@ietf.org" , "JustAnotherArchivist (JAA)" Message-ID: In-Reply-To: <1A3A30C7-9680-44ED-AD5E-46F9A90EFF95@akamai.com> References: <2DFA835E-39C1-4644-859A-EC035BB7DF81@akamai.com> <1A3A30C7-9680-44ED-AD5E-46F9A90EFF95@akamai.com> Feedback-ID: 2600247:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Thu, 04 Jan 2024 10:58:14 -0800 Subject: Re: [TLS] Media types "application/tls" and "application/ssl", and URIs for schemes "tls" and "ssl" 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2024 12:18:56 -0000 > Again, think carefully about the data you are recording. Also, TLS1.2 all= ows renegotiation in an active connection to do things like change the ciph= er algorithm, ask the client to send its certificate, and so on. Are you go= ing to record those? Client authentication seems like something important. = And which part are you recording". The client or server side or both? You s= aid "outgoing TLS record" but that's not clear to me. Renegotiation can be = initiated by either side FYI. We would be recording the records send by the client to the servers, and th= ose received by the client from the server. > Are you going to support session resumption, session tickets, pre-shared = keys? Are you going to ensure your client doesn't do any of those? Theoretically we would support archiving all SSL/TLS records, with one cond= ition (copied from previous email): While any TLS records may be stored in the WARC, encrypted content in these= records that needs to be available in decrypted form must be stored in a s= eparate record in decrypted form. If the TLS record does not contain any ot= her data of interest next to what is stored decrypted separately, the TLS r= ecord should not be stored, keeping only the decrypted record. The would prevent any need for storing sensitive keys, and is in line with = storing the HTTP record in decrypted form as is already being done. This also means that in some cases it might make no sense to store the TLS = record as it holds no interesting data next to the data that was stored in = decrypted form. > I read RFC 7595 and looked at the IANA registry. I am fairly confident th= at you will never get the "tls" scheme, so you might want to re-think thing= s a bit. Thank you for checking that, we will think about this.