Re: [TLS] [EXTERNAL] Re: Next steps for key share prediction

Andrei Popov <Andrei.Popov@microsoft.com> Tue, 12 March 2024 00:04 UTC

Return-Path: <Andrei.Popov@microsoft.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 C04B8C14F6E3 for <tls@ietfa.amsl.com>; Mon, 11 Mar 2024 17:04:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-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_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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 (1024-bit key) header.d=microsoft.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 dv1po42c_FAN for <tls@ietfa.amsl.com>; Mon, 11 Mar 2024 17:04:11 -0700 (PDT)
Received: from BN8PR05CU002.outbound.protection.outlook.com (mail-eastus2azon11023019.outbound.protection.outlook.com [52.101.56.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17882C14F5FF for <tls@ietf.org>; Mon, 11 Mar 2024 17:04:10 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jrTdhownPjHpa19vUZQA5XZ+nXV56qZLqmobvRwAw72qdOuPzrecI4ZwtMV0xIYR8UjzvOendkKfuw1WkIYsRzo+xAXxBEfVZVOLcjj7El5mWUOiCagh6NhRlMclPbS9vG7O/uxSxbNjDFL4feFpFF6mBhkgF7orz3xBczeti0fhchqKYg9KCYrPmvEwymvXDqAqmWoTAE5HSpD/QIHTGBPFe5wnTwGtOL06uhgXoERkBXVClpLDxNidIEITisxG9E4355RTUtbmdkGOkGvEYS8Sc9wjpzYk4qUeozOtkaaKsbjw94hJPwa3UIJDwO1WH5sYxTx1MZOMWH9VsKrjEQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=OHR7tc1PqhMUKvEEALdarpZADOQw1AwJblyM5wvljW0=; b=JT2OshjAD+ZZgydgiWXYSWo/+JANsIyPUUHfOwVIw/aPKvRUNhfEM3k5vYSE9HPbrSTiaD9lPLRML8/oYqr2P/+GHL98gW8r/1JN7v5P/oetEuzuIiFRsp5q/0+PDzzQ6k89yrdLppOvqPlHcNXFnkk3y99GKRMSSP53mi3ipCBfwySGW9PXZZsoeHT584yRiiXQHdhG2EMJWXHQPag29QuuA6Gv2zDGiG/M8P2XoAN+nyxrB2RvY1a8kAzqTa+7UuOqvLKRBXemJ0yP0RKjdJBvHxx1QhLBe0P1d39bwZy1P5klTHhKkvpXvfI7QeMuy8UO7Tmo2jVO3u3LUacKyw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OHR7tc1PqhMUKvEEALdarpZADOQw1AwJblyM5wvljW0=; b=geYK4aPRmGo3ShKLsCzdjabvOSKtftcp5KQzimlajCBubhHqsiDij1zKZ30IqgXY2AvBs1PRxpYCTmfhXFQ+2QjEP46/e2K5tMGhMFmB5dMbM2JgmS2dBSIP3aDlV3TatkdDsxmcWqkRDKATAP+die1621EiTcMqkHoAav1IB/g=
Received: from MW2PR2101MB1083.namprd21.prod.outlook.com (2603:10b6:302:a::24) by MN0PR21MB3511.namprd21.prod.outlook.com (2603:10b6:208:3d0::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.2; Tue, 12 Mar 2024 00:04:05 +0000
Received: from MW2PR2101MB1083.namprd21.prod.outlook.com ([fe80::3bc5:85a5:87b7:ed]) by MW2PR2101MB1083.namprd21.prod.outlook.com ([fe80::3bc5:85a5:87b7:ed%7]) with mapi id 15.20.7409.002; Tue, 12 Mar 2024 00:04:04 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: David Benjamin <davidben@chromium.org>, Watson Ladd <watsonbladd@gmail.com>
CC: "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [EXTERNAL] Re: [TLS] Next steps for key share prediction
Thread-Index: AQHacOgbPsO5riWKnEa2wjZwQNhNjLEufbwAgAS+ZMA=
Date: Tue, 12 Mar 2024 00:04:04 +0000
Message-ID: <MW2PR2101MB1083F45D236CDD378DAA885D8C2B2@MW2PR2101MB1083.namprd21.prod.outlook.com>
References: <CAF8qwaB6OZr=Cw7aGyo+9EEo_wQ5Da7KF=3CSEttWqyHQn=+fw@mail.gmail.com> <CACsn0cmc3zM6bWdvFffj11R5vomrnfYQBTe_4j1c=1Sq-GUNyw@mail.gmail.com> <CAF8qwaBsDkL-F8cThUCb5LWnXqj0BD5_ac-WcGpRKF2FvZpXdQ@mail.gmail.com>
In-Reply-To: <CAF8qwaBsDkL-F8cThUCb5LWnXqj0BD5_ac-WcGpRKF2FvZpXdQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=7e4aacfe-7160-4acb-9753-45149bb97861; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2024-03-11T23:51:00Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=microsoft.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: MW2PR2101MB1083:EE_|MN0PR21MB3511:EE_
x-ms-office365-filtering-correlation-id: b0c66194-df3f-4526-e8f9-08dc4227ee2f
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: iwa6ENeeYwx4qD1iapC4FoSMz8qg/SPDlJjHHEx6+T4+MJCtGs/7B7PJyOQM9VAiWSHjZ75BGbprtffjtSynZUlIUETFvSL75seSHI3LUwxj01EHBEzfDbhES0B2bTC4DStTRfX/xLqTrFbCbpUDgjB6Iz2kXZbSTboFAIDDlvNEhdwwdAXd9EXsjP4QInUULsM8q6vzvkPoX5c16tH0+sWhTTnRGOVO6CQgHeRD3MI3vwZhSWpEgtdVgi2/QtZ1ifFfHcOdjWbGC+xrmqH7/Li8SDx7wQE9318/yDl0fEwBmP9VKNQFwR5DVfxpHqJsiZdC7K37czgeAYXVC7dvlXyq1gQDLLU3JA9fQ/D7zTajZXLljA7KK4a8d11sGjfgwHu79Xq7EgteX6kfjXUJtlwjC2j91C5DGFAlChqLIOWHjWaHlMLGd2Aqb18eW2hVmKsxEwCUaB6ZOshC3IicVdf20KYcPbGvBOyhXeOgVDXK794FSIonEJlsRRrgVwRZhq9ZUdohD55y+IujDiB0W/A1jCNe0f2ayXohR+oNRBRE3s6HFSzhMYo/Ap68FQfKKXh81hstfnGkoLP4OHRj9sojw1SDZLj3tTqbuvIKMEEkPTR5jlDIo96BqlNUtzZblNVzd4TrBlfUMsHAjSi3RW55ZwnSvWIBEnwegz2dA/o29tnFufL+H60QanUeHc3a
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW2PR2101MB1083.namprd21.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(1800799015)(376005)(38070700009); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: VfYQSAit65u6++D7HUReMcFRqjpnEBPhGjfyajfhEaw4sEUPR2e2KzH+xT2HLwXb4AM8iq1vsjP9GpzzMo27Dj/84w+/6Md8M7IGLGfLOl9z1MAq43xDdd4/CM1OLGS/PWaD4f+OPAJxTFLW/X+x9K4nbVRDZbsKzJPQt2zdO712Wjo15pWBwKCXnl+vWqFfzYl6spw4TMFHokhnwfM0Nfs3jk9IxxxRzPs6rPkyHidjzNeCpBm90o8IkkSNR+MVI/p6SVH4EGW4vVBfNwJDvztLfeknnfBOPe1fucDwYokYl9hz5QTcTSP+/9Gw4HlK33Kv7w2SbgtnKLtcRgbtakbQq8RuzaXqEVxA0P9uZ+VVccVbT1IKIzPTeYv29ItKJJuovgh/D31q1v3Wq4lSmxoKTSorqHKN3ECUzfX8Q3RNQyQKluqr7tBt/ImJbjbS8zsuoYEN+aNj/nHO6QrSX6YJAKH/fLuuQ4rVe6aSpy4pw0zWLLXkO6Woa5S8kQ1/1JUzY1RRnrOVctfXrTX8ChV388yjx+PiDZlW11QneP6zwY9oZyRDs6OSsTKhR/qJcNQZrITz7YLr35/2Bh1q2U8Ae2a1UNocrcFH+idx7bkApfkSjGD9RoSXicVmrmUDlZYrAe79bXSBXG7HBUq0MyMCm3tkhR/95q3aPPJK2UshAGen95WtpQ59W+EL7hI7q5bVDG0i/hQqD4sIAWw+pBocnbaF7Ha3DYFHD5ELdQ6LsuWR7c+GFIYO2+NliRy3mvsIU3r+xYrkVreJcODzukkaKsnC7VqOZGXhybVafo8Wb8JX/9K423mOBOyZdUS+zsITgC0lB7KkadLJ7yOLGnwbCei4jTKeQFm1qeVki6eCPohQy5yLmHCnB+TKiqD6GdW5nnZTMpQUZUsd62ump92HJ3PDfb1JF+WvtjWrD6YVzH50CuaDhO1Y6G1UIAxYOUvMUSMy8tZPMszApLECjKdHGeyJXK4PN9pzv2nVAOuiY5pCId1QUJMISIMt1CYtGnStx3x/aNOeRCwr+CfIE99vdxO9DhVPlzvuuinuYIaGJwuNNlsiSegled7LZIndtgMnOKXKjVDs86FhJqHw41Qca5JvJJ85ByfunOux4vsKKVYMCIDZusG9Pfi98qs5zyNB5Eu2tfnCJI4pcXGyonkTzKWJGc3Kf1kWRrvY8tkTuGNNcc618Mn95lSqJXksvOEtMCBXbBSt4SgLaBqr4cnS0nROwyzdn9osrupSogzwI2h2N952hjwCNXQuALuq+5neVLdO9dkyIIdTq/thxRulU/P91eYiSpgPLyEiUBUEiHDBKuLeeRE1Wl0mbZhYwkU2M/SM15xtz4HRMfexO5UG6/q0wfaS5vEbYUwG7lcM0rCiEk2Dk5tH004a3o2ynbCfxf/lhYOnO89Znza7OcO595ZLHdG7pzTojexOOPxWUzcJEUfIM7xo2Q1kVrghi9L2RfND1fmPRHKEn4Fb8mt7KUUttYljAfmUStpXB90ipwB+uAU30B/jrDAZwGFMyoCvj7quxelQHfgy9I1pJXMONQGadlYmC8MKomzXZcfBHT8CWabOTMFcL3hhVJ/+
Content-Type: multipart/alternative; boundary="_000_MW2PR2101MB1083F45D236CDD378DAA885D8C2B2MW2PR2101MB1083_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MW2PR2101MB1083.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b0c66194-df3f-4526-e8f9-08dc4227ee2f
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2024 00:04:04.6437 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: L9Idq9WKsGpjoEBjxsFaErhyBgtoUrIj7y+Br29w2707/FoSZifR5qBR+YM30Qg48eQSOtDKHCIV9spdNDDl2Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR21MB3511
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/wrVp-87FctWVdie2aplGp-hCuuk>
Subject: Re: [TLS] [EXTERNAL] Re: Next steps for key share prediction
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: Tue, 12 Mar 2024 00:04:14 -0000

  *   …and now I'm coming around to the idea that we don't need to do anything special to account for the "wrong" server behavior. Since RFC8446 already explicitly said that clients are allowed to not predict their most preferred groups, we can already reasonably infer that such servers actively believe that all their groups are comparable in security.
It makes sense for some services to prioritize RTT reduction; others may prioritize group strength. There are a lot of services out there prioritizing weaker groups for CPU savings (e.g., this is one of the reasons why Curve 25519 is so popular).


  *   I... question whether taking that position is wise, given the ongoing postquantum transition, but so it goes
Servers will have to be updated and reconfigured for PQC/hybrid support, at which time they will likely apply a different policy.


  *   Hopefully your TLS server software, if it advertises pluggable cryptography with a PQ use case, and yet opted for a PQ-incompatible selection criteria, has clearly documented this so it isn't a surprise to you. ;-)
Correct.


  *   Between all that, we probably can reasonably say that's the server operator's responsibility?
Yes.

Cheers,

Andrei

From: TLS <tls-bounces@ietf.org> On Behalf Of David Benjamin
Sent: Friday, March 8, 2024 3:25 PM
To: Watson Ladd <watsonbladd@gmail.com>
Cc: <tls@ietf.org> <tls@ietf.org>
Subject: [EXTERNAL] Re: [TLS] Next steps for key share prediction

On Thu, Mar 7, 2024 at 6:34 PM Watson Ladd <watsonbladd@gmail.com<mailto:watsonbladd@gmail.com>> wrote:
On Thu, Mar 7, 2024 at 2:56 PM David Benjamin <davidben@chromium.org<mailto:davidben@chromium.org>> wrote:
>
> Hi all,
>
> With the excitement about, sometime in the far future, possibly transitioning from a hybrid, or to a to-be-developed better PQ algorithm, I thought it would be a good time to remind folks that, right now, we have no way to effectively transition between PQ-sized KEMs at all.
>
> At IETF 118, we discussed draft-davidben-tls-key-share-prediction, which aims to address this. For a refresher, here are some links:
> https://davidben.github.io/tls-key-share-prediction/draft-davidben-tls-key-share-prediction.html
> https://datatracker.ietf.org/meeting/118/materials/slides-118-tls-key-share-prediction-00
> (Apologies, I forgot to cut a draft-01 with some of the outstanding changes in the GitHub, so the link above is probably better than draft-00.)
>
> If I recall, the outcome from IETF 118 was two-fold:
>
> First, we'd clarify in rfc8446bis that the "key_share first" selection algorithm is not quite what you want. This was done in https://github.com/tlswg/tls13-spec/pull/1331
>
> Second, there was some discussion over whether what's in the draft is the best way to resolve a hypothetical future transition, or if there was another formulation. I followed up with folks briefly offline afterwards, but an alternative never came to fruition.
>
> Since we don't have another solution yet, I'd suggest we move forward with what's in the draft as a starting point. (Or if this email inspires folks to come up with a better solution, even better! :-D) In particular, whatever the rfc8446bis guidance is, there are still TLS implementations out there with the problematic selection algorithm. Concretely, OpenSSL's selection algorithm is incompatible with this kind of transition. See https://github.com/openssl/openssl/issues/22203

Is that asking whether or not we want adoption? I want adoption.

I suppose that would be the next step. :-) I think, last meeting, we were a little unclear what we wanted the document to be, so I was trying to take stock first. Though MT prompted me to ponder this a bit more in https://github.com/davidben/tls-key-share-prediction/issues/5, and now I'm coming around to the idea that we don't need to do anything special to account for the "wrong" server behavior. Since RFC8446 already explicitly said that clients are allowed to not predict their most preferred groups, we can already reasonably infer that such servers actively believe that all their groups are comparable in security. OpenSSL, at least, seems to be taking that position. I... question whether taking that position is wise, given the ongoing postquantum transition, but so it goes. Hopefully your TLS server software, if it advertises pluggable cryptography with a PQ use case, and yet opted for a PQ-incompatible selection criteria, has clearly documented this so it isn't a surprise to you. ;-)

Between all that, we probably can reasonably say that's the server operator's responsibility? I'm going to take some time to draft a hopefully simpler version of the draft that only defines the DNS hint, and just includes some rough text warning about the implications. Maybe also some SHOULD level text to call out that servers should be sure their policy is what they want. Hopefully, in drafting that, it'll be clearer what the options are. If nothing else, I'm sure writing it will help me crystalize my own preferences!

> Given that, I don't see a clear way to avoid some way to separate the old behavior (which impacts the existing groups) from the new behavior. The draft proposes to do it by keying on the codepoint, and doing our future selves a favor by ensuring that the current generation of PQ codepoints are ready for this. That's still the best solution I see right now for this situation.
>
> Thoughts?

I think letting the DNS signal also be an indicator the server
implements the correct behavior would be a good idea.

I'm afraid DNS is typically unauthenticated. In most TLS deployments, we have to assume that the attacker has influence over DNS, which makes it unsuitable for such a signal. Of course, if we end up settling on not needing a signal, this is moot.

David