From nobody Wed Jul 12 04:32:12 2023 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 04CB1C151AFC for ; Wed, 12 Jul 2023 04:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.095 X-Spam-Level: X-Spam-Status: No, score=-7.095 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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=dennis-jackson.uk 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 xlqDkNmZJ_JJ for ; Wed, 12 Jul 2023 04:32:07 -0700 (PDT) Received: from mout-p-103.mailbox.org (mout-p-103.mailbox.org [80.241.56.161]) (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 2F3EFC151AE5 for ; Wed, 12 Jul 2023 04:31:35 -0700 (PDT) Received: from smtp202.mailbox.org (smtp202.mailbox.org [10.196.197.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-103.mailbox.org (Postfix) with ESMTPS id 4R1Ftp4zdMz9s7Q; Wed, 12 Jul 2023 13:31:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dennis-jackson.uk; s=MBO0001; t=1689161490; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=9WD5P4SGzlKjWBYJ7eloJC3yKp3pf0LAfZEnH1mayh0=; b=QLtygd8vg8bt/dEMXVcLZMn2pdfu1JdsiHwcl187Ja9BnpkEsZHG6zL0wreKzg5fIPhKSB Nj0sKha3uuUdNW8QZlu/hwOtlY2aJFR7B/XJrAQdjMQzjsVjI4aKsWp5uq2Ex68mYcdQRS b4bpNKDTC05+FoQdXuKLDF75pABBewRqJjhZ+5Lv8d70SXmWvQRtMEKZ/CGe79yEfw9Oai lL1FwF5X1bMYzITtkTczV9DJXzwo/y9mJ7sGfN4vnczYEgCtPiH5ouCKK8uqBdXl4OmY9p ENrbpwtHkmJ7hSF6bBr1tL8RY57luc8szy92ROruQ87wTlV1Vg1qjJabghrXjQ== Content-Type: multipart/alternative; boundary="------------8V0PNGTNEZvGrBVTuiUd30l1" Message-ID: <5bf310d0-36a0-c09d-dacd-124f06376f14@dennis-jackson.uk> Date: Wed, 12 Jul 2023 12:31:29 +0100 MIME-Version: 1.0 From: Dennis Jackson To: Ilari Liusvaara , TLS List References: <168868149085.54562.8407395333388460548@ietfa.amsl.com> <6c2f1152-f3c1-0dfa-2f8b-784cf7f7286e@dennis-jackson.uk> <0196e082-bece-7c8c-78ff-99e1b51253b6@dennis-jackson.uk> Content-Language: en-US In-Reply-To: Archived-At: Subject: Re: [TLS] Abridged Certificate Compression 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: Wed, 12 Jul 2023 11:32:12 -0000 This is a multi-part message in MIME format. --------------8V0PNGTNEZvGrBVTuiUd30l1 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 12/07/2023 11:01, Ilari Liusvaara wrote: > On Tue, Jul 11, 2023 at 09:37:19PM +0100, Dennis Jackson wrote: >> TLS Certificate Compression influences the transcript for the decompressing >> party, as the output is the Certificate message which is used in the >> transcript. > RFC 8879 does not alter how transcript is computed in any way. Firstly, all extensions added to the ClientHello influence the transcript as the body of the CH message is included in the transcript. Secondly, RFC 8879 specifies a CompressedCertificate message which is the result of applying the negotiated compression algorithm to the original Certificate message. The receiver of the CompressedCertificate message will decompress it and include the resulting Certificate message in their transcript. Consequently, for one party use of RFC 8879 will influence the transcript. > An extension altering computation of transcript would be truly > extraordinary. You might find 6.1.5 and 7.2 of https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ an interesting read :-). Best, Dennis --------------8V0PNGTNEZvGrBVTuiUd30l1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

On 12/07/2023 11:01, Ilari Liusvaara wrote:

On Tue, Jul 11, 2023 at 09:37:19PM +0100, Dennis Jackson wrote:

TLS Certificate Compression influences the transcript for the decompressing
party, as the output is the Certificate message which is used in the
transcript. 

RFC 8879 does not alter how transcript is computed in any way.

Firstly, all extensions added to the ClientHello influence the transcript as the body of the CH message is included in the transcript. 

Secondly, RFC 8879 specifies a CompressedCertificate message which is the result of applying the negotiated compression algorithm to the original Certificate message. The receiver of the CompressedCertificate message will decompress it and include the resulting Certificate message in their transcript. Consequently, for one party use of RFC 8879 will influence the transcript.  

An extension altering computation of transcript would be truly
extraordinary.

You might find 6.1.5 and 7.2 of https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ an interesting read :-).

Best, Dennis

--------------8V0PNGTNEZvGrBVTuiUd30l1--