Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt
Bas Westerbaan <bas@cloudflare.com> Fri, 29 September 2023 14:45 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 E2D41C15154F for <tls@ietfa.amsl.com>; Fri, 29 Sep 2023 07:45:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=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 sj6o0noIjFjJ for <tls@ietfa.amsl.com>; Fri, 29 Sep 2023 07:45:24 -0700 (PDT)
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 49161C151540 for <tls@ietf.org>; Fri, 29 Sep 2023 07:45:24 -0700 (PDT)
Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-5347e657a11so7575090a12.2 for <tls@ietf.org>; Fri, 29 Sep 2023 07:45:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google09082023; t=1695998722; x=1696603522; 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=Ja6c+iTJX1v5Qyn1AonSRZeqdRRDuvZz8XVylXwhWGs=; b=DbDEbcsKqWrcbvD8SV6rudg7TD3h9THUXYWUrASrx4C6k45dsnBhuvyRsPL18TFmh/ sVPWA0RgTSDCbPqRNjPlocbcoR0Aad8vkOL/+oY6KH8PiD0Fid5C6JPnYNrWpAckvxJH I3p15+YYpjOE14nT6dbxqW0hERb7hjldknJtXPTHjCsf2uNY2C8osh//nSIApNo6W+ci fRg41p/ut7axawQoI782+UjNFY+uKiWRzJWzU0a0BseReSdJaHcmroia2rLBFwaBOJax qRlOEgeO/PjZnNUhuCR7GriJ0H7zTqIc5Xj45C11M81WnxHUdYYwMcLk+jYVTC49vA92 Vz/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695998722; x=1696603522; 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=Ja6c+iTJX1v5Qyn1AonSRZeqdRRDuvZz8XVylXwhWGs=; b=sHGfYwO+YDIptwWCco80nBH3hiZmyeUAjXXsV/JkZNLDOwCZSn0fzk6GJElUcMc29Y huiAA1s1pfbLvQxMjlC1ulkURcT9ZBKE1hL9jrfn0MrvtZPTgE/ybxqdUGG9VIV3hSzP AmjGp67eYI4HLaZGHMHh5u7TV3/KNuh1TcGjDrKaO83AtiPUnH7zNBoDIeM5Zlpxn88y xvycWGmq2tmvbPkUjDkrfAY8OnDD6Tqub0E74wFd477mF+gvBA8yYrcpHrfM5gqMTso6 MrOJdP376dBG+ICnHbcY3GRlYYp2H+yhfBQyDY+TYYmubHhqv5hUZ/9mhvvrW9yV4/FM VNBA==
X-Gm-Message-State: AOJu0YwEpQB1akyPxFAx6SV13PVYy8938tVLQc8TEvMFomIkct7W/mfo IvG9nhog+9hb+Av3uq8CDnu1+Xt7v60eRZILlNHxYg==
X-Google-Smtp-Source: AGHT+IE1PPRhe81IolN+n6zSOnmUzGJmd/qbLnOJylmUnZZH4eiKJVQk+nz2NhW2VKi2LUk2o8PgRZibAiXWWnMeYq4=
X-Received: by 2002:aa7:c1d1:0:b0:530:9fbc:8df5 with SMTP id d17-20020aa7c1d1000000b005309fbc8df5mr3740584edp.9.1695998722039; Fri, 29 Sep 2023 07:45:22 -0700 (PDT)
MIME-Version: 1.0
References: <169568255939.9761.10849003375721626023@ietfa.amsl.com> <CAF8qwaDH_XbZefVPbehZ4F55oD-taRPC8ZqvAohLvF_eXZMXZg@mail.gmail.com>
In-Reply-To: <CAF8qwaDH_XbZefVPbehZ4F55oD-taRPC8ZqvAohLvF_eXZMXZg@mail.gmail.com>
From: Bas Westerbaan <bas@cloudflare.com>
Date: Fri, 29 Sep 2023 16:45:11 +0200
Message-ID: <CAMjbhoX=s3Ve4z=Zj6gzdJnSd4sgmyube7B8rxRzvJNn2TGtDg@mail.gmail.com>
To: David Benjamin <davidben@chromium.org>
Cc: "<tls@ietf.org>" <tls@ietf.org>, Suleman Ahmad <suleman@cloudflare.com>, Luke Valenta <lvalenta@cloudflare.com>
Content-Type: multipart/alternative; boundary="0000000000005e0bde0606807900"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/X8roz2X5kmekEULrHa_xbzp3TkU>
Subject: Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-key-share-prediction-00.txt
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: Fri, 29 Sep 2023 14:45:28 -0000
This is a useful and very timely draft — I would like to see it adopted. I'll argue it's more urgent than sketched by David. We have been investigating turning on post-quantum key agreement for connections from Cloudflare to origin servers. In testing, we found that 0.34% of origins will fail to establish a connection if we send X25519Kyber768Draft00 keyshare directly (while still advertising support for classical keyshares.) As expected, a significant portion of failures seem to be caused by the large ClientHello. Interestingly though, the majority of these failures don't seem to be specific to the size of the ClientHello, but are rather caused by the origin not supporting HelloRetryRequest correctly. We're still digging into it, and will share our findings later on. Anyway, even though it's a small fraction of origins, we cannot send a PQ keyshare immediately and completely break the websites in front of those few origins. Instead, we are going [1] for the following approach: we send a X25519 keyshare, but advertise support for Xyber. A server that supports Xyber can then use HelloRetryRequest for a post-quantum connection. Undoubtedly due to GREASE (thanks David), we did not see any issues with this approach. [2] This comes at the cost of an extra roundtrip. To get rid of it, we're scanning key agreement support of origins, and in the future will send Xyber immediately if we see the origin supports it without failing. Now we come to the usefulness of this draft: without it we cannot guarantee that we will negotiate PQ even if both the client and server are configured to prefer it. The problem is that many TLS servers are content with a supported keyshare, and will not HRR even if a more preferred key agreement is available. Indeed: a MitM can break our PQ test connections, which will make us send X25519, while advertising support for Xyber. Despite advertising support for Xyber, many TLS servers will now be content with X25519. Best, Bas [1] https://blog.cloudflare.com/post-quantum-to-origins/ [2] Of course, when a server that can't handle large ClientHello or HRR adds Xyber, it will still need to fix those issues, but importantly they don't block the rest anymore. PS. We have also included some stats on classical key agreement support and preference of origins in [1]. On Tue, Sep 26, 2023 at 6:46 PM David Benjamin <davidben@chromium.org> wrote: > Hi all, > > A while back, we discussed using a DNS hint to predict key shares and > reduce HelloRetryRequest, but this was dropped due to downgrade issues. In > thinking through post-quantum KEMs and the various transitions we'll have > in the future, I realized we actually need to address those downgrade > issues now. I've published a draft below which is my attempt at resolving > this. > > We don't need a DNS hint for the *current* PQ transition—most TLS > ecosystems should stick to the one preferred option, and then clients can > predict that one and move on. However, I think we need to lay the > groundwork for it now. If today's round of PQ supported groups cannot be > marked "prediction-safe" (see document for what I mean by that), > transitioning to the *next* PQ KEM (e.g. if someone someday comes up with > a smaller one that we're still confident in!) will be extremely difficult > without introducing downgrades. > > Thoughts? > > David > > ---------- Forwarded message --------- > From: <internet-drafts@ietf.org> > Date: Mon, Sep 25, 2023 at 6:56 PM > Subject: New Version Notification for > draft-davidben-tls-key-share-prediction-00.txt > To: David Benjamin <davidben@google.com> > > > A new version of Internet-Draft > draft-davidben-tls-key-share-prediction-00.txt > has been successfully submitted by David Benjamin and posted to the > IETF repository. > > Name: draft-davidben-tls-key-share-prediction > Revision: 00 > Title: TLS Key Share Prediction > Date: 2023-09-25 > Group: Individual Submission > Pages: 11 > URL: > https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.txt > Status: > https://datatracker.ietf.org/doc/draft-davidben-tls-key-share-prediction/ > HTML: > https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.html > HTMLized: > https://datatracker.ietf.org/doc/html/draft-davidben-tls-key-share-prediction > > > Abstract: > > This document clarifies an ambiguity in the TLS 1.3 key share > selection, to avoid a downgrade when server assumptions do not match > client behavior. It additionally defines a mechanism for servers to > communicate key share preferences in DNS. Clients may use this > information to reduce TLS handshake round-trips. > > > > The IETF Secretariat > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
- [TLS] Fwd: New Version Notification for draft-dav… David Benjamin
- Re: [TLS] Fwd: New Version Notification for draft… Bas Westerbaan
- Re: [TLS] Fwd: New Version Notification for draft… Joseph Birr-Pixton
- Re: [TLS] Fwd: New Version Notification for draft… Bas Westerbaan
- Re: [TLS] Fwd: New Version Notification for draft… David Benjamin
- Re: [TLS] Fwd: New Version Notification for draft… Dennis Jackson
- Re: [TLS] Fwd: New Version Notification for draft… David Benjamin
- Re: [TLS] Fwd: New Version Notification for draft… Rob Sayre
- Re: [TLS] Fwd: New Version Notification for draft… David Benjamin
- Re: [TLS] Fwd: New Version Notification for draft… Rob Sayre
- Re: [TLS] Fwd: New Version Notification for draft… Bas Westerbaan
- Re: [TLS] Fwd: New Version Notification for draft… David Benjamin
- Re: [TLS] Fwd: New Version Notification for draft… Bas Westerbaan
- Re: [TLS] Fwd: New Version Notification for draft… Dennis Jackson
- Re: [TLS] Fwd: New Version Notification for draft… David Benjamin
- Re: [TLS] Fwd: New Version Notification for draft… David Benjamin
- Re: [TLS] Fwd: New Version Notification for draft… Rob Sayre
- Re: [TLS] Fwd: New Version Notification for draft… David Benjamin
- Re: [TLS] Fwd: New Version Notification for draft… Rob Sayre
- Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notific… Andrei Popov
- Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notific… Rob Sayre
- Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notific… Andrei Popov
- Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notific… Rob Sayre
- Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notific… David Benjamin
- Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notific… Rob Sayre
- Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notific… Michael P1
- Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notific… Peter Gutmann
- Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notific… David Benjamin
- Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notific… Salz, Rich
- Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notific… Bob Beck
- Re: [TLS] Fwd: New Version Notification for draft… Loganaden Velvindron
- Re: [TLS] [EXTERNAL] Re: Fwd: New Version Notific… Michael P1
- Re: [TLS] Fwd: New Version Notification for draft… Eric Rescorla
- Re: [TLS] Fwd: New Version Notification for draft… David Benjamin