[TLS] Bytes server -> client
Bas Westerbaan <bas@cloudflare.com> Thu, 07 November 2024 14:07 UTC
Return-Path: <bas@cloudflare.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 2DEC2C14F5F1 for <tls@ietfa.amsl.com>; Thu, 7 Nov 2024 06:07:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cloudflare.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 nhplFxzg6mKa for <tls@ietfa.amsl.com>; Thu, 7 Nov 2024 06:06:56 -0800 (PST)
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 765FCC14F5E0 for <tls@ietf.org>; Thu, 7 Nov 2024 06:06:56 -0800 (PST)
Received: by mail-lf1-x12c.google.com with SMTP id 2adb3069b0e04-53c78ebe580so2151997e87.1 for <tls@ietf.org>; Thu, 07 Nov 2024 06:06:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google09082023; t=1730988413; x=1731593213; darn=ietf.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=dICnW5akyK8uTE3SLtj4ohKKcdOZL7g8O1PHjjItYXQ=; b=JvoAiGexi/uGFYrFYY6APy1vzh0Qi8JtCDYkVjMKceRGI6QdrIv2r1Sp9BY4HH9XwP RuosGatV42f839rSM/3Vw8FDudruCfPxFsYUiJH7C/cnynuFo9pAfphqoVFDoYUB2arb T7Ncl1+mfVzbbj5g5p3uQQ4quQO7jZm4g19dFWz0vUq5Tq8oo5FdYtC+Jly7u3OP2kOQ VxAjOI/s/ytvWDQNyT0rNDj2FIX2HR3TedsZnNxb5TtzK9eAIUzxaNQxxAtN9qjOxXbb dnJljrfge7hI6uNR8AO53m+8cpjffXa+T70iVVt5YrfhtbS79dZ0FQlYCyaFzjBBeoPD 8deQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730988413; x=1731593213; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=dICnW5akyK8uTE3SLtj4ohKKcdOZL7g8O1PHjjItYXQ=; b=oLatRNn8rKHAR1aoP3wE0/CsIchbZ2Tk8PU/haQ7PqMunz7p1ioX6ZjeDLJl9RK0PT HEFSGF6KmDQ/Wh/catZfV15NVa11LJH+EC4YtJ4A6xVbya9qUSsd45Y4/0+xOPxFbVFi ETQGGPp7eqPf26zI10f6CwxL+FsBr0OMgDHiqF7JFfpuXgSyET+5A+GKFvvCxmnBwdoA r/9Ytra7+oyUnBCZzMGdZw+MZciX5e7zE553R2JlKUbMDSFx9BnS9Rnv897r1WJqB3TI JSlv6SihsBwu6YcmpLF+svGdQ1wiyAReGvb5vKFKI4K5lcE3ursX8yDxnBVRSM061T/W LRfg==
X-Gm-Message-State: AOJu0Yy0SJdMMS3AF4Sa57Xs1ogQoQ8mW05BuGvipI7iYJYxBcdVpSfd w2UoM5j3vjTJn0jBxNTLDAB+Wm4O/nNvlIBXbIn8gfZWaiUYVxrNuljN8NFAc8d9fNBCg4Q+7cf QgFzk4mua67bTHBBaB2UV+MV13TI1AxYQo3VMFJ3WToB/zTsmxmuZdQ==
X-Google-Smtp-Source: AGHT+IF70Szs3RPY7lnwrwURVps67yUSeG7t77s8w5G5vyh8ARqbGPoSv9SnLMHQ5ZIjc+A3idDx8QqKLQ7B0HSSh9U=
X-Received: by 2002:a05:6512:1595:b0:539:93e8:7ed8 with SMTP id 2adb3069b0e04-53d85a872a3mr25063e87.15.1730988412780; Thu, 07 Nov 2024 06:06:52 -0800 (PST)
MIME-Version: 1.0
From: Bas Westerbaan <bas@cloudflare.com>
Date: Thu, 07 Nov 2024 15:06:41 +0100
Message-ID: <CAMjbhoUdt53ypQMFgNDh6YM9kDpP8pEB7Ost1nBPFF=kwi-gsA@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>, pqc@ietf.org
Content-Type: multipart/alternative; boundary="00000000000074730106265325ee"
Message-ID-Hash: RQQX43LBP5ZNFFZKVMHGPGIHDB66IH3V
X-Message-ID-Hash: RQQX43LBP5ZNFFZKVMHGPGIHDB66IH3V
X-MailFrom: bas@cloudflare.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
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Bytes server -> client
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/YgJyhNEufvYGDiSfTXekV1fJD5o>
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>
Hi all, Just wanted to highlight a blog post we just published. https://blog.cloudflare.com/another-look-at-pq-signatures/ At the end we share some statistics that may be of interest: On average, around 15 million TLS connections are established with > Cloudflare per second. Upgrading each to ML-DSA, would take 1.8Tbps, which > is 0.6% of our current total network capacity. No problem so far. The > question is how these extra bytes affect performance. > Back in 2021, we ran a large-scale experiment to measure the impact of big > post-quantum certificate chains on connections to Cloudflare’s network over > the open Internet. There were two important results. First, we saw a steep > increase in the rate of client and middlebox failures when we added more > than 10kB to existing certificate chains. Secondly, when adding less than > 9kB, the slowdown in TLS handshake time would be approximately 15%. We felt > the latter is workable, but far from ideal: such a slowdown is noticeable > and people might hold off deploying post-quantum certificates before it’s > too late. Chrome is more cautious and set 10% as their target for maximum TLS > handshake time regression. They report that deploying post-quantum key > agreement has already incurred a 4% slowdown in TLS handshake time, for the > extra 1.1kB from server-to-client and 1.2kB from client-to-server. That > slowdown is proportionally larger than the 15% we found for 9kB, but that > could be explained by slower upload speeds than download speeds. > There has been pushback against the focus on TLS handshake times. One > argument is that session resumption alleviates the need for sending the > certificates again. A second argument is that the data required to visit a > typical website dwarfs the additional bytes for post-quantum certificates. > One example is this 2024 publication, where Amazon researchers have > simulated the impact of large post-quantum certificates on data-heavy TLS > connections. They argue that typical connections transfer multiple requests > and hundreds of kilobytes, and for those the TLS handshake slowdown > disappears in the margin. > Are session resumption and hundreds of kilobytes over a connection typical > though? We’d like to share what we see. We focus on QUIC connections, which > are likely initiated by browsers or browser-like clients. Of all QUIC > connections with Cloudflare that carry at least one HTTP request, 37% are > resumptions, meaning that key material from a previous TLS connection is > reused, avoiding the need to transmit certificates. The median number of > bytes transferred from server-to-client over a resumed QUIC connection is > 4.4kB, while the average is 395kB. For non-resumptions the median is 7.8kB > and average is 551kB. This vast difference between median and average > indicates that a small fraction of data-heavy connections skew the average. > In fact, only 15.8% of all QUIC connections transfer more than 100kB. > The median certificate chain today (with compression) is 3.2kB. That means > that almost 40% of all data transferred from server to client on more than > half of the non-resumed QUIC connections are just for the certificates, and > this only gets worse with post-quantum algorithms. For the majority of QUIC > connections, using ML-DSA as a drop-in replacement for classical signatures > would more than double the number of transmitted bytes over the lifetime of > the connection. > It sounds quite bad if the vast majority of data transferred for a typical > connection is just for the post-quantum certificates. It’s still only a > proxy for what is actually important: the effect on metrics relevant to the > end-user, such as the browsing experience (e.g. largest contentful paint) > and the amount of data those certificates take from a user’s monthly data > cap. We will continue to investigate and get a better understanding of the > impact. Best, Bas
- [TLS] Re: Bytes server -> client Kampanakis, Panos
- [TLS] Re: Bytes server -> client Raghu Saxena
- [TLS] Bytes server -> client Bas Westerbaan
- [TLS] Re: Bytes server -> client Luke Valenta
- [TLS] Re: [Pqc] Re: Re: Bytes server -> client John Mattsson
- [TLS] Re: Bytes server -> client Bas Westerbaan
- [TLS] Re: Bytes server -> client D. J. Bernstein
- [TLS] Re: Bytes server -> client Luke Valenta