[TLS] Re: Bytes server -> client
Bas Westerbaan <bas@cloudflare.com> Sat, 09 November 2024 12:23 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 E85F6C14F713 for <tls@ietfa.amsl.com>; Sat, 9 Nov 2024 04:23:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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_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=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 n3zx_mrMwOpr for <tls@ietfa.amsl.com>; Sat, 9 Nov 2024 04:22:58 -0800 (PST)
Received: from mail-yw1-x1132.google.com (mail-yw1-x1132.google.com [IPv6:2607:f8b0:4864:20::1132]) (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 41563C14F711 for <tls@ietf.org>; Sat, 9 Nov 2024 04:22:58 -0800 (PST)
Received: by mail-yw1-x1132.google.com with SMTP id 00721157ae682-6e5b7cd1ef5so26233347b3.1 for <tls@ietf.org>; Sat, 09 Nov 2024 04:22:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google09082023; t=1731154977; x=1731759777; 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=w0+lO6nzaGGwWvX4LNd8dZ8UdJLMjw6m984L5zHtgGw=; b=MSQvZSNCqBhllusYqVUZQtoYBBBnEGPFTfYWFqASd79WsbrnZa1zX9A47tDmhnC5Qn NYuE1Su6ADnbXfXfMWYL6Dl4RVZYikQpKHs/xTnjDDt3WvSHKLvYF8KBFJ70kEkRhGvK 5xEmgncZHSEpc63p+IpKZSWcWSxF6jSVE9ep5wFMrD1bDRDvkGwUTOcFypVBMjUAoUo1 Ps3zEq1V963IW4m8hdKiBszL3Xs9sSrWlbx3tC4ncNCWgPz4D12V8hZ78jeQcnH/o8p0 H1Kt2BfLr5PGYbB0l032qKNL6QV+huV6AA5l1vSyke+nZGGWBImPEIN1uFCzAovQB50P 0Nkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731154977; x=1731759777; 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=w0+lO6nzaGGwWvX4LNd8dZ8UdJLMjw6m984L5zHtgGw=; b=C3pX9+vxRJ+mcKScCyD577vNxUG36qvc1tX69AGSG3nD7d2EtGEFJoE4B+oK+QskPb s82oPDanYAVuK87CsT9ufd+xPw0lv0SEmX+4VUjpldjwUNpeinuUdNB02+9qpu68c2DM bZY31MgXZCN8RG2krJ6wthkS3dnEut93h7xZZqnlWGlzMa2Ahvdgcy8lVV43DP+PQKqP beCtTcl0Qpb8wMux0PDCBWY6KzlF7IrsASqqk9WHIDkjiqPsZT4jMStmqQ+OUSAJGCpA U2HBDYPSO6YvM2XxC+SG/r1KEAXx3DaNJUOvAc/31TZDSBi4Pq0DBajmENTzNIUgvwp5 159w==
X-Gm-Message-State: AOJu0YwQxwl9yyejroE5OkhkyQApcMeHdV8SnfZkxuXvz+gHF6tGSHYq 1CQ7SiBoeCo2mEznoI8Fjnib1DUHX8US9WKHsDMf0qei3r8kmuqhfKw2M/6s18XLGTGdNmPo4MJ kWT96Nb7lyXcjkHkAtYQG6L5BxTmbgvNdSrOqlhQsNxZmo6ckxMKJWg==
X-Google-Smtp-Source: AGHT+IHZqcZiruRYekvrdzUpCdASBi8IiYRX39AEEnshJS0kJKodrqYdb/Q1B+pnE5bbVODBxYV/7ENOA6ybTjomUTA=
X-Received: by 2002:a05:690c:6601:b0:6e3:fd6:6ccb with SMTP id 00721157ae682-6eaddda0f27mr69708467b3.13.1731154977208; Sat, 09 Nov 2024 04:22:57 -0800 (PST)
MIME-Version: 1.0
References: <CAMjbhoUdt53ypQMFgNDh6YM9kDpP8pEB7Ost1nBPFF=kwi-gsA@mail.gmail.com> <ME0P282MB5587057E101756B878B90E18A35D2@ME0P282MB5587.AUSP282.PROD.OUTLOOK.COM>
In-Reply-To: <ME0P282MB5587057E101756B878B90E18A35D2@ME0P282MB5587.AUSP282.PROD.OUTLOOK.COM>
From: Bas Westerbaan <bas@cloudflare.com>
Date: Sat, 09 Nov 2024 13:22:46 +0100
Message-ID: <CAMjbhoVFwU6p1PSOd4VkDFOvcOPtw=he8gCutS6bhoBN0ixx7g@mail.gmail.com>
To: Raghu Saxena <poiasdpoiasd@live.com>
Content-Type: multipart/alternative; boundary="00000000000077e20f062679ed7f"
Message-ID-Hash: UW3RXV4WVD7IDLWS4C73BF6HDPYS5FOE
X-Message-ID-Hash: UW3RXV4WVD7IDLWS4C73BF6HDPYS5FOE
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
CC: tls@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: 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/Dis2fgAj490gGp2zuwzpNkVCfOk>
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>
> > > > 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. > > > Would you be willing to share some numbers around the increase in > failures? Details are in our 2021 blog post https://blog.cloudflare.com/sizing-up-post-quantum-signatures/ > What do you think might've been the cause for increased > failures at clients and middleboxes? One hypothesis I have is > TLS-related DPI might allocate a certain buffer to capture the > handshake, which was now being crossed. > That could well be one cause. 16MB chains are allowed by the spec, but most TLS libraries reject shorter chains. Back in 2021 I saw that OpenSSL rejected chains longer than 106kB, and Go rejects them if they're longer than 64kB. That's still well above 13kB, but there could be middleboxes that picked a shorter buffer length. Note that this is problematic for those that only want to deploy a single certificate "chameleon hybrids". Best, Bas > > Regards, > > Raghu Saxena > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-leave@ietf.org >
- [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
- [TLS] Re: [Pqc] Re: Re: Bytes server -> client Kampanakis, Panos
- [TLS] Re: [Pqc] Re: Re: Bytes server -> client Bas Westerbaan