From nobody Mon Oct 4 01:19:57 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A925B3A1256 for ; Mon, 4 Oct 2021 01:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5ruH33aM156 for ; Mon, 4 Oct 2021 01:19:40 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD903A124E for ; Mon, 4 Oct 2021 01:19:39 -0700 (PDT) Received: from ja.int.chopps.org.chopps.org (047-026-251-217.res.spectrum.com [47.26.251.217]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 5033E80526; Mon, 4 Oct 2021 08:19:38 +0000 (UTC) References: <41C188CD-9B34-4FD9-A9B9-632C335253A4@chopps.org> <24858.42061.118149.546106@fireball.acr.fi> <24858.54291.205079.485517@fireball.acr.fi> <04158312-E6F2-4467-B435-58D77ED7435E@dell.com> <509B58FB-03A1-4C28-BE47-1E4A47478512@chopps.org> <24859.37908.612701.587580@fireball.acr.fi> <9BD66C9D-9E6C-4BEC-A71F-D74B667EA503@chopps.org> <8B9B2CB1-D470-45AD-9C9A-218FB3DBE811@chopps.org> <24859.55228.954532.765168@fireball.acr.fi> <24886.26315.915608.856404@fireball.acr.fi> <24886.30488.12451.378363@fireball.acr.fi> <3171E295-4AA1-49C2-9F27-1DD2BAC4D19A@chopps.org> User-agent: mu4e 1.6.5; emacs 27.2 From: Christian Hopps To: Christian Hopps Cc: Paul Wouters , "Koning, Paul" , touch@strayalpha.com, Tero Kivinen , ipsec@ietf.org Date: Mon, 04 Oct 2021 04:10:53 -0400 In-reply-to: Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [IPsec] iptfs publication request X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2021 08:19:51 -0000 --=-=-= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Tero, Will you be able to provide the text changes that would cover the issue you= have? Would really like to get this submitted to IESG before another IETF = cycle completes. Thanks, Chris. Christian Hopps writes: > It was resolved with the transport area by adding the drop timer. I > added more text to highlight and even recommend the drop timer in the > latest revision, but it is apparently not enough. > > I believe Tero really wants to allow for sending packets as soon as > he can, even if it means complexity in the implementation (keeping 1/ > 2 processed outer packets around), I believe this is unneeded, but > see no reason to disallow it either =E2=80=94 and certainly not to block = the > document. > > I=E2=80=99m just asking Tero to provide text that will make him happy, ra= ther > than keep going around and around with me not getting the text > correct. > > Thanks, > Chris. > > > > Paul > > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAmFauRgACgkQLh2DDte4 MCVtohAAj0jTebTRmQrag4M01H49rNW5g6xoXy4spZIG8zxFjCa+otzXCBNtZtNe FvrdmDKOLYFWUAvz74rVbAd3+JpmrsSbiVC3E0Me1itxjbAdUdytR3j7UiIuK1qO 5ISM2U7Rv66i3zm1BL9v1PgQv3o2WtHd/u/bNtBn42IiSetxr9873l+1lk0k2hf3 MhEFFiFU3SlKB0jHX7VdwPnqFNlnk4G8nPbodKMX1ZZEdgZUlYUVrnDZcVIOloD2 SEqENCQYcKCLXAbUBiBUpSHu//mG40TQ550PGh93z6r+Zzq0yaAYFz7YjojF0uys zqlHSsizkNH2clyoGgZCrprQ2YkoK9fYl2TGBmBh2sWngpHaRj9kTC55wapz4kvi Pq738WwtkefA56h4dOki1a4h4oFb9Iwp7vgVf++QFForJcdlg6DZgvaAwY1JVdyF gU6ClIepqQNPIcSlzvjjvqx8hu42assWYY1ZDX7GobwZxql5TFYdgb69Z6tBL+7N 4U9VJTPuYLsddbPDu2IPvWCmIGGTjD2GC7c0HqtcMZg1Kds8tklqTm/fXpQmsliK ChYBySxkSD1eeOs5ov8GDrcxOUJUkaVO3rcxKZS0NVkEkPFhFg14aJwkzsLMfMyn 5YvypryZJ5RpULHekdZNrI0vqzme5Lef6O3vGLxwjBouCGS5DW4= =LRNh -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Oct 4 06:05:45 2021 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 294C73A03EE; Mon, 4 Oct 2021 06:04:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.38.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <163335267209.3626.12893967657191265920@ietfa.amsl.com> Date: Mon, 04 Oct 2021 06:04:32 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-yang-iptfs-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2021 13:04:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : IP Traffic Flow Security YANG Module Authors : Don Fedyk Christian Hopps Filename : draft-ietf-ipsecme-yang-iptfs-01.txt Pages : 27 Date : 2021-10-04 Abstract: This document describes a yang module for the management of IP Traffic Flow Security additions to IKEv2 and IPsec. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-yang-iptfs/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-yang-iptfs-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-yang-iptfs-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 4 10:21:35 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA0A3A0A01 for ; Mon, 4 Oct 2021 10:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Mx35pE2AwGl for ; Mon, 4 Oct 2021 10:21:29 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BDB43A09FC for ; Mon, 4 Oct 2021 10:21:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 454BF182B6; Mon, 4 Oct 2021 13:29:28 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wZngyYRKgGox; Mon, 4 Oct 2021 13:29:23 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1BB98180C7; Mon, 4 Oct 2021 13:29:23 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 40C4258B; Mon, 4 Oct 2021 13:21:21 -0400 (EDT) From: Michael Richardson To: Christian Hopps , ipsec@ietf.org, Tero Kivinen In-Reply-To: References: <41C188CD-9B34-4FD9-A9B9-632C335253A4@chopps.org> <24858.42061.118149.546106@fireball.acr.fi> <24858.54291.205079.485517@fireball.acr.fi> <04158312-E6F2-4467-B435-58D77ED7435E@dell.com> <509B58FB-03A1-4C28-BE47-1E4A47478512@chopps.org> <24859.37908.612701.587580@fireball.acr.fi> <9BD66C9D-9E6C-4BEC-A71F-D74B667EA503@chopps.org> <8B9B2CB1-D470-45AD-9C9A-218FB3DBE811@chopps.org> <24859.55228.954532.765168@fireball.acr.fi> <24886.26315.915608.856404@fireball.acr.fi> <24886.30488.12451.378363@fireball.acr.fi> <3171E295-4AA1-49C2-9F27-1DD2BAC4D19A@chopps.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] iptfs publication request X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2021 17:21:34 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Christian Hopps wrote: > Will you be able to provide the text changes that would cover the iss= ue > you have? Would really like to get this submitted to IESG before > another IETF cycle completes. I also would like to see exactly what the difference is. I also would like the document submitted to the IESG. (And the IESG has become even more active, so it could still take many revisions to get to publication) =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmFbOBEACgkQgItw+93Q 3WXDQggAmCFKeTbIH0FACfukBZ65Or1yAcAFcSvHpnquMIrI7Pe+EadiNkSxJFf9 hYHoyjuiamjIiqPWIGoS8PfynJ2XE5pAENAXAPhf9FL4xRNDwYJa94KZ1Xe0Lt0P 3H81jVoYiaNgl6HUYLVGyr/w9erqDJHmoNAmQtd+SB5O3CHhxDetlRkjDTenRuYr eeG0vyeIVXTzYhVt4W5w//iZxRMaubE9C7t8J7Cv0Tk4ZdTzchw9TuZ808hr2Tpw u4iGrgKBlieT8vCCRdGDHjFzjanBmw6MRE2hkEf/EnIT/LJlvuSEXlktwzqTF28H hOCrTixK49g7RuZY1NZh3+KtrM9jLw== =Qvo4 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Oct 6 13:21:43 2021 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B50C3A08C4; Wed, 6 Oct 2021 13:21:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder_via_Datatracker?= To: Cc: draft-ietf-ipsecme-yang-iptfs.all@ietf.org, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.38.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163355168321.5236.15157145817122238419@ietfa.amsl.com> Reply-To: =?utf-8?b?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= Date: Wed, 06 Oct 2021 13:21:23 -0700 Archived-At: Subject: [IPsec] Yangdoctors early review of draft-ietf-ipsecme-yang-iptfs-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2021 20:21:26 -0000 Reviewer: Jürgen Schönwälder Review result: On the Right Track I have reviewed draft-ietf-ipsecme-yang-iptfs-01.txt. - Looking at [1], following the most popular naming scheme would suggest the title "A YANG Data Model for IP Traffic Flow Security" instead of the current title. - Never data models usually state in the abstract whether the model conforms to the Network Management Datastore Architecture (NMDA). - The document is generally well written and easy to read. Thanks for that. - Not sure what "actively published YANG modules" are. In the YANG world, we usually consider YANG modules under development not really as published. (See how 'published' is used in RFC 7950.) What you are referring to here are modules actively being worked on I think. - You import RFC 2119 terms but then I am not sure they are actually used anywhere. If you do not need RFC 2119 terms, there is also no need to import them. - It seems that [I-D.ietf-i2nsf-sdn-ipsec-flow-protection] has been published as RFC 9061, so please update your document. - "IP-TFS YANG augments IPsec YANG model from" - why not use the actual YANG module names to avoid any confusion? - I did not understand what the purpose of this is: The data model uses following constructs for configuration and management: o Configuration o Operational State The text following this is useful, but the value of the quoted text was unclear to me. - I did not understand what this text means: IP-TFS YANG augments: * Yang catalog entry for ietf-i2nsf-ike@2021-07-14.yang * Yang catalog entry for ietf-i2nsf-ikeless@20202-07-14.yang What is a Yang catalog entry for xxx and how can you augment it? - The YANG module names you are augmenting include the WG name, which is a rather weird construction and generally not recommended. I wonder how this went through. You seem to follow this and you put ipsecme into the name. Ideally, module names would be tied to a technology but not to RFCs or WGs (all of which come and go). - Copyright needs some updating... and in less than 3 months again. - You use type uint64 for counters instead of the yang:counter64 type. Is there a special reason? How would an overflow be handled? Can there be any counter discontinuities during their lifetime? - I found this: // config true; want this so we can refine? Can you elaborate what the question is here? - The congestion control leaf is an enable/disable knob. Is there exactly one and only one way to do congestion control or is there / will there be a need to be more detailed, i.e., does this have to be extensible instead of just a simple boolean? - What happens if I set use-path-mtu-discovery to true and outer-packet-size to 1234? Which takes precedence? Is it desirable to allow both to be configured? - Consider adding a units clause to l2-fixed-rate and l3-fixed-rate. - I did not extract the YANG to do syntax checking etc, I assume that the authors have a proper build automation in place (or any errors will have to be dealt with when the ID has passed WG last call). - I did not verify the xml and json examples in the appendix. However, I suggest to use documentation addresses for prefixes in the examples instead of 1.1.1.1/32 and 2.2.2.2/32 (and some may even want to see some IPv6 prefixes there as well). - Editorial fll out -> fill out Congestion Control With the -> With the [1] https://en.wikipedia.org/wiki/YANG#Standards-track_data_models From nobody Tue Oct 12 11:08:38 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC933A0477; Tue, 12 Oct 2021 11:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=labn.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZLQp0e2aEUf; Tue, 12 Oct 2021 11:08:32 -0700 (PDT) Received: from NAM04-BN8-obe.outbound.protection.outlook.com (mail-bn8nam08on2138.outbound.protection.outlook.com [40.107.100.138]) (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 730333A003C; Tue, 12 Oct 2021 11:08:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CoNELLwbV1Ruq09rmDLnTJ6BHLPurb9XXc2yAXAS13ZQcgttJv222x0UjAFl3ksqccSSCIJHudjj+/AyKMnDGPokdVY3FUIrjCEPU7EoZv9hPsos4TDlw6x7HYKFMcckhEHD6B7mP1h1OoqpzQ79N40Wp+iHbPh5ZYuTuTn7JNIzNnKVRTnGHoiEcKG8seBf5/u9W/jT5DdS/Qgju/McPppR8mBFQN5xSDfVHLpYgAGn1GLNI9q9R0QE1k8DJeUq6PXPexxo28eInM7A20AtwY7y6GbdKPshIEd6D1Ck8ysTD3ljt+IWGpkXDn/ty6Es2rF+MVRbXXO6GAV9sADRmg== 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=zj28TdLwmtSofS6JQj9OgI/OyWpEV3gPmDFZINS5eIc=; b=dc/FFcs447YSnNIOKyDpk7YxPeHIyYThHklrvm8R/3lCVSOh8C0yky3S6M/dHq2UuJDrQstIbMYMKAonVEor0njpojOHvprmPYJeRUWGCHh4QjF0GFxoGYiyJcMKoPyei+PLNZE6YGDPFmsuSwIJA4XBgOsME405MGQ5IoZAm1pFpVw2XtbKEl50i4sznlKk24o3QMpsEyLAn5+0hbUAevrbL3JKwO3mMTRQ1FP9hQfIAhxf8GbX10KYnuknmwYeJ0twBmgnRSUweqVe2paS8QyWSvadFfBVB0tvg4k6GF98t0TQnlaAf2LGC9KZA2Xm+f5QEa/nPM73OXJcTKrfvA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=labn.net; dmarc=pass action=none header.from=labn.net; dkim=pass header.d=labn.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=labn.onmicrosoft.com; s=selector2-labn-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zj28TdLwmtSofS6JQj9OgI/OyWpEV3gPmDFZINS5eIc=; b=fk8kKPPPutUcvoiuiNBMj5yv8ncwfJKWgTC+0CQflNjWRzMVoSSJQBnTPPG62GXbivD1Up1f0V3tgHzkfzQFaHxN6KjeBfsAZS+kjjL1/xFwOSWmckDORrwACX0XKeVOoedfWKCwOhHkt/DvsRqd4nHV0gkOl3KKMdraZPdFeSM= Received: from MN2PR14MB4030.namprd14.prod.outlook.com (2603:10b6:208:1dc::14) by MN2PR14MB3438.namprd14.prod.outlook.com (2603:10b6:208:1a1::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.18; Tue, 12 Oct 2021 18:08:21 +0000 Received: from MN2PR14MB4030.namprd14.prod.outlook.com ([fe80::a056:e6a5:6d4f:26e4]) by MN2PR14MB4030.namprd14.prod.outlook.com ([fe80::a056:e6a5:6d4f:26e4%4]) with mapi id 15.20.4587.026; Tue, 12 Oct 2021 18:08:20 +0000 From: Don Fedyk To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= , "yang-doctors@ietf.org" CC: "draft-ietf-ipsecme-yang-iptfs.all@ietf.org" , "ipsec@ietf.org" Thread-Topic: Yangdoctors early review of draft-ietf-ipsecme-yang-iptfs-01 Thread-Index: AQHXuu/CvHm7JIAFvUO+xaQzasOYV6vHxqvQ Date: Tue, 12 Oct 2021 18:08:20 +0000 Message-ID: References: <163355168321.5236.15157145817122238419@ietfa.amsl.com> In-Reply-To: <163355168321.5236.15157145817122238419@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=labn.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 64b72c2f-f1fe-4a97-6186-08d98dab4661 x-ms-traffictypediagnostic: MN2PR14MB3438: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /4N8jKaUjfdRigM48tAC5D7B/EbRLQAyhSbl7C4LYzqyx3gCIYUeDpYwmUKUwxKgKP1ePzwbODx4dY5P7fH+xc3ZFFwMvVLLfpvd5olag2HuNoC600XLov0r1OlpzawDIf5Ku0XtFUvOIMy+dj6ijrcs7Pt7bAsLI3iU5s193czoizCeIlupokZk6gIDrMSWDnzB3kjoVE/KSHbZgNHoxSq+TQI8yO1i0VgfnO35CkOL90F4NjmjsaAxc8vf8vJZvoruH6pDM8gwXpB+YQOZBm8oRpWWN/csPwebPn82Vrue/kmMQf6dA1iZQ7bFeML1pAyFxiJSSN3ls0EPCoFEmNHIkuNaQr0BElpISrzLe+VA7YDy/cyKQ9i1pgC1jvzsbv1MlSFEss8QukBJzAqf9ClVxPuGr2OPIz7r/vyiViWTyzIybj/ENWsLOAfENh0wA2qNCyqfN9YenrhKF1LGavbuYbBUOZNnQ4CJhjAaawFkIg2chss2qoXQwgdp1ch9ov66Ux04yANOQjBwxTh5ScxxpkswxapAYQkRcjirql5IdCPc1q6W42kvr0Ll6aWbIh++6f9ilemSel6G/qmPjjDCVB9Sgm6vHzl8PasDYhz1hHbml68r5IJYoeaKeF/BR1lu4dvoyy5R/NPaKzrFIOcdYXIw0giuznenyGodtZbu6mCkS/zvhH2GTxx5fXRePB8ivz7UlAGCgXMh0W2Z+1od7Au+8BlMYyyGU1hf52dkILF9yKl1wMEU7m2GzJgTs2cY2rkzQje2cUa0A376HIKtcvDyTgm44RBCJ+o6PwJzcIDMlN6E27NrKVrnM8WM x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR14MB4030.namprd14.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(376002)(39830400003)(366004)(396003)(346002)(122000001)(316002)(66574015)(110136005)(9686003)(5660300002)(33656002)(54906003)(83380400001)(38100700002)(55016002)(26005)(6506007)(86362001)(52536014)(2906002)(8676002)(4326008)(64756008)(66476007)(66946007)(508600001)(53546011)(76116006)(7696005)(71200400001)(966005)(186003)(8936002)(66446008)(66556008)(38070700005)(21314003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?MVgxUkY2YUJQMFdwcnJMWHlnTWdWVjBrWFp3NU1VbFdrOHV6aTJvbnF5a3Yw?= =?utf-8?B?U0hvQTZmQ3B0YzNIU1N3bUZkRncwQ1BJYUR1ZXRQcE9tcHRWOUhacnZBSk9E?= =?utf-8?B?YTFzWk85S25rb1ZEaVZ1cmZHbDhYMytIdThrdzdSU2FyMVRKUDBQUFR4TVBS?= =?utf-8?B?SXRtZElNNlVHL3hoTnFLOTRqRk5acFFIamh4UlNZNnc2N2orMktQMzV3V0tj?= =?utf-8?B?Umgya0dxdS9ublYzYnM4UVRhSlVJZjhyN3FDSHJvQVN6SUJsTGUyaHpGTlVP?= =?utf-8?B?dFBLdnJEZHRtZElRZzdxMy90T3hCeFRmRVkwZUR4ekRKTGZ0NEF1RlpSOEVW?= =?utf-8?B?bWZ5SkFpcVpBZDlhbjV6eld5YnBKNUVQQy9jd2UxZ0VodEFPUFlpN2t3Y083?= =?utf-8?B?REgyalRRd1NUVXRWSjlsL0ZSL1dreTdobGdnMisyMXhrelFNWjZIZUZ0NmtN?= =?utf-8?B?dUplQ1dCTm1QMjRTcENhSWd1bHNicDQxbnhIanpKZnM0RUZ4ZC8xUlFmMEYz?= =?utf-8?B?K1hxL0xIQzJwaldIYWEzQ1pFL09tY1JkSjhsYWVtUnBUQUE2MHBjdWdvSWkz?= =?utf-8?B?K3pLZEF3NjV6Tk1udEl3cmJVOVFyY3R5VFpMcHN4dFMyVVBram5sRVJWeFUr?= =?utf-8?B?T3ZnMnM0dWI3VFhLV1NleVBxeFFYV1FCZm9aVk5FUWpHa3ZMbkFLVEExQ2s4?= =?utf-8?B?TE4vZzN4dTlUb1JvMzRySHRwSjZpUkVKdUQ4aUFoTDB2cTQ3MlAvMU8weDNB?= =?utf-8?B?ZDNlK09hdG9EUlIrNzgxbXU2NUZqcnlSdkcrYnB3bjJFbk9vaDNxUEZwY3M3?= =?utf-8?B?RUNVZFp3SFc2THI4MjNSZW5FMy9FNGlqSTAxd29rV2pkdkxZU3NKN1diSlhi?= =?utf-8?B?ejVkOWQ4T3dBZFZpNm1xN0VXUXFLS2hQQUhBSk93ZnZuNjlBSnk0eHU3WjUw?= =?utf-8?B?WjYzd1plNmwyby9oL3lpWXk5UE5IRkM4M095UHY5OUx3clpiOFNUZXd0ZVlB?= =?utf-8?B?d3hSbmIwa3N4YlgySHgzcHZmNUJmR1VpR0xYbmsvVHJuS1ZGbkJqWGVXQkpw?= =?utf-8?B?SFBSaElJeWdsak9yb3N6ZjV3bVlraWxOaGpWSGF4RThDdEgxOTNpRXkxLyt6?= =?utf-8?B?bGRxd1JKNC9KdnlwZVVpSXpYTmRZWkVIQ2wrMFAyYlk5d2FGU3lrS0k1SGxv?= =?utf-8?B?OTZVZFpFSDY1VmN4ODQ1TmphVDRaYy8wcGwzVVg2cWFvdXh3cjhNendyZGlU?= =?utf-8?B?UkVFVjlPZ2J2WWl0NlVuN09RdEd6QkdVQS91eW8vL0pMY0tpTTkwa3g2Nk5Z?= =?utf-8?B?QTlTSHFZREtzQ3ZFRVdpdEpNSnFxd0lZSzArVHJ3L2haREZiNkJ0QjZSNHVh?= =?utf-8?B?MU5rZGJwMHBDQ1ZIaHpOeUdnVytQd0IyYXpycmZvdVI3M3lhT2xLSGFOS1Z0?= =?utf-8?B?a2hxemFTM2hkdnJYNFZKVllnWXRMSGkvRFJJUkZRWnNwbWRnQVZORkdrWStz?= =?utf-8?B?ZkFHZ0RaTCtBMzRxVWVrWjhNOXBBekZEb3JRMkVqSVlLRjBDeFJ2VTJZRWZS?= =?utf-8?B?RkF4dzMyeXF1QVFxZ201MEZDcUY5VWQ5UWI5S0YzNHBXZzI5MXRhdWF4V25G?= =?utf-8?B?VEFpcHBjWE92eEdHZTlCcDhCNUdlaDExR1VpMy9aUFVNdG9kdGt0d2lwdTBi?= =?utf-8?B?TmE5ejZGRi96QS9ZdE14VzY0WU8xZTU0RkY0SzR0clMwNWV3cEhnMSt0Nm5j?= =?utf-8?Q?QYSAQJUYiNhPMxVMZ95pW4ZUWzzLpnVNchIGbbq?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: labn.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR14MB4030.namprd14.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 64b72c2f-f1fe-4a97-6186-08d98dab4661 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2021 18:08:20.7086 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: eb60ac54-2184-4344-9b60-40c8b2b72561 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: UhpCFpdHpgZTnwjpPwl1byuaJ8QKVrRANeaCMrXR1o6TLABBkxK7uU8jxlvbAsT3tZBrPaCGqFyyXT/eCzwIdA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR14MB3438 Archived-At: Subject: Re: [IPsec] Yangdoctors early review of draft-ietf-ipsecme-yang-iptfs-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2021 18:08:38 -0000 SGkgSsO8cmdlbg0KDQpUaGFua3MgZm9yIHRoZSBSZXZpZXcuIE1vc3QgY29tbWVudHMgYXJlIGFu IGVhc3kgQWNjZXB0LiANClJlc3BvbnNlIG9uIGludGVudCBhcmUgaW5saW5lIERvbjoNCg0KQ2hl ZXJzDQpEb24NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSsO8cmdlbiBT Y2jDtm53w6RsZGVyIHZpYSBEYXRhdHJhY2tlciA8bm9yZXBseUBpZXRmLm9yZz4gDQpTZW50OiBX ZWRuZXNkYXksIE9jdG9iZXIgNiwgMjAyMSA0OjIxIFBNDQpUbzogeWFuZy1kb2N0b3JzQGlldGYu b3JnDQpDYzogZHJhZnQtaWV0Zi1pcHNlY21lLXlhbmctaXB0ZnMuYWxsQGlldGYub3JnOyBpcHNl Y0BpZXRmLm9yZw0KU3ViamVjdDogWWFuZ2RvY3RvcnMgZWFybHkgcmV2aWV3IG9mIGRyYWZ0LWll dGYtaXBzZWNtZS15YW5nLWlwdGZzLTAxDQoNClJldmlld2VyOiBKw7xyZ2VuIFNjaMO2bnfDpGxk ZXINClJldmlldyByZXN1bHQ6IE9uIHRoZSBSaWdodCBUcmFjaw0KDQpJIGhhdmUgcmV2aWV3ZWQg ZHJhZnQtaWV0Zi1pcHNlY21lLXlhbmctaXB0ZnMtMDEudHh0Lg0KDQotIExvb2tpbmcgYXQgWzFd LCBmb2xsb3dpbmcgdGhlIG1vc3QgcG9wdWxhciBuYW1pbmcgc2NoZW1lIHdvdWxkDQogIHN1Z2dl c3QgdGhlIHRpdGxlICJBIFlBTkcgRGF0YSBNb2RlbCBmb3IgSVAgVHJhZmZpYyBGbG93IFNlY3Vy aXR5Ig0KICBpbnN0ZWFkIG9mIHRoZSBjdXJyZW50IHRpdGxlLg0KRG9uOiAgQWNjZXB0DQoNCi0g TmV3ZXIgZGF0YSBtb2RlbHMgdXN1YWxseSBzdGF0ZSBpbiB0aGUgYWJzdHJhY3Qgd2hldGhlciB0 aGUgbW9kZWwNCiAgY29uZm9ybXMgdG8gdGhlIE5ldHdvcmsgTWFuYWdlbWVudCBEYXRhc3RvcmUg QXJjaGl0ZWN0dXJlIChOTURBKS4NCkRvbjogQWNjZXB0IFdlIHN1cHBvcnQgTk1EQS4NCg0KLSBU aGUgZG9jdW1lbnQgaXMgZ2VuZXJhbGx5IHdlbGwgd3JpdHRlbiBhbmQgZWFzeSB0byByZWFkLiBU aGFua3MgZm9yDQogIHRoYXQuDQoNCi0gTm90IHN1cmUgd2hhdCAiYWN0aXZlbHkgcHVibGlzaGVk IFlBTkcgbW9kdWxlcyIgYXJlLiBJbiB0aGUgWUFORw0KICB3b3JsZCwgd2UgdXN1YWxseSBjb25z aWRlciBZQU5HIG1vZHVsZXMgdW5kZXIgZGV2ZWxvcG1lbnQgbm90IHJlYWxseQ0KICBhcyBwdWJs aXNoZWQuIChTZWUgaG93ICdwdWJsaXNoZWQnIGlzIHVzZWQgaW4gUkZDIDc5NTAuKSBXaGF0IHlv dQ0KICBhcmUgcmVmZXJyaW5nIHRvIGhlcmUgYXJlIG1vZHVsZXMgYWN0aXZlbHkgYmVpbmcgd29y a2VkIG9uIEkgdGhpbmsuDQpEb246IEFjY2VwdA0KDQotIFlvdSBpbXBvcnQgUkZDIDIxMTkgdGVy bXMgYnV0IHRoZW4gSSBhbSBub3Qgc3VyZSB0aGV5IGFyZSBhY3R1YWxseQ0KICB1c2VkIGFueXdo ZXJlLiBJZiB5b3UgZG8gbm90IG5lZWQgUkZDIDIxMTkgdGVybXMsIHRoZXJlIGlzIGFsc28gbm8N CiAgbmVlZCB0byBpbXBvcnQgdGhlbS4NCkRvbjogV2lsbCBjaGVjay4NCg0KLSBJdCBzZWVtcyB0 aGF0IFtJLUQuaWV0Zi1pMm5zZi1zZG4taXBzZWMtZmxvdy1wcm90ZWN0aW9uXSBoYXMgYmVlbg0K ICBwdWJsaXNoZWQgYXMgUkZDIDkwNjEsIHNvIHBsZWFzZSB1cGRhdGUgeW91ciBkb2N1bWVudC4N CkRvbjogSSB0aGluayBJIG1pc3NlZCB1cGRhdGluZyBhIHRleHQgcmVmZXJlbmNlIHRoZSBSRkMg cmVmZXJlbmNlIHdhcyB1cGRhdGVkIGF1dG9tYXRpY2FsbHkuIA0KDQoNCi0gIklQLVRGUyBZQU5H IGF1Z21lbnRzIElQc2VjIFlBTkcgbW9kZWwgZnJvbSIgLSB3aHkgbm90IHVzZSB0aGUNCiAgYWN0 dWFsIFlBTkcgbW9kdWxlIG5hbWVzIHRvIGF2b2lkIGFueSBjb25mdXNpb24/DQpEb246IEFjY2Vw dC4gDQoNCi0gSSBkaWQgbm90IHVuZGVyc3RhbmQgd2hhdCB0aGUgcHVycG9zZSBvZiB0aGlzIGlz Og0KDQogICBUaGUgZGF0YSBtb2RlbCB1c2VzIGZvbGxvd2luZyBjb25zdHJ1Y3RzIGZvciBjb25m aWd1cmF0aW9uIGFuZA0KICAgbWFuYWdlbWVudDoNCg0KICAgbyBDb25maWd1cmF0aW9uDQoNCiAg IG8gT3BlcmF0aW9uYWwgU3RhdGUNCg0KICBUaGUgdGV4dCBmb2xsb3dpbmcgdGhpcyBpcyB1c2Vm dWwsIGJ1dCB0aGUgdmFsdWUgb2YgdGhlIHF1b3RlZCB0ZXh0DQogIHdhcyB1bmNsZWFyIHRvIG1l Lg0KRG9uOiBXZSBjYW4gcmVtb3ZlLiANCg0KLSBJIGRpZCBub3QgdW5kZXJzdGFuZCB3aGF0IHRo aXMgdGV4dCBtZWFuczoNCg0KICAgSVAtVEZTIFlBTkcgYXVnbWVudHM6DQoNCiAgICogIFlhbmcg Y2F0YWxvZyBlbnRyeSBmb3IgaWV0Zi1pMm5zZi1pa2VAMjAyMS0wNy0xNC55YW5nDQoNCiAgICog IFlhbmcgY2F0YWxvZyBlbnRyeSBmb3IgaWV0Zi1pMm5zZi1pa2VsZXNzQDIwMjAyLTA3LTE0Lnlh bmcNCg0KICBXaGF0IGlzIGEgWWFuZyBjYXRhbG9nIGVudHJ5IGZvciB4eHggYW5kIGhvdyBjYW4g eW91IGF1Z21lbnQgaXQ/DQpEb246IEkgdGhpbmsgd2Ugc2hvdWxkIGp1c3Qgc2F5IE1vZGVsIG5v dCBjYXRhbG9nIGhlcmUuIA0KDQotIFRoZSBZQU5HIG1vZHVsZSBuYW1lcyB5b3UgYXJlIGF1Z21l bnRpbmcgaW5jbHVkZSB0aGUgV0cgbmFtZSwgd2hpY2gNCiAgaXMgYSByYXRoZXIgd2VpcmQgY29u c3RydWN0aW9uIGFuZCBnZW5lcmFsbHkgbm90IHJlY29tbWVuZGVkLiBJDQogIHdvbmRlciBob3cg dGhpcyB3ZW50IHRocm91Z2guIFlvdSBzZWVtIHRvIGZvbGxvdyB0aGlzIGFuZCB5b3UgcHV0DQog IGlwc2VjbWUgaW50byB0aGUgbmFtZS4gSWRlYWxseSwgbW9kdWxlIG5hbWVzIHdvdWxkIGJlIHRp ZWQgdG8gYQ0KICB0ZWNobm9sb2d5IGJ1dCBub3QgdG8gUkZDcyBvciBXR3MgKGFsbCBvZiB3aGlj aCBjb21lIGFuZCBnbykuDQpEb246IFdpbGwgcmV2aXNpdCBuYW1pbmcuIA0KDQotIENvcHlyaWdo dCBuZWVkcyBzb21lIHVwZGF0aW5nLi4uIGFuZCBpbiBsZXNzIHRoYW4gMyBtb250aHMgYWdhaW4u DQpEb246IEFjY2VwdA0KDQotIFlvdSB1c2UgdHlwZSB1aW50NjQgZm9yIGNvdW50ZXJzIGluc3Rl YWQgb2YgdGhlIHlhbmc6Y291bnRlcjY0DQogIHR5cGUuIElzIHRoZXJlIGEgc3BlY2lhbCByZWFz b24/IEhvdyB3b3VsZCBhbiBvdmVyZmxvdyBiZSBoYW5kbGVkPw0KICBDYW4gdGhlcmUgYmUgYW55 IGNvdW50ZXIgZGlzY29udGludWl0aWVzIGR1cmluZyB0aGVpciBsaWZldGltZT8NCg0KLSBJIGZv dW5kIHRoaXM6DQoNCiAgICAgICAgIC8vIGNvbmZpZyB0cnVlOyB3YW50IHRoaXMgc28gd2UgY2Fu IHJlZmluZT8NCiAgQ2FuIHlvdSBlbGFib3JhdGUgd2hhdCB0aGUgcXVlc3Rpb24gaXMgaGVyZT8N CkRvbjogSSB3aWxsIGNoZWNrIGFuZCB1cGRhdGUgSSB0aGluayB0aGlzIGEgc2ltcGx5IHNheWlu ZyB0aGF0IHdlIGZvdW5kIGNvbmZpZyB0cnVlIGhhZCB0byBiZSBzZXQNClNvIHRoYXQgYSByZWZp bmUgY291bGQgYmUgZG9uZS4NCg0KLSBUaGUgY29uZ2VzdGlvbiBjb250cm9sIGxlYWYgaXMgYW4g ZW5hYmxlL2Rpc2FibGUga25vYi4gSXMgdGhlcmUNCiAgZXhhY3RseSBvbmUgYW5kIG9ubHkgb25l IHdheSB0byBkbyBjb25nZXN0aW9uIGNvbnRyb2wgb3IgaXMgdGhlcmUgLw0KICB3aWxsIHRoZXJl IGJlIGEgbmVlZCB0byBiZSBtb3JlIGRldGFpbGVkLCBpLmUuLCBkb2VzIHRoaXMgaGF2ZSB0byBi ZQ0KICBleHRlbnNpYmxlIGluc3RlYWQgb2YganVzdCBhIHNpbXBsZSBib29sZWFuPw0KRG9uOiBX ZSBkb24ndCBoYXZlIGEgY29uZ2VzdGlvbiBtZWNoYW5pc20gZm9yIElQLVRGUyBidXQgaW5zdGVh ZCBhIGtub2IgdGhhdCBpdCANCnN1cHBvcnQgdW5kZXJseWluZyBtZWNoYW5pc21zLiANCg0KLSBX aGF0IGhhcHBlbnMgaWYgSSBzZXQgdXNlLXBhdGgtbXR1LWRpc2NvdmVyeSB0byB0cnVlIGFuZA0K ICBvdXRlci1wYWNrZXQtc2l6ZSB0byAxMjM0PyBXaGljaCB0YWtlcyBwcmVjZWRlbmNlPyBJcyBp dCBkZXNpcmFibGUNCiAgdG8gYWxsb3cgYm90aCB0byBiZSBjb25maWd1cmVkPw0KRG9uOiBUaGUg ZGVzY3JpcHRpb24gc2F5cyB0aGF0IHVzZS1wYXRoLW10dS1kaXNjb3ZlcnkgdGFrZXMgcHJlY2Vk ZW5jZQ0KT3ZlciB2YWx1ZXMgaWYgdGhlIG91dGVyIHBhY2tldCBzaXplIGlzIGdyZWF0ZXIgdGhh dCB0aGUgTVRVIGRpc2NvdmVyeSB2YWx1ZS4gDQpJIHRoaW5rIHRoaXMgd29ya3MgZm9yIGFsbCBj YXNlcy4gDQotIENvbnNpZGVyIGFkZGluZyBhIHVuaXRzIGNsYXVzZSB0byBsMi1maXhlZC1yYXRl IGFuZCBsMy1maXhlZC1yYXRlLg0KRG9uOiBBY2NlcHQuDQoNCi0gSSBkaWQgbm90IGV4dHJhY3Qg dGhlIFlBTkcgdG8gZG8gc3ludGF4IGNoZWNraW5nIGV0YywgSSBhc3N1bWUgdGhhdA0KICB0aGUg YXV0aG9ycyBoYXZlIGEgcHJvcGVyIGJ1aWxkIGF1dG9tYXRpb24gaW4gcGxhY2UgKG9yIGFueSBl cnJvcnMNCiAgd2lsbCBoYXZlIHRvIGJlIGRlYWx0IHdpdGggd2hlbiB0aGUgSUQgaGFzIHBhc3Nl ZCBXRyBsYXN0IGNhbGwpLg0KDQotIEkgZGlkIG5vdCB2ZXJpZnkgdGhlIHhtbCBhbmQganNvbiBl eGFtcGxlcyBpbiB0aGUgYXBwZW5kaXguIEhvd2V2ZXIsDQogIEkgc3VnZ2VzdCB0byB1c2UgZG9j dW1lbnRhdGlvbiBhZGRyZXNzZXMgZm9yIHByZWZpeGVzIGluIHRoZQ0KICBleGFtcGxlcyBpbnN0 ZWFkIG9mIDEuMS4xLjEvMzIgYW5kIDIuMi4yLjIvMzIgKGFuZCBzb21lIG1heSBldmVuDQogIHdh bnQgdG8gc2VlIHNvbWUgSVB2NiBwcmVmaXhlcyB0aGVyZSBhcyB3ZWxsKS4NCkRvbi4gQWNjZXB0 Lg0KDQotIEVkaXRvcmlhbA0KDQogIGZsbCBvdXQgLT4gZmlsbCBvdXQNCg0KICBDb25nZXN0aW9u IENvbnRyb2wgV2l0aCB0aGUgLT4gV2l0aCB0aGUNCkRvbiAtIFdpbGwgdXBkYXRlLg0KDQpbMV0g aHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvWUFORyNTdGFuZGFyZHMtdHJhY2tfZGF0YV9t b2RlbHMNCg0KDQoNCg== From nobody Fri Oct 15 15:41:53 2021 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE6F3A0DC9; Fri, 15 Oct 2021 15:34:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: ipsec@ietf.org, kaduk@mit.edu X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163433724136.17026.16741745367119767233@ietfa.amsl.com> Date: Fri, 15 Oct 2021 15:34:01 -0700 Archived-At: Subject: [IPsec] ipsecme - Requested session has been scheduled for IETF 112 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2021 22:34:14 -0000 Dear Tero Kivinen, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. ipsecme Session 1 (2:00 requested) Monday, 8 November 2021, Session I 1200-1400 Room Name: Room 6 size: 506 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/112/sessions/ipsecme.ics Request Information: --------------------------------------------------------- Working Group Name: IP Security Maintenance and Extensions Area Name: Security Area Session Requester: Tero Kivinen Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 30 Conflicts to Avoid: People who must be present: Benjamin Kaduk Tero Kivinen Yoav Nir Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Oct 18 02:29:12 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9C33A127A for ; Mon, 18 Oct 2021 02:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCQD6i9eqGnt for ; Mon, 18 Oct 2021 02:29:07 -0700 (PDT) Received: from gg.genua.de (gg-0.genua.de [80.154.94.10]) (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 C37943A11EF for ; Mon, 18 Oct 2021 02:29:05 -0700 (PDT) Received: from gg.genua.de (localhost [127.0.0.1]) by gg.genua.de (Postfix) with ESMTP id BDA5333F0E5; Mon, 18 Oct 2021 11:28:59 +0200 (CEST) Received: (from localhost) by gg.genua.de (MSCAN) id 5/gg.genua.de/smtp-gw/mscan; Mon Oct 18 11:28:59 2021 From: Daniel Herzinger To: "ipsec@ietf.org" CC: "ietf@gazdag.de" Thread-Topic: Cost-efficient quantum-resistant DoS protection Thread-Index: AQHXxAHuDuDAcAFigkC0od08vH3ixQ== Date: Mon, 18 Oct 2021 09:28:47 +0000 Message-ID: <935923623769463b80caf7b64bfe430a@genua.de> Accept-Language: de-DE, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.217.185] MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="----B1918C090D21F57B1DE3CFAB7C13D63E" Archived-At: Subject: [IPsec] Cost-efficient quantum-resistant DoS protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2021 09:29:10 -0000 ------B1918C090D21F57B1DE3CFAB7C13D63E Content-Language: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, in response to the new version of draft-ietf-ipsecme-ikev2-multiple-ke-04.t= xt, we wanted to emphasize the issue of DoS attacks during intermediate exc= hanges. The new version does address it by mentioning the option of simply = avoiding intermediate exchanges altogether but still require additional key= exchanges. Yet, this protects only against record-and-harvest attacks but = not against an attacker with a strong quantum computer at the time of the h= andshake, regardless of quantum-resistant authentication (since they can br= eak the initial shared secret and therefore recalculate the MAC which authe= nticates the followup exchanges, fully establishing a man-in-the-middle). W= e doubt that an attacker, even with a strong quantum computer, is able to b= reak a key exchange in such a short time period. Still, this assumption is = too theoretical to rely on. This, together with the fact that Group-IKE is = incompatible with key exchanges during followup exchanges, makes the option= seem inferior to just sticking to intermediate exchanges during the handsh= ake. However, we must also consider the draft-tjhai-ikev2-beyond-64k-limit-= 01.txt. An attacker who exploits the large key exchanges, e.g., by requesting seven= additional maximum size McEliece key exchanges, can force a gateway to acc= ept and process 1.4MB of data per McEliece KEM. This leaves us at a situati= on where we must pick one of the following options: 1. Accept the highly increased risk of DoS attacks. 2. Prohibit the use of large KE payloads, hence the McEliece mechanism. 3. Prohibit the use of intermediate exchanges, leaving the IKE SA initiall= y unprotected and being vulnerable to an attacker with a quantum computer d= uring the handshake. To us, none of these options seems desirable. Thus, we propose another solu= tion which sees one new transform type, e.g., SNTRUP761X25519, which then d= efines a combination of one classical algorithm (like ECDH based on curve25= 519) and one pqc algorithm which fits into IKE_SA_INIT without fragmentatio= n (like sntruprime761). The two secrets get concatinated and then fed to a = hash function. The resulting hash is used as the shared secret for further = key derivation. This mechanism is low effort in terms of implementation and= does not affect the state machine at all, but already offers a high level = of protection against all attacks as long as there is no major break-throug= h in cryptanalysis. Furthermore, it is the accepted approach for most of th= e applications of post-quantum key exchanges. For higher long-term security= , it can be combined with other, more conventional algorithms which follow = either in intermediate or followup exchanges. We then propose to restrict the use of large key exchanges to the context o= f option 3, which removes the risk of the described DoS attacks. Yet, to pr= event the insecurities of plain option 3, we also propose to make it mandat= ory to combine it with the new hybrid transform type, i.e., SNTRUP761X25519= . The only downside of this approach is that G-IKE is then incompatible with = the McEliece exchange. However, the fact that G-IKE exchanges sensitive inf= ormation before authentication makes it impossible to be not vulnerable aga= inst the discussed DoS attack and, at the same time, support the McEliece a= lgorithm. Thus, we see that as a decision to be made in the G-IKE standardi= zation track, not in IKEv2. Regards, Stefan-Lukas Gazdag, Daniel Herzinger= ------B1918C090D21F57B1DE3CFAB7C13D63E Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIU+QYJKoZIhvcNAQcCoIIU6jCCFOYCAQExDTALBglghkgBZQMEAgEwCwYJKoZI hvcNAQcBoIIRQDCCBA4wggL2oAMCAQICAw/drDANBgkqhkiG9w0BAQsFADBFMQsw CQYDVQQGEwJERTEVMBMGA1UECgwMRC1UcnVzdCBHbWJIMR8wHQYDVQQDDBZELVRS VVNUIFJvb3QgQ0EgMyAyMDEzMB4XDTEzMDkyMDA4MjU1MVoXDTI4MDkyMDA4MjU1 MVowRTELMAkGA1UEBhMCREUxFTATBgNVBAoMDEQtVHJ1c3QgR21iSDEfMB0GA1UE AwwWRC1UUlVTVCBSb290IENBIDMgMjAxMzCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAMR7QpKCH+ztVJiOEsDKCd+TbjqTXBvkEHeeTmmIbPbhafL2m6Jh sb0HIHSYZfGMJgjNqDXKgDbRY23oRHqCw2xe3rvoNtLEaDaMnzK9hCLg3MLuEEY5 ba+TOa6H5sO8Ccksa2db2Zt2dUwL4LvF17w+efJfvtGQV/mu9mZfMb/TbY+nukrz I2W7t++jJdcK6li274j6+nmyUljV8KyMoVF0KZWqUTuQMgOfHHJ0kN497WHS5eP9 ZEflubdKqfcfrpaGBKwv46SBd7daFv/YDz/2t3jMpK/6WzwSW6hSiXLviPPVRIGG lSOfe9282TTvfJQ8qsBBwuOdUBrA5Bki/LMCAwEAAaOCAQUwggEBMA8GA1UdEwEB /wQFMAMBAf8wHQYDVR0OBBYEFD+QyH3HFW/zJI+pwy9Log8hsi/nMA4GA1UdDwEB /wQEAwIBBjCBvgYDVR0fBIG2MIGzMHSgcqBwhm5sZGFwOi8vZGlyZWN0b3J5LmQt dHJ1c3QubmV0L0NOPUQtVFJVU1QlMjBSb290JTIwQ0ElMjAzJTIwMjAxMyxPPUQt VHJ1c3QlMjBHbWJILEM9REU/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDA7oDmg N4Y1aHR0cDovL2NybC5kLXRydXN0Lm5ldC9jcmwvZC10cnVzdF9yb290X2NhXzNf MjAxMy5jcmwwDQYJKoZIhvcNAQELBQADggEBAA5ZDljkdEgjRM80IbWcFBqtmku3 s4htXKkXcPAqn417+XuF+sc56BAIsDUrX88C0tOcyAse7gVUrjeTBAl9bI/CdLz4 HJS+MQFALfMkILeEVSxcyPV0ShAZi6PH7TXWCUjTDsC6OaiwRgKw28aIWcK+/Hux K89+YodVlswBb5tnIZU1i/gQ/HEbt0s3aaY71uyL7sGw8yXJj5J9oerDykS/JqV0 kpzjdOuddNnLTYfY/LRpbIugQwdgeJfp2ZN8wka8mzdSo+2KPBOpe1NLSZoRBSwL blasHy6CbOBpZ7UObS3Z5MAV8T/6GHLhFW0nWy0wKCufSJpkK5nv8nVJX1wwggT0 MIID3KADAgECAgMP4PYwDQYJKoZIhvcNAQELBQAwRTELMAkGA1UEBhMCREUxFTAT BgNVBAoMDEQtVHJ1c3QgR21iSDEfMB0GA1UEAwwWRC1UUlVTVCBSb290IENBIDMg MjAxMzAeFw0xMzA5MjcwNzMwNDBaFw0yODA5MjAwODI1NTFaMFsxCzAJBgNVBAYT AkRFMRUwEwYDVQQKDAxELVRydXN0IEdtYkgxNTAzBgNVBAMMLEQtVFJVU1QgQXBw bGljYXRpb24gQ2VydGlmaWNhdGVzIENBIDMtMSAyMDEzMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAsL/U1GFo1h3boKtaIzrEMPZHGI4FKLKLkjWJZYh1 CSa4URX8j52diNu1tmcTpwKOMiv03awa2lEElvrqVEhpMHOxK42q7WG7c4d0lkc7 d+cTrexeZlGAZ8rIsXcASttIf0106PkzjHclKZrJ6iN11ToWkjpPBsE9THKJ/2aw tRHDVQTq5Ode7n1aGay3/nNIeMf1ALe4Q93Xx2glcXU0ZgLPftRQKJF5ql800EgW WPe+tHArNBWzPh+NhoMzKfghnR+kPyUiFHd+ZzU+FU1XAvrqw3UAzPhp4vTKVXS+ IgqE9bRZW5CzBnXyZPFFtbuA3UJHPwKnS0bHNrw6DxIjrwIDAQABo4IB1TCCAdEw HwYDVR0jBBgwFoAUP5DIfccVb/Mkj6nDL0uiDyGyL+cwQgYIKwYBBQUHAQEENjA0 MDIGCCsGAQUFBzABhiZodHRwOi8vcm9vdC1jYS0zLTIwMTMub2NzcC5kLXRydXN0 Lm5ldDBmBgNVHSAEXzBdMFsGCysGAQQBpTQCgUgBMEwwSgYIKwYBBQUHAgEWPmh0 dHA6Ly93d3cuZC10cnVzdC5uZXQvaW50ZXJuZXQvZmlsZXMvRC1UUlVTVF9Sb290 X1BLSV9DUFMucGRmMIG+BgNVHR8EgbYwgbMwdKByoHCGbmxkYXA6Ly9kaXJlY3Rv cnkuZC10cnVzdC5uZXQvQ049RC1UUlVTVCUyMFJvb3QlMjBDQSUyMDMlMjAyMDEz LE89RC1UcnVzdCUyMEdtYkgsQz1ERT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0 MDugOaA3hjVodHRwOi8vY3JsLmQtdHJ1c3QubmV0L2NybC9kLXRydXN0X3Jvb3Rf Y2FfM18yMDEzLmNybDAdBgNVHQ4EFgQUGQOq2SJFxxpiqedcmbCd3u3UuLUwDgYD VR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwDQYJKoZIhvcNAQELBQAD ggEBABCOUPipaQNkTuhlpNOQk8lDCndO0Y9nuN8+Y99m/odfdUDN2MmOg0ICPVWN yg9bIHfxytRkNlFzCrc7B9KmzPAAiu7UwOXl3dnRrFJpluGcAbnDGRr1Ssgvb2HD mZwlU2K7TpMOt6XayFkiefx5q4WC67BbVcIPD1IZ2te0HRdmdh7zhIz2Hw1+bfuz zSNf8/JRYojIyweGq9uDue45yhVDl86O3GJaOphjDVm5c7mTdWg1xbJ244PhmpQH 3h1s+kfD76rg4mwAIQa3QkfX2BqMEc9ASiWm1L9iNA0Z4ng9tiuVm4LJKPVA2lZp px7+KtmVmv0/lv+8eGKwPvw1HlUwgggyMIIHGqADAgECAhBrvsOl+goq9gVz/cEm 7sAlMA0GCSqGSIb3DQEBCwUAMFsxCzAJBgNVBAYTAkRFMRUwEwYDVQQKDAxELVRy dXN0IEdtYkgxNTAzBgNVBAMMLEQtVFJVU1QgQXBwbGljYXRpb24gQ2VydGlmaWNh dGVzIENBIDMtMSAyMDEzMB4XDTIxMDkyMjE4NDExMloXDTIyMDkyNTE4NDExMlow gaoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpnZW51YSBHbWJIMRkwFwYDVQQDExBE YW5pZWwgSGVyemluZ2VyMR4wHAYDVQQHDBVLaXJjaGhlaW0gYi4gTcO8bmNoZW4x DzANBgNVBCoTBkRhbmllbDESMBAGA1UEBBMJSGVyemluZ2VyMRUwEwYDVQQFEwxD U00wMjc2MjM1OTgxDzANBgNVBAgTBkJheWVybjCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBANqB5XCDmCsmv/nQdEpNf/77grsLiU23WXuM/5tfgBcBd8JZ Dv8r6GijQtSPZHj4nFKbkewHlJgFCGd20NtFMEi0rFnkDfJtFKsd7gZH+9yDdBWx btne1PiNhtgu3urLBs9gwUpBSrZSGo1L64PbKO3gxiBWzvF+ysTyBjYZ0MEhIolX nufVeLla5a3RQGFLqN2wJN5KwiPnix8x/iU0WELposT00Hw+vqX7geZmZkzHUO9a wgdpXx9LfmS5MQ/QSM8Pdjodzn/JGp6iLYlScsRQPlzlVKBJaGTiddRGkLgRpq5n av9loMUgD84JDbuVPPZ/keEvAzx6jS5688aa/TV+qBuNrC9DfpcrgKMVV4FEyBz5 dKKiPDtc3qLUFWLCQ0xBv0AH9VtT4LpbngPVU6xUXSvu30k+wrQosyD12hKxSNld cOkI2P1M0XG9lSW2PJRLJRSj7hrEAYm1zBpN7av232hG5DMx9lgOjfcv/6yIsO0p DFUNHfngOEDnctgNtFQrHNVlXWjGlycmedosZ6+QdfolaFyuLkksFkaayGcUFmde IGTL/9aMqIs6qX9ji8s/wEcwnNZwJoJnGOt8f0JdDIRN+GQ8juUNyEAEUQSD6zMq JvfJp8bRpVYoxxbnwFLVrstgpSfX8g3NeWF5ZkEVNW2023ZoEcqNAZ5g6MB/AgMB AAGjggOgMIIDnDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHwYDVR0j BBgwFoAUGQOq2SJFxxpiqedcmbCd3u3UuLUwggFJBggrBgEFBQcBAQSCATswggE3 MEgGCCsGAQUFBzABhjxodHRwOi8vYXBwbGljYXRpb24tY2VydGlmaWNhdGVzLWNh LTMtMS0yMDEzLm9jc3AuZC10cnVzdC5uZXQwWwYIKwYBBQUHMAKGT2h0dHA6Ly93 d3cuZC10cnVzdC5uZXQvY2dpLWJpbi9ELVRSVVNUX0FwcGxpY2F0aW9uX0NlcnRp ZmljYXRlc19DQV8zLTFfMjAxMy5jcnQwgY0GCCsGAQUFBzAChoGAbGRhcDovL2Rp cmVjdG9yeS5kLXRydXN0Lm5ldC9DTj1ELVRSVVNUJTIwQXBwbGljYXRpb24lMjBD ZXJ0aWZpY2F0ZXMlMjBDQSUyMDMtMSUyMDIwMTMsTz1ELVRydXN0JTIwR21iSCxD PURFP2NBQ2VydGlmaWNhdGU/YmFzZT8wbwYDVR0gBGgwZjBaBgsrBgEEAaU0AoFI AjBLMEkGCCsGAQUFBwIBFj1odHRwOi8vd3d3LmQtdHJ1c3QubmV0L2ludGVybmV0 L2ZpbGVzL0QtVFJVU1RfQ1NNX1BLSV9DUFMucGRmMAgGBgQAj3oBAzCCAUUGA1Ud HwSCATwwggE4MIIBNKCCATCgggEshoGGbGRhcDovL2RpcmVjdG9yeS5kLXRydXN0 Lm5ldC9DTj1ELVRSVVNUJTIwQXBwbGljYXRpb24lMjBDZXJ0aWZpY2F0ZXMlMjBD QSUyMDMtMSUyMDIwMTMsTz1ELVRydXN0JTIwR21iSCxDPURFP2NlcnRpZmljYXRl cmV2b2NhdGlvbmxpc3SGS2h0dHA6Ly9jcmwuZC10cnVzdC5uZXQvY3JsL2QtdHJ1 c3RfYXBwbGljYXRpb25fY2VydGlmaWNhdGVzX2NhXzMtMV8yMDEzLmNybIZUaHR0 cDovL2Nkbi5kLXRydXN0LWNsb3VkY3JsLm5ldC9jcmwvZC10cnVzdF9hcHBsaWNh dGlvbl9jZXJ0aWZpY2F0ZXNfY2FfMy0xXzIwMTMuY3JsMB0GA1UdDgQWBBQ7Mbel rokN1XgEHhDNqQnt4afO2TAOBgNVHQ8BAf8EBAMCBLAwJAYDVR0RBB0wG4EZZGFu aWVsX2hlcnppbmdlckBnZW51YS5kZTANBgkqhkiG9w0BAQsFAAOCAQEAbvMls9Zy PSq5BCwdLvvnT6UApYc34DzgNMqrhJ1QkHioS/145BkovzEC0FvmsMfxKOBpUH4p pL2V5XWbCNlaTokN3+xJyFTCut6LHYE+xPVaYoRTY5upVXXBetOwRxqmGRyF3sXX eeQAZhFKRodpuEM7X4Dno3eSaaPPK/vIl+jaI5A4/liyUA3mJkGBCtxji/UZ5bag B04aWsDkShBCCMi3ro4FutJa0GcJ2OYVwk+LFH1hLs13bzfBloXjMY0KRi+DtOhF xoxtdmrnA3d5JcsLzRV2n5sJ3bvbxrx97lnf2gFmUaeIhKL0VRHBWu0RKZOsQi3G kfw8EhilV8poEDGCA38wggN7AgEBMG8wWzELMAkGA1UEBhMCREUxFTATBgNVBAoM DEQtVHJ1c3QgR21iSDE1MDMGA1UEAwwsRC1UUlVTVCBBcHBsaWNhdGlvbiBDZXJ0 aWZpY2F0ZXMgQ0EgMy0xIDIwMTMCEGu+w6X6Cir2BXP9wSbuwCUwCwYJYIZIAWUD BAIBoIHkMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTIxMTAxODA5Mjg0OVowLwYJKoZIhvcNAQkEMSIEIBntGioRdqsdorLN+t/CM+ux 0Im+NyF7W5Fn+6CqHWpNMHkGCSqGSIb3DQEJDzFsMGowCwYJYIZIAWUDBAEqMAsG CWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqG SIb3DQEBAQUABIICADjrT8M+RXDdmUpaWkK3b8dR6dkDTzePhTRtX0oTMJMM2jS1 OW3V3Vm9pttdE6yQhOxSjgH6AgOi6VZkWSsswerln2URgaHOeTWJPSqJsBhOX3B7 AXi8H7bWfB3anHBB2OMcDnuH8BfdbK0ja/wjc8iLAQnULpirfld4Al1XDYZvdHiN /0GifHl/cYMcqYjAzGZJIhK24K/KFe3MqWvHhT5xLQ9H46+6KyhYbBkbVK/c0ui/ KORarz9cZT0kZ4JCQS/m8cD4CWQUg7sjRBlgp0SwXQxyW4VF7HFRhzz/BQAb5WX4 EP5TOrBM5lb0V3gmwLqZJQwLMe9WmQrm1Y2mXHmyzLpDkSYIvLgpXDpGaxUiyeUI zXr/CSKIO5tMjV1qcA/FwwllqKy53/6tyji+EWkPHgTJnlltqEVH8FXF6jUiLGAR nWcI0e3aVSG0pTLbAhkvDk+RZLl15ZtefqXi5nIEEMRBA3NqIXZoKKjtZzBROheg eD/DP31INPR2hoFqBAycyESGD9nhYKzPgika/wGgzwISy4Spm5BwAfidmlNDMrvT bFWn1NEYNg58SeGADJ31bMJoDh1ytRoiKteG8iWukvtDmVzEhfhgxwTVWemFopmu kSZv6Ty7HRvrDN+BXHqV/0sIbClxiiLLjwP8jEapxBdMvoWd0ASFd98oR8A+ ------B1918C090D21F57B1DE3CFAB7C13D63E-- From nobody Mon Oct 18 13:50:26 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C14CB3A0B9E for ; Mon, 18 Oct 2021 13:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.789 X-Spam-Level: X-Spam-Status: No, score=-2.789 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1OBNNu2puMI for ; Mon, 18 Oct 2021 13:50:12 -0700 (PDT) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [185.185.170.37]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 244433A0BAA for ; Mon, 18 Oct 2021 13:50:04 -0700 (PDT) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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) (Authenticated sender: kivinen@iki.fi) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 88F771B00334; Mon, 18 Oct 2021 23:50:01 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1634590201; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GD1b+2kdrYLKViLxKWtrsRAOb45PKk5C3CKvRZLHg9E=; b=oVQGqFx7BkpH2nLiGyM309RG+d6VwrUKbk2TPbdaA3Gfkw8sIPuZ3oCkqhA5kxEvDllbdb dXktaM1TPicxr2nHmxfX5S8vWfrxjr198ZnAwHduMAK4SFlbMbmwBcik7GRJY8//Ij7vBK uEZqdOGLGOt5f9AU9MTGB5BpeW6XQSXpSp335EdDX2khTLRhuzcBXQ2cH1L3weToyOVFbY rGZaUfgDXoZx8dQmy0L1ozDxfUa6EuojtrPZ15vT7dCkFK1ukA3DHgtAnXPOjJZiWAmDoZ dn7Web5N9gfliBGJhWNs7zwX999PTh8HblKChi5XdKyNmshDlFtRr2GIQzn07w== Received: by fireball.acr.fi (Postfix, from userid 15204) id 17DA625C12DB; Mon, 18 Oct 2021 23:50:01 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24941.56825.49896.67989@fireball.acr.fi> Date: Mon, 18 Oct 2021 23:50:01 +0300 From: Tero Kivinen To: Daniel Herzinger Cc: "ipsec\@ietf.org" , "ietf\@gazdag.de" In-Reply-To: <935923623769463b80caf7b64bfe430a@genua.de> References: <935923623769463b80caf7b64bfe430a@genua.de> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 49 min X-Total-Time: 56 min ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1634590201; a=rsa-sha256; cv=none; b=ubeEYTbSobQdX0lFrn4y9LyEuJM5m0sihOy6gPPsMZZmibrmAbbSluqwRgTyosw9vIfRto fZchKsylAhuVNkIG7L/BgqmPMCVOi/JdvMnrXyqZwKiFCX+Syhzk1SeJw/g39OuyQkNK99 h0xKu7LoA/w5EEOJ421DZdHJuEiU28Z8ga9qfITYnvLj81h66pqSdpf6k65AmyNXRMC7xe Y+p05+m/Cp3FSXd6xTxYVAxNErDzZnEVA47vJkblYvwV688LcvoBnNaZxqdM6GCcxrjKWO so/xZPWp8Df5bNFyhwvRUBoEF+JwIggxHe0t5I38LZV62ycdZhMilYrFSgTNng== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen@iki.fi smtp.mailfrom=kivinen@iki.fi ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1634590201; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GD1b+2kdrYLKViLxKWtrsRAOb45PKk5C3CKvRZLHg9E=; b=Yo+7Nt/BlTZlgZ85GYw0fmjCawbXJvTufA+o/ocbBSBIUXWiWoRsMTV2P6mupPIAyDjz3h b03PQbUEUdxzfo9XhSfFAGumY0O1xkBff0sImFNtquIExvkDLxkHVPdXrkVxVrYmPaoWt+ O+3SenkHi8eaKu9NjJrP28QEHre0S9Ktfw37NyCcccwhqTcuZQmxJv39iBV1o5+ncdIemv 2YkU0OdAAPcAgplriLjmzDOFXnteHX3nH2xPGQnuspvmoAtm0hjW4M/cRWtCvxsBGZPRPQ I/IXNRm24VKZ0tll0dfO7P42cM4Eub2Vl5S/jxCsDhO03ZzrlHkozQfdG1HfLA== Archived-At: Subject: [IPsec] Cost-efficient quantum-resistant DoS protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2021 20:50:19 -0000 Daniel Herzinger writes: > in response to the new version of > draft-ietf-ipsecme-ikev2-multiple-ke-04.txt, we wanted to emphasize > the issue of DoS attacks during intermediate exchanges. The new > version does address it by mentioning the option of simply avoiding > intermediate exchanges altogether but still require additional key > exchanges. Yet, this protects only against record-and-harvest > attacks but not against an attacker with a strong quantum computer > at the time of the handshake, regardless of quantum-resistant > authentication (since they can break the initial shared secret and > therefore recalculate the MAC which authenticates the followup > exchanges, fully establishing a man-in-the-middle). We doubt that an > attacker, even with a strong quantum computer, is able to break a > key exchange in such a short time period. Still, this assumption is > too theoretical to rely on. This, together with the fact that > Group-IKE is incompatible with key exchanges during followup > exchanges, makes the option seem inferior to just sticking to > intermediate exchanges during the handshake. However, we must also > consider the draft-tjhai-ikev2-beyond-64k-limit-01.txt. > > An attacker who exploits the large key exchanges, e.g., by > requesting seven additional maximum size McEliece key exchanges, can > force a gateway to accept and process 1.4MB of data per McEliece > KEM. This leaves us at a situation where we must pick one of the > following options: > > 1. Accept the highly increased risk of DoS attacks. > 2. Prohibit the use of large KE payloads, hence the McEliece mechanism. > 3. Prohibit the use of intermediate exchanges, leaving the IKE SA > initially unprotected and being vulnerable to an attacker with a > quantum computer during the handshake. Not really. There are several different attacks here and we have different protection against each of them. Firstly Diffie-Hellman, Intermediate exchanges etc are not really meant for DoS protection. For DoS protection we have cookies, puzzles (RFC8019), and the fact that that we know the source IP-address of the attacker (as cookies forces them to do full round trip before they can do anything else), and as we know the IP-address(es) we can force puzzles for all unknown IP-addresses, i.e. anything we have not seen before, and that will make attackers work much harder. We might allow anybody connecting from the known IP-addresses without puzzles, just use cookies to force full round trip, but do puzzles for everybody else. This does not depend at all whether the attacker has quantum computer or not (hmm... not sure if our puzzles are faster to calculate on quantum computer than on normal computer, but at least forcing attacker to use his quantum computer just to solve our puzzles, might be a win). Secondly only authentication type now which is really protected against quantum computers is the PPK (RFC8784), i.e., post-quantum preshared keys with strong and random shared secrets. Signatures etc can be attacked using quantum computer by find out the private key for them. This might change in the future, but I think that will happen in general PKIX / X.509 area, i.e., when the certificates can use methods that are quantum computer safe, we should be able to use them with just generic signature authentication method (RFC7427). So now we do IKE_INIT and have Diffie-Hellman done there and attacker does not even need to have Quantum computer to do attack that as on path attacker can simply do non-cryptographic attack to stay in the middle, and see all the traffic going through. This Diffie-Hellman and all following quantum safe key exchange methods are still unauthenticated ones. This means that attacker can force as to do those expensive KE methods. On the other hand this do require on path attacker, who can also simply wait for the real initiator to do everything and then simply block all messages to IKE SA going through the path, thus severing the IKEv2 connection, can causing reconnection. It can do that always and there is nothing we can do for that, no quantum computer needed... And blocking few packets is cheaper than attacking Diffie-Hellman or even acting as an attacker in the middle. If you want to protect against doing those quantum safe algorithms with attacker, you simply do normal childless IKEv2 with just traditional Diffie-Hellman and use PPK to make sure there is no attacker in the middle, and after that finishes you rekey that IKEv2 and then do the expensive operations only then. This should give you full protection of the REKEYed IKEv2 SA, if I have understood the protocol correctly. > To us, none of these options seems desirable. Thus, we propose > another solution which sees one new transform type, e.g., > SNTRUP761X25519, which then defines a combination of one classical > algorithm (like ECDH based on curve25519) and one pqc algorithm > which fits into IKE_SA_INIT without fragmentation (like > sntruprime761). The two secrets get concatinated and then fed to a > hash function. The resulting hash is used as the shared secret for > further key derivation. This does not protect at all against the active on path attacker as it does not even need to use quantum computer to be able to do that attack, it simply acts in the middle doing separate connections, one for the initiator, and another for the responder, and then passes messages through after decrypting and reencrypting them. If it has already broken the private key used in the signature to authenticate the peers, it can successfully stay there after the authentication (unless PPK was used too). > This mechanism is low effort in terms of implementation and does not > affect the state machine at all, but already offers a high level of > protection against all attacks as long as there is no major > break-through in cryptanalysis. It does not affect the state machine, but it does affect the crypto calculations which has quite big impact on the protocol. On the other hand as this is just new Key Exchange algorithm, there is actually no need to change IKEv2 at all, as long as that new KE simply generates one shared secret (g^ir) that can be used on both ends, i.e., the combining of the separate secrets happens inside the key exchange algorithm not in the IKEv2 protocol. I myself think this is wasted effort, as it does not provide us any protection against active attackers (except that attacker need to implement that new algorithm too :-), and doing those algorithms as separate steps is easier and more modularized. > Furthermore, it is the accepted approach for most of the > applications of post-quantum key exchanges. For higher long-term > security, it can be combined with other, more conventional > algorithms which follow either in intermediate or followup > exchanges. > > We then propose to restrict the use of large key exchanges to the > context of option 3, which removes the risk of the described DoS > attacks. Yet, to prevent the insecurities of plain option 3, we also > propose to make it mandatory to combine it with the new hybrid > transform type, i.e., SNTRUP761X25519. Restricting algorithms is completely up to the policy you use. Even when using IKE_INTERMEDIATE exchange you can do so that you first do classical Diffie-Hellman, then do cheap quantum safe algorithm (like the sntruprime761 you mentioned) and then do the authentication in the IKE_AUTH using PPK, and after that do IKE SA rekey and during that you do the more expensive methods that were not allowed by policy earlier.. > The only downside of this approach is that G-IKE is then > incompatible with the McEliece exchange. However, the fact that > G-IKE exchanges sensitive information before authentication makes it > impossible to be not vulnerable against the discussed DoS attack > and, at the same time, support the McEliece algorithm. Thus, we see > that as a decision to be made in the G-IKE standardization track, > not in IKEv2. I do not think G-IKEv2 needs to exchange any sensitive information during the GSA_AUTH. In the GSA_AUTH SAg is optional, GSA, and KD are optional, only think that is mandatory is the IDg, which is identical to IDi, and IDr, i.e., indicates identity. We might want to make sure GSA_AUTH can use PPK as described in the RFC8784, i.e., mention N(USE_PPK) for IKE_SA_INIT and add optional N(PPK_IDENTITY, PPK_ID) to GSA_AUTH. We have already talked earlier that if we want to have proper identity protection against all attackers we need to use pseudonym method, i.e., the IDi (and IDg) would be pseudonym for the device, not the real identity. Then the IKEv2 does IKE SA rekey to create channel which is protected against all attackers when using PPK, and after that it can do pseudonym maintenance. In the simplist case the server simply sends client few dozen one use random unique pseudonyms that the client can use next time it connects over that channel. And next time when it connects the server updates new pseudonyms for future use etc. Also I think G-IKEv2 is written in a way where it should allow IKE_INTERMEDIATE exchanges between the IKE_SA_INIT and GSA_AUTH, but I have not verified whether there is something still missing there. -- kivinen@iki.fi From nobody Tue Oct 19 08:45:42 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 632A73A07A5 for ; Tue, 19 Oct 2021 08:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBV3AAWhov4H for ; Tue, 19 Oct 2021 08:45:37 -0700 (PDT) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70E7B3A0788 for ; Tue, 19 Oct 2021 08:45:37 -0700 (PDT) Received: by mail-wm1-x331.google.com with SMTP id y16-20020a05600c17d000b0030db7a51ee2so2325506wmo.0 for ; Tue, 19 Oct 2021 08:45:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=Kl+oUA01vDm0WO5CgPsI4bUGWCgIvx7Zyd4YLnsG3m4=; b=D0vt6FKaB+lOo3RKFaHXjcaH8Rfi+JJJ5Xdtr/UFlytYG7dVJzM886SXGoAiZwJjIX r3Tz4jzY1vZKV8yxNLhEdY/Yb7CUYWpaUiaRj7+aNX+yTBwAPIPuEKQqEll175srqFAP cngUAMBlxMnCm6oQ84zyPxC4WT5TrCvVm+VOJ/vFZHnQQVGrNyXoNGn+lRfp37Ci4GG3 kLU44m4kOJ3iCmkjBcpzaOPn8bQorYHDy26/+KG7Ohvd8kk2jM4LYx6ImG/Lqr8fnr5k 21pNrn3hCOoN4ba1HeNdIEYccLjJEV+IUVvGxi5Y9C59XigMHdBmfjWPIpAO2Rhn5Tk4 Czxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=Kl+oUA01vDm0WO5CgPsI4bUGWCgIvx7Zyd4YLnsG3m4=; b=ZLDI+LZhkmSeDJ82arrvX67K0TEkoEaWn9wzEkAdoSnnVosdWyhcJGsOC2OfCiEOex 65airxW7c7CBMrJy7RHYZEDVoG7ckB57Lpbs+4htut7YDJipJsEoFhNp4uFY8lJ+4xyG bdSOZ7/HF3rSwHs+7D8sMnIZF90vNS5NWX09tPUIpLLk7WA2HHEdrVUh1cslY90GLaJx mU/0GjVqB6c+l67uNYey/x5sbox7osfQz+et0EMTe4nghbw9QtPcTqZi9wzza2N4D7uJ OjNmuJT/HoiF2Q9YK5MexW1BrutRaty4o0Kmq5uoCA/EBoqrPsQyf0tl+DkneRCKUMM6 5+7A== X-Gm-Message-State: AOAM532TQy7hwAn41LWenGMFDqb8KnFNDtQVgdIYvos0O85QEuUpEsJQ 4USIgIayCgRa1h54t+6+2fMw4lFF+Wo= X-Google-Smtp-Source: ABdhPJyjJygxq9Kf/nP5bBAGcEHrWPXO1TA08li+ZPbH8NwE55L4LQNUvPk+JQOUAQZSQdTlOgKxrg== X-Received: by 2002:adf:fe0b:: with SMTP id n11mr45897678wrr.371.1634658335470; Tue, 19 Oct 2021 08:45:35 -0700 (PDT) Received: from buildpc ([93.188.44.204]) by smtp.gmail.com with ESMTPSA id p17sm15182136wro.34.2021.10.19.08.45.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Oct 2021 08:45:34 -0700 (PDT) From: "Valery Smyslov" To: "'Daniel Herzinger'" , Cc: References: <935923623769463b80caf7b64bfe430a@genua.de> In-Reply-To: <935923623769463b80caf7b64bfe430a@genua.de> Date: Tue, 19 Oct 2021 18:45:35 +0300 Message-ID: <07a701d7c500$5c3fdcc0$14bf9640$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLlmXEscoeqGnTi+siCjM6VrsV64qm+vQLA Content-Language: ru Archived-At: Subject: Re: [IPsec] Cost-efficient quantum-resistant DoS protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2021 15:45:40 -0000 Hi Daniel and Stefan-Lukas, > Hi, > > in response to the new version of draft-ietf-ipsecme-ikev2-multiple-ke-04.txt, we wanted to emphasize the > issue of DoS attacks during intermediate exchanges. The new version does address it by mentioning the > option of simply avoiding intermediate exchanges altogether but still require additional key exchanges. Yet, > this protects only against record-and-harvest attacks but not against an attacker with a strong quantum > computer at the time of the handshake, regardless of quantum-resistant authentication (since they can break > the initial shared secret and therefore recalculate the MAC which authenticates the followup exchanges, fully > establishing a man-in-the-middle). We doubt that an attacker, even with a strong quantum computer, is able > to break a key exchange in such a short time period. Still, this assumption is too theoretical to rely on. This, > together with the fact that Group-IKE is incompatible with key exchanges during followup exchanges, makes > the option seem inferior to just sticking to intermediate exchanges during the handshake. However, we must > also consider the draft-tjhai-ikev2-beyond-64k-limit-01.txt. > An attacker who exploits the large key exchanges, e.g., by requesting seven additional maximum size McEliece > key exchanges, can force a gateway to accept and process 1.4MB of data per McEliece KEM. Not really. First, the situation with seven McEliece is not possible, since all negotiated Key Exchange methods MUST be different. Then, you seem to assume that the responder blindly accepts all the key exchanges at the initiator's will. This is not true. First peers negotiate which key exchanges they will perform (including additional key exchanges), and you can limit the types and the number additional key exchanges the responder will accept via its local policy. > This leaves us at > a situation where we must pick one of the following options: > > 1. Accept the highly increased risk of DoS attacks. > 2. Prohibit the use of large KE payloads, hence the McEliece mechanism. > 3. Prohibit the use of intermediate exchanges, leaving the IKE SA initially unprotected and being vulnerable to > an attacker with a quantum computer during the handshake. > > To us, none of these options seems desirable. Thus, we propose another solution which sees one new > transform type, e.g., SNTRUP761X25519, which then defines a combination of one classical algorithm (like I'm confused here - did you mean new transform type or new transform ID? Transform types define a kind of algorithms (or other features, like ESN), while transform IDs define a particular algorithm of this type. Unless I'm missing something I presume you meant new transform ID which defines a new key exchange algorithm which is a combination of SNTRUP761 and X25519. Correct me if I'm wrong. > ECDH based on curve25519) and one pqc algorithm which fits into IKE_SA_INIT without fragmentation (like > sntruprime761). The two secrets get concatinated and then fed to a hash function. The resulting hash is used > as the shared secret for further key derivation. This mechanism is low effort in terms of implementation and > does not affect the state machine at all, but already offers a high level of protection against all attacks as long > as there is no major break-through in cryptanalysis. Furthermore, it is the accepted approach for most of the > applications of post-quantum key exchanges. For higher long-term security, it can be combined with other, > more conventional algorithms which follow either in intermediate or followup exchanges. I think that this combined key exchange algorithm can also be implemented (with more flexibility) by doing IKE_SA_INIT(X25519)+IKE_INTERMEDIATE(SNTRUP761). I don't think your approach has real advantages in terms of consuming responder's resources. The responder still needs to perform both X25519 and SNTRUP761 before it authenticates the initiator. Yes, you save one round trip, but the amount of data sent on the wire and the amount of CPU cycles are roughly the same. I'd like also mention that while X25519 and SNTRUP761 public keys are fit into a single 1500 bytes IKE message, they leave relatively little space for SA payload, so initiator may be limited in expressing its proposals. > We then propose to restrict the use of large key exchanges to the context of option 3, which removes the risk > of the described DoS attacks. Yet, to prevent the insecurities of plain option 3, we also propose to make it > mandatory to combine it with the new hybrid transform type, i.e., SNTRUP761X25519. Are you proposing to stick with these two particular algorithms? I don't think it's a good idea, giving the algorithm agility requirements. I think that the same result can be achieved with the current draft: IKE_SA_INIT(X25519 or whatever else) IKE_INTERMEDIATE(SNTRUP761 or whatever else with small public key) IKE_AUTH(Childless if you want) CREATE_CHILD_SA+IKE_FOLLOWUP_KE(McEliece or whatever else with long public key) This leaves much more flexibility in selecting particular algorithms. > The only downside of this approach is that G-IKE is then incompatible with the McEliece exchange. However, > the fact that G-IKE exchanges sensitive information before authentication makes it impossible to be not > vulnerable against the discussed DoS attack and, at the same time, support the McEliece algorithm. Thus, we > see that as a decision to be made in the G-IKE standardization track, not in IKEv2. I agree that G-IKEv2 is very special, but I also agree with Tero's previous message that protecting IKEv2 and (G-IKEv2 too) against DoS attacks leaves in slightly different area. We have some mechanisms for this (not perfect, but that is that). Regards, Valery. > Regards, > > Stefan-Lukas Gazdag, Daniel Herzinger From nobody Thu Oct 21 08:49:22 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512423A00C4 for ; Thu, 21 Oct 2021 08:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-MBrQt24dRC for ; Thu, 21 Oct 2021 08:49:14 -0700 (PDT) Received: from smtp-fw-80006.amazon.com (smtp-fw-80006.amazon.com [99.78.197.217]) (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 5DA213A00D2 for ; Thu, 21 Oct 2021 08:49:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1634831355; x=1666367355; h=from:to:cc:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=205ly60omPA9aAYlORlS6l2WvEGbkAmVlxogVwvejd4=; b=UZMXICFQ/iDVO0WYrzJTiurvoZyY/K7+4QFms6r0M08s4DVMywlWyRra Bj6UbdYECKoAeGre+3KVNB6U8mD42j6zJseJEBirayZVTRpj5IqthU7DL eabKUvL/798m9I1iAIsif7rjttWLGuGfa+kDNdagVKQmOEspe6lMJ7BnJ A=; X-IronPort-AV: E=Sophos;i="5.87,170,1631577600"; d="scan'208";a="35973703" Thread-Topic: [IPsec] Cost-efficient quantum-resistant DoS protection Received: from pdx4-co-svc-p1-lb2-vlan3.amazon.com (HELO email-inbound-relay-pdx-2c-d9fba5dd.us-west-2.amazon.com) ([10.25.36.214]) by smtp-border-fw-80006.pdx80.corp.amazon.com with ESMTP; 21 Oct 2021 15:49:06 +0000 Received: from EX13MTAUWB001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan3.pdx.amazon.com [10.236.137.198]) by email-inbound-relay-pdx-2c-d9fba5dd.us-west-2.amazon.com (Postfix) with ESMTPS id 95E00425FD; Thu, 21 Oct 2021 15:49:05 +0000 (UTC) Received: from EX13D01ANC004.ant.amazon.com (10.43.157.237) by EX13MTAUWB001.ant.amazon.com (10.43.161.249) with Microsoft SMTP Server (TLS) id 15.0.1497.24; Thu, 21 Oct 2021 15:49:04 +0000 Received: from EX13D01ANC003.ant.amazon.com (10.43.157.68) by EX13D01ANC004.ant.amazon.com (10.43.157.237) with Microsoft SMTP Server (TLS) id 15.0.1497.24; Thu, 21 Oct 2021 15:49:03 +0000 Received: from EX13D01ANC003.ant.amazon.com ([10.43.157.68]) by EX13D01ANC003.ant.amazon.com ([10.43.157.68]) with mapi id 15.00.1497.024; Thu, 21 Oct 2021 15:49:02 +0000 From: "Kampanakis, Panos" To: Valery Smyslov , 'Daniel Herzinger' , "ipsec@ietf.org" CC: "ietf@gazdag.de" Thread-Index: AQHXxAHuDuDAcAFigkC0od08vH3ixavaeLKAgAMi/kA= Date: Thu, 21 Oct 2021 15:49:02 +0000 Message-ID: <994547d5af7a47b2b4819136af4b29fd@EX13D01ANC003.ant.amazon.com> References: <935923623769463b80caf7b64bfe430a@genua.de> <07a701d7c500$5c3fdcc0$14bf9640$@gmail.com> In-Reply-To: <07a701d7c500$5c3fdcc0$14bf9640$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.156.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Cost-efficient quantum-resistant DoS protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2021 15:49:20 -0000 Hi Valery, Tero,=20 > Not really. First, the situation with seven McEliece is not possible, sin= ce all negotiated Key Exchange methods MUST be different. Then, you seem to assume that the responder blindly accepts all the key exc= hanges at the initiator's will. This is not true. First peers negotiate which key exchanges they will perfo= rm (including additional key exchanges), and you can limit the types and th= e number additional key exchanges the responder will accept via its local p= olicy. I think the point is valid though if the responder supports McEliece. A mis= creant can that way make the responder put a lot of data on the wire like a= n amplification attack although the initiator has not been validated. QUIC = has a 3x amplification protection limits for that matter.=20 Sure, the issue existed even in ECDH exchanges, but the impact is much high= er when we talk MB of public keys.=20 Imo, McEliece is not practical for live protocols like TLS or IKEv2. Too ma= ny packets mean pretty high loss probability in unstable networks which mea= ns pretty bad performance unless everything happens in the datacenter or ro= bust end-to-end network paths. The PQ KEMs that will end up being standardi= zed are likely to have just a few KBs of public key and ciphertext which is= better for the general case.=20 So, I would say option 3 (prohibit the use of very large KE payloads like M= cEliece's MB sized public keys) is more practical.=20 Rgs, Panos -----Original Message----- From: IPsec On Behalf Of Valery Smyslov Sent: Tuesday, October 19, 2021 11:46 AM To: 'Daniel Herzinger' ; ipsec@ietf.org Cc: ietf@gazdag.de Subject: RE: [EXTERNAL] [IPsec] Cost-efficient quantum-resistant DoS protec= tion CAUTION: This email originated from outside of the organization. Do not cli= ck links or open attachments unless you can confirm the sender and know the= content is safe. Hi Daniel and Stefan-Lukas, > Hi, > > in response to the new version of=20 > draft-ietf-ipsecme-ikev2-multiple-ke-04.txt, we wanted to emphasize=20 > the issue of DoS attacks during intermediate exchanges. The new=20 > version does address it by mentioning the option of simply avoiding=20 > intermediate exchanges altogether but still require additional key=20 > exchanges. Yet, this protects only against record-and-harvest attacks=20 > but not against an attacker with a strong quantum computer at the time=20 > of the handshake, regardless of quantum-resistant authentication=20 > (since they can break the initial shared secret and therefore=20 > recalculate the MAC which authenticates the followup exchanges, fully=20 > establishing a man-in-the-middle). We doubt that an attacker, even with a= strong quantum computer, is able to break a key exchange in such a short t= ime period. Still, this assumption is too theoretical to rely on. This, tog= ether with the fact that Group-IKE is incompatible with key exchanges durin= g followup exchanges, makes the option seem inferior to just sticking to in= termediate exchanges during the handshake. However, we must also consider t= he draft-tjhai-ikev2-beyond-64k-limit-01.txt. > An attacker who exploits the large key exchanges, e.g., by requesting=20 > seven additional maximum size McEliece key exchanges, can force a gateway= to accept and process 1.4MB of data per McEliece KEM. Not really. First, the situation with seven McEliece is not possible, since= all negotiated Key Exchange methods MUST be different. Then, you seem to assume that the responder blindly accepts all the key exc= hanges at the initiator's will. This is not true. First peers negotiate which key exchanges they will perfo= rm (including additional key exchanges), and you can limit the types and th= e number additional key exchanges the responder will accept via its local p= olicy. > This leaves us at > a situation where we must pick one of the following options: > > 1. Accept the highly increased risk of DoS attacks. > 2. Prohibit the use of large KE payloads, hence the McEliece mechanism. > 3. Prohibit the use of intermediate exchanges, leaving the IKE SA=20 > initially unprotected and being vulnerable to an attacker with a quantum = computer during the handshake. > > To us, none of these options seems desirable. Thus, we propose another=20 > solution which sees one new transform type, e.g., SNTRUP761X25519,=20 > which then defines a combination of one classical algorithm (like I'm confused here - did you mean new transform type or new transform ID? Transform types define a kind of algorithms (or other features, like ESN), = while transform IDs define a particular algorithm of this type. Unless I'm missing something I presume you meant new transform ID which def= ines a new key exchange algorithm which is a combination of SNTRUP761 and X= 25519. Correct me if I'm wrong. > ECDH based on curve25519) and one pqc algorithm which fits into=20 > IKE_SA_INIT without fragmentation (like sntruprime761). The two=20 > secrets get concatinated and then fed to a hash function. The=20 > resulting hash is used as the shared secret for further key=20 > derivation. This mechanism is low effort in terms of implementation=20 > and does not affect the state machine at all, but already offers a=20 > high level of protection against all attacks as long as there is no major= break-through in cryptanalysis. Furthermore, it is the accepted approach f= or most of the applications of post-quantum key exchanges. For higher long-= term security, it can be combined with other, more conventional algorithms = which follow either in intermediate or followup exchanges. I think that this combined key exchange algorithm can also be implemented (= with more flexibility) by doing IKE_SA_INIT(X25519)+IKE_INTERMEDIATE(SNTRUP= 761). I don't think your approach has real advantages in terms of consuming= responder's resources. The responder still needs to perform both X25519 an= d SNTRUP761 before it authenticates the initiator. Yes, you save one round trip, but the amount of data sent on the wire and t= he amount of CPU cycles are roughly the same. I'd like also mention that wh= ile X25519 and SNTRUP761 public keys are fit into a single 1500 bytes IKE m= essage, they leave relatively little space for SA payload, so initiator may= be limited in expressing its proposals. > We then propose to restrict the use of large key exchanges to the=20 > context of option 3, which removes the risk of the described DoS=20 > attacks. Yet, to prevent the insecurities of plain option 3, we also prop= ose to make it mandatory to combine it with the new hybrid transform type, = i.e., SNTRUP761X25519. Are you proposing to stick with these two particular algorithms? I don't think it's a good idea, giving the algorithm agility requirements. I think that the same result can be achieved with the current draft: IKE_SA_INIT(X25519 or whatever else) IKE_INTERMEDIATE(SNTRUP761 or whatever else with small public key) IKE_AUTH= (Childless if you want) CREATE_CHILD_SA+IKE_FOLLOWUP_KE(McEliece or whateve= r else with long public key) This leaves much more flexibility in selecting particular algorithms. > The only downside of this approach is that G-IKE is then incompatible=20 > with the McEliece exchange. However, the fact that G-IKE exchanges=20 > sensitive information before authentication makes it impossible to be=20 > not vulnerable against the discussed DoS attack and, at the same time, su= pport the McEliece algorithm. Thus, we see that as a decision to be made in= the G-IKE standardization track, not in IKEv2. I agree that G-IKEv2 is very special, but I also agree with Tero's previous= message that protecting IKEv2 and (G-IKEv2 too) against DoS attacks leaves= in slightly different area. We have some mechanisms for this (not perfect, but that is that). Regards, Valery. > Regards, > > Stefan-Lukas Gazdag, Daniel Herzinger _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Oct 21 09:40:14 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E063A0858 for ; Thu, 21 Oct 2021 09:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=post-quantum-com.20210112.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCETVyPFUGnk for ; Thu, 21 Oct 2021 09:39:29 -0700 (PDT) Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28A783A0860 for ; Thu, 21 Oct 2021 09:39:29 -0700 (PDT) Received: by mail-yb1-xb2f.google.com with SMTP id m63so678689ybf.7 for ; Thu, 21 Oct 2021 09:39:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=post-quantum-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=o7dNdRVhNlHfgiZS8E8GwdIXBFdDK3r1aMNnzpn5hMs=; b=DedW4rLWtZf2nerkzemaWlIE/+Yw9/2+5JVlRlpR8LefUB9A0bK/0siUq3ElE6RQoy q1HrdqDECgxKF2D5hzjLZ0gFgFT5twhn2O4bAQ0d9n77SUOm1dYhwWKx81plgC/FbgFb uBIwagkHiE4cbiiWdUnaHEqJNwL/GuAQoc3JRq4cfzogmlzFbbTQU0stYWTcbDHji453 o1M48Ex4wJAzzPjwIx8eSK1cKHIg1MSs53Te+JDKz+y57PrtzHEx9hBfThQ6IBTNAGtM vpM+MoN8WmaWaUcI6uVxdpNyLv4Eytdx0IlxqF/1VJ4x+Iit1FiDeK8lbmwy8LkQG0l6 k2BA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=o7dNdRVhNlHfgiZS8E8GwdIXBFdDK3r1aMNnzpn5hMs=; b=VF9+SGrbuzmHVmL1MDJx4WFLpZyWPy6AjIZWkz9vrbYOp7vipA7wpSQd2LZ/A6IbcX NYd4oXfFZ96GYC0Gzfyonnk7itdcO03HbI4PXBfhfOw3h8NEj2p3vJl6ov3WuiVKN8dm bBgK1VK/3hdOdtHykShxVAmmYwJG48LsDrAhY3IsNg4MHtdGQhK9T0T2HrRK0yMM92x9 lJNi9kVNJOuW6W/BQMquYNljfbndR5IkfaOZmFPwUxjMnwpoJyl4S3fPLJe84BgwDJE5 neTypw4hwX0ox0aaZ145GqGA8YzMJpPsKsr1A/kHPVir9Od0GuHKLh8Yu3mjHE4I72hE WGzQ== X-Gm-Message-State: AOAM53117UnfUqeobAU3qxt4EHyevKsB2C8y2EIKf13nBw3vnBUMrCo0 dV+V1tzHhdxp5K9Xn0rpFxImrxIs7erZII6Vc3+PzynqTqThFunyqMc3cEUyGb6UrA2KHsg79rr xVk/8/FAKiLE/CiM= X-Google-Smtp-Source: ABdhPJxf2bm+YNRyybx0LA0mLcwQFZO6DKXLFo9+m01h29eV+Q7CsEojxK6BT3PcrZn3KoBVvFS3f1CCaVk/GaXeF8Y= X-Received: by 2002:a25:6908:: with SMTP id e8mr6861324ybc.337.1634834367213; Thu, 21 Oct 2021 09:39:27 -0700 (PDT) MIME-Version: 1.0 References: <935923623769463b80caf7b64bfe430a@genua.de> <07a701d7c500$5c3fdcc0$14bf9640$@gmail.com> <994547d5af7a47b2b4819136af4b29fd@EX13D01ANC003.ant.amazon.com> In-Reply-To: <994547d5af7a47b2b4819136af4b29fd@EX13D01ANC003.ant.amazon.com> From: CJ Tjhai Date: Thu, 21 Oct 2021 17:39:16 +0100 Message-ID: To: "Kampanakis, Panos" Cc: Valery Smyslov , Daniel Herzinger , "ipsec@ietf.org" , "ietf@gazdag.de" Content-Type: multipart/alternative; boundary="000000000000b98c7105cedf89e2" Archived-At: Subject: Re: [IPsec] Cost-efficient quantum-resistant DoS protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2021 16:39:45 -0000 --000000000000b98c7105cedf89e2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Panos, There are two drafts involved here. a) the main draft, https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-multiple-ke/, cannot support any public-key larger than 64KB, so it can never be used for KEMs like McEliece. So the option 3 is implied here. b) on the other hand, https://datatracker.ietf.org/doc/draft-tjhai-ikev2-beyond-64k-limit/ is an attempt to address the issue with transferring payload larger than 64KB. As you pointed out, transferring large blob of data in a live protocol is challenging and therefore it deservers separate treatments and considerations. It was deliberate that we split the hybrid key exchange drafts into two, the second draft is there just in case there is any interest in the working group on supporting the use KEMs like McEliece. Cheers, CJ On Thu, 21 Oct 2021 at 16:49, Kampanakis, Panos wrote: > Hi Valery, Tero, > > > Not really. First, the situation with seven McEliece is not possible, > since all negotiated Key Exchange methods MUST be different. > Then, you seem to assume that the responder blindly accepts all the key > exchanges at the initiator's will. > This is not true. First peers negotiate which key exchanges they will > perform (including additional key exchanges), and you can limit the types > and the number additional key exchanges the responder will accept via its > local policy. > > I think the point is valid though if the responder supports McEliece. A > miscreant can that way make the responder put a lot of data on the wire > like an amplification attack although the initiator has not been validate= d. > QUIC has a 3x amplification protection limits for that matter. > > Sure, the issue existed even in ECDH exchanges, but the impact is much > higher when we talk MB of public keys. > > Imo, McEliece is not practical for live protocols like TLS or IKEv2. Too > many packets mean pretty high loss probability in unstable networks which > means pretty bad performance unless everything happens in the datacenter = or > robust end-to-end network paths. The PQ KEMs that will end up being > standardized are likely to have just a few KBs of public key and cipherte= xt > which is better for the general case. > > So, I would say option 3 (prohibit the use of very large KE payloads like > McEliece's MB sized public keys) is more practical. > > Rgs, > Panos > > > > > > -----Original Message----- > From: IPsec On Behalf Of Valery Smyslov > Sent: Tuesday, October 19, 2021 11:46 AM > To: 'Daniel Herzinger' ; ipsec@ietf.org > Cc: ietf@gazdag.de > Subject: RE: [EXTERNAL] [IPsec] Cost-efficient quantum-resistant DoS > protection > > CAUTION: This email originated from outside of the organization. Do not > click links or open attachments unless you can confirm the sender and kno= w > the content is safe. > > > > Hi Daniel and Stefan-Lukas, > > > Hi, > > > > in response to the new version of > > draft-ietf-ipsecme-ikev2-multiple-ke-04.txt, we wanted to emphasize > > the issue of DoS attacks during intermediate exchanges. The new > > version does address it by mentioning the option of simply avoiding > > intermediate exchanges altogether but still require additional key > > exchanges. Yet, this protects only against record-and-harvest attacks > > but not against an attacker with a strong quantum computer at the time > > of the handshake, regardless of quantum-resistant authentication > > (since they can break the initial shared secret and therefore > > recalculate the MAC which authenticates the followup exchanges, fully > > establishing a man-in-the-middle). We doubt that an attacker, even with > a strong quantum computer, is able to break a key exchange in such a shor= t > time period. Still, this assumption is too theoretical to rely on. This, > together with the fact that Group-IKE is incompatible with key exchanges > during followup exchanges, makes the option seem inferior to just stickin= g > to intermediate exchanges during the handshake. However, we must also > consider the draft-tjhai-ikev2-beyond-64k-limit-01.txt. > > An attacker who exploits the large key exchanges, e.g., by requesting > > seven additional maximum size McEliece key exchanges, can force a > gateway to accept and process 1.4MB of data per McEliece KEM. > > Not really. First, the situation with seven McEliece is not possible, > since all negotiated Key Exchange methods MUST be different. > Then, you seem to assume that the responder blindly accepts all the key > exchanges at the initiator's will. > This is not true. First peers negotiate which key exchanges they will > perform (including additional key exchanges), and you can limit the types > and the number additional key exchanges the responder will accept via its > local policy. > > > This leaves us at > > a situation where we must pick one of the following options: > > > > 1. Accept the highly increased risk of DoS attacks. > > 2. Prohibit the use of large KE payloads, hence the McEliece mechanism= . > > 3. Prohibit the use of intermediate exchanges, leaving the IKE SA > > initially unprotected and being vulnerable to an attacker with a quantu= m > computer during the handshake. > > > > To us, none of these options seems desirable. Thus, we propose another > > solution which sees one new transform type, e.g., SNTRUP761X25519, > > which then defines a combination of one classical algorithm (like > > I'm confused here - did you mean new transform type or new transform ID? > Transform types define a kind of algorithms (or other features, like ESN)= , > while transform IDs define a particular algorithm of this type. > > Unless I'm missing something I presume you meant new transform ID which > defines a new key exchange algorithm which is a combination of SNTRUP761 > and X25519. > Correct me if I'm wrong. > > > ECDH based on curve25519) and one pqc algorithm which fits into > > IKE_SA_INIT without fragmentation (like sntruprime761). The two > > secrets get concatinated and then fed to a hash function. The > > resulting hash is used as the shared secret for further key > > derivation. This mechanism is low effort in terms of implementation > > and does not affect the state machine at all, but already offers a > > high level of protection against all attacks as long as there is no > major break-through in cryptanalysis. Furthermore, it is the accepted > approach for most of the applications of post-quantum key exchanges. For > higher long-term security, it can be combined with other, more convention= al > algorithms which follow either in intermediate or followup exchanges. > > I think that this combined key exchange algorithm can also be implemented > (with more flexibility) by doing > IKE_SA_INIT(X25519)+IKE_INTERMEDIATE(SNTRUP761). I don't think your > approach has real advantages in terms of consuming responder's resources. > The responder still needs to perform both X25519 and SNTRUP761 before it > authenticates the initiator. > Yes, you save one round trip, but the amount of data sent on the wire and > the amount of CPU cycles are roughly the same. I'd like also mention that > while X25519 and SNTRUP761 public keys are fit into a single 1500 bytes I= KE > message, they leave relatively little space for SA payload, so initiator > may be limited in expressing its proposals. > > > We then propose to restrict the use of large key exchanges to the > > context of option 3, which removes the risk of the described DoS > > attacks. Yet, to prevent the insecurities of plain option 3, we also > propose to make it mandatory to combine it with the new hybrid transform > type, i.e., SNTRUP761X25519. > > Are you proposing to stick with these two particular algorithms? > I don't think it's a good idea, giving the algorithm agility requirements= . > I think that the same result can be achieved with the current draft: > > IKE_SA_INIT(X25519 or whatever else) > IKE_INTERMEDIATE(SNTRUP761 or whatever else with small public key) > IKE_AUTH(Childless if you want) CREATE_CHILD_SA+IKE_FOLLOWUP_KE(McEliece = or > whatever else with long public key) > > This leaves much more flexibility in selecting particular algorithms. > > > The only downside of this approach is that G-IKE is then incompatible > > with the McEliece exchange. However, the fact that G-IKE exchanges > > sensitive information before authentication makes it impossible to be > > not vulnerable against the discussed DoS attack and, at the same time, > support the McEliece algorithm. Thus, we see that as a decision to be mad= e > in the G-IKE standardization track, not in IKEv2. > > I agree that G-IKEv2 is very special, but I also agree with Tero's > previous message that protecting IKEv2 and (G-IKEv2 too) against DoS > attacks leaves in slightly different area. > We have some mechanisms for this (not perfect, but that is that). > > Regards, > Valery. > > > Regards, > > > > Stefan-Lukas Gazdag, Daniel Herzinger > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --=20 PQ Solutions Limited (trading as =E2=80=98Post-Quantum=E2=80=99) is a priva= te limited=20 company incorporated in England and Wales with=C2=A0registered number 06808= 505. =C2=A0 This email is meant only for the intended recipient. If you have received= =20 this email in error, any review, use, dissemination,=C2=A0distribution, or= =20 copying of this email is strictly prohibited. Please notify us immediately= =20 of the error by return email and please=C2=A0delete this message from your= =20 system. Thank you in advance for your cooperation. For more information=20 about Post-Quantum, please visit www.post-quantum.com=20 . In the course of our business relationship,=20 we may collect, store and transfer information about you. Please see our=20 privacy=C2=A0notice at www.post-quantum.com/privacy-notice=20 to learn about how we use this= =20 information. --000000000000b98c7105cedf89e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Panos,

There are two drafts involved= here.=C2=A0

a) the main draft, https://da= tatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-multiple-ke/, cannot su= pport any public-key larger than 64KB, so it can never be used for KEMs lik= e McEliece. So the option 3 is implied here.

b) on= the other hand,=C2=A0https://datatracker.ietf.org/doc/draft-tjhai-ik= ev2-beyond-64k-limit/ is an attempt to address the issue with transferr= ing payload larger than 64KB. As you pointed out, transferring large blob o= f data in a live protocol is challenging and therefore it deservers separat= e treatments and considerations. It was deliberate that we split the hybrid= key exchange drafts into two, the second draft is there just in case there= is any interest in the working group on supporting the use KEMs like McEli= ece.=C2=A0
=C2=A0
Cheers,
CJ




On Thu, 21 Oct 2021 at 16:49, Kampanakis,= Panos <kpanos=3D40amazon= .com@dmarc.ietf.org> wrote:
Hi Valery, Tero,

> Not really. First, the situation with seven McEliece is not possible, = since all negotiated Key Exchange methods MUST be different.
Then, you seem to assume that the responder blindly accepts all the key exc= hanges at the initiator's will.
This is not true. First peers negotiate which key exchanges they will perfo= rm (including additional key exchanges), and you can limit the types and th= e number additional key exchanges the responder will accept via its local p= olicy.

I think the point is valid though if the responder supports McEliece. A mis= creant can that way make the responder put a lot of data on the wire like a= n amplification attack although the initiator has not been validated. QUIC = has a 3x amplification protection limits for that matter.

Sure, the issue existed even in ECDH exchanges, but the impact is much high= er when we talk MB of public keys.

Imo, McEliece is not practical for live protocols like TLS or IKEv2. Too ma= ny packets mean pretty high loss probability in unstable networks which mea= ns pretty bad performance unless everything happens in the datacenter or ro= bust end-to-end network paths. The PQ KEMs that will end up being standardi= zed are likely to have just a few KBs of public key and ciphertext which is= better for the general case.

So, I would say option 3 (prohibit the use of very large KE payloads like M= cEliece's MB sized public keys) is more practical.

Rgs,
Panos





-----Original Message-----
From: IPsec <ipsec-bounces@ietf.org> On Behalf Of Valery Smyslov
Sent: Tuesday, October 19, 2021 11:46 AM
To: 'Daniel Herzinger' <daniel_herzinger@genua.de>; ipsec@ietf.org
Cc: ietf@gazdag.de<= br> Subject: RE: [EXTERNAL] [IPsec] Cost-efficient quantum-resistant DoS protec= tion

CAUTION: This email originated from outside of the organization. Do not cli= ck links or open attachments unless you can confirm the sender and know the= content is safe.



Hi Daniel and Stefan-Lukas,

> Hi,
>
> in response to the new version of
> draft-ietf-ipsecme-ikev2-multiple-ke-04.txt, we wanted to emphasize > the issue of DoS attacks during intermediate exchanges. The new
> version does address it by mentioning the option of simply avoiding > intermediate exchanges altogether but still require additional key > exchanges. Yet, this protects only against record-and-harvest attacks =
> but not against an attacker with a strong quantum computer at the time=
> of the handshake, regardless of quantum-resistant authentication
> (since they can break the initial shared secret and therefore
> recalculate the MAC which authenticates the followup exchanges, fully =
> establishing a man-in-the-middle). We doubt that an attacker, even wit= h a strong quantum computer, is able to break a key exchange in such a shor= t time period. Still, this assumption is too theoretical to rely on. This, = together with the fact that Group-IKE is incompatible with key exchanges du= ring followup exchanges, makes the option seem inferior to just sticking to= intermediate exchanges during the handshake. However, we must also conside= r the draft-tjhai-ikev2-beyond-64k-limit-01.txt.
> An attacker who exploits the large key exchanges, e.g., by requesting =
> seven additional maximum size McEliece key exchanges, can force a gate= way to accept and process 1.4MB of data per McEliece KEM.

Not really. First, the situation with seven McEliece is not possible, since= all negotiated Key Exchange methods MUST be different.
Then, you seem to assume that the responder blindly accepts all the key exc= hanges at the initiator's will.
This is not true. First peers negotiate which key exchanges they will perfo= rm (including additional key exchanges), and you can limit the types and th= e number additional key exchanges the responder will accept via its local p= olicy.

> This leaves us at
> a situation where we must pick one of the following options:
>
>=C2=A0 1. Accept the highly increased risk of DoS attacks.
>=C2=A0 2. Prohibit the use of large KE payloads, hence the McEliece mec= hanism.
>=C2=A0 3. Prohibit the use of intermediate exchanges, leaving the IKE S= A
> initially unprotected and being vulnerable to an attacker with a quant= um computer during the handshake.
>
> To us, none of these options seems desirable. Thus, we propose another=
> solution which sees one new transform type, e.g., SNTRUP761X25519, > which then defines a combination of one classical algorithm (like

I'm confused here - did you mean new transform type or new transform ID= ?
Transform types define a kind of algorithms (or other features, like ESN), = while transform IDs define a particular algorithm of this type.

Unless I'm missing something I presume you meant new transform ID which= defines a new key exchange algorithm which is a combination of SNTRUP761 a= nd X25519.
Correct me if I'm wrong.

> ECDH based on curve25519) and one pqc algorithm which fits into
> IKE_SA_INIT without fragmentation (like sntruprime761). The two
> secrets get concatinated and then fed to a hash function. The
> resulting hash is used as the shared secret for further key
> derivation. This mechanism is low effort in terms of implementation > and does not affect the state machine at all, but already offers a > high level of protection against all attacks as long as there is no ma= jor break-through in cryptanalysis. Furthermore, it is the accepted approac= h for most of the applications of post-quantum key exchanges. For higher lo= ng-term security, it can be combined with other, more conventional algorith= ms which follow either in intermediate or followup exchanges.

I think that this combined key exchange algorithm can also be implemented (= with more flexibility) by doing IKE_SA_INIT(X25519)+IKE_INTERMEDIATE(SNTRUP= 761). I don't think your approach has real advantages in terms of consu= ming responder's resources. The responder still needs to perform both X= 25519 and SNTRUP761 before it authenticates the initiator.
Yes, you save one round trip, but the amount of data sent on the wire and t= he amount of CPU cycles are roughly the same. I'd like also mention tha= t while X25519 and SNTRUP761 public keys are fit into a single 1500 bytes I= KE message, they leave relatively little space for SA payload, so initiator= may be limited in expressing its proposals.

> We then propose to restrict the use of large key exchanges to the
> context of option 3, which removes the risk of the described DoS
> attacks. Yet, to prevent the insecurities of plain option 3, we also p= ropose to make it mandatory to combine it with the new hybrid transform typ= e, i.e., SNTRUP761X25519.

Are you proposing to stick with these two particular algorithms?
I don't think it's a good idea, giving the algorithm agility requir= ements.
I think that the same result can be achieved with the current draft:

IKE_SA_INIT(X25519 or whatever else)
IKE_INTERMEDIATE(SNTRUP761 or whatever else with small public key) IKE_AUTH= (Childless if you want) CREATE_CHILD_SA+IKE_FOLLOWUP_KE(McEliece or whateve= r else with long public key)

This leaves much more flexibility in selecting particular algorithms.

> The only downside of this approach is that G-IKE is then incompatible =
> with the McEliece exchange. However, the fact that G-IKE exchanges > sensitive information before authentication makes it impossible to be =
> not vulnerable against the discussed DoS attack and, at the same time,= support the McEliece algorithm. Thus, we see that as a decision to be made= in the G-IKE standardization track, not in IKEv2.

I agree that G-IKEv2 is very special, but I also agree with Tero's prev= ious message that protecting IKEv2 and (G-IKEv2 too) against DoS attacks le= aves in slightly different area.
We have some mechanisms for this (not perfect, but that is that).

Regards,
Valery.

> Regards,
>
> Stefan-Lukas Gazdag, Daniel Herzinger

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

<= /div>
PQ Solutions Limited (trading as =E2=80=98Post-Quantum=E2=80=99) = is a private limited company incorporated in England and Wales with=C2=A0registered number 06808505.
=C2=A0
This= email is meant only for the intended recipient. If you have received this = email in error, any review, use, dissemination,=C2=A0distribution,= or copying of this email is strictly prohibited. Please notify us immediat= ely of the error by return email and please=C2=A0delete this message from= your system. Thank you in advance for your cooperation.
<= span style=3D"font-size:13px;font-family:Arial,Helvetica,sans-serif">
For more information about Post-Quantum, please visit www.post-quantum.com.
--000000000000b98c7105cedf89e2-- From nobody Sun Oct 24 04:43:07 2021 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BDC83A0AFA; Sun, 24 Oct 2021 04:42:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <163507577033.16386.4323448732896467004@ietfa.amsl.com> Date: Sun, 24 Oct 2021 04:42:50 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-iptfs-11.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2021 11:42:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : IP-TFS: Aggregation and Fragmentation Mode for ESP and its Use for IP Traffic Flow Security Author : Christian Hopps Filename : draft-ietf-ipsecme-iptfs-11.txt Pages : 30 Date : 2021-10-24 Abstract: This document describes a mechanism for aggregation and fragmentation of IP packets when they are being encapsulated in ESP payload. This new payload type can be used for various purposes such as decreasing encapsulation overhead for small IP packets; however, the focus in this document is to enhance IPsec traffic flow security (IP-TFS) by adding Traffic Flow Confidentiality (TFC) to encrypted IP encapsulated traffic. TFC is provided by obscuring the size and frequency of IP traffic using a fixed-sized, constant-send-rate IPsec tunnel. The solution allows for congestion control as well as non- constant send-rate usage. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-iptfs-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-iptfs-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 25 11:19:11 2021 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0DBC3A153E; Mon, 25 Oct 2021 11:19:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <163518594088.29638.3891670131687133802@ietfa.amsl.com> Date: Mon, 25 Oct 2021 11:19:00 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc8229bis-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 18:19:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : TCP Encapsulation of IKE and IPsec Packets Authors : Valery Smyslov Tommy Pauly Filename : draft-ietf-ipsecme-rfc8229bis-01.txt Pages : 30 Date : 2021-10-25 Abstract: This document describes a method to transport Internet Key Exchange Protocol (IKE) and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as "TCP encapsulation", involves sending both IKE packets for Security Association establishment and Encapsulating Security Payload (ESP) packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP. TCP encapsulation for IKE and IPsec was defined in [RFC8229]. This document updates specification for TCP encapsulation by including additional clarifications obtained during implementation and deployment of this method. This documents makes RFC8229 obsolete. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc8229bis/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-rfc8229bis-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc8229bis-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 25 12:29:31 2021 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9F63A0D35; Mon, 25 Oct 2021 12:29:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <163519016233.15536.8819983820447250347@ietfa.amsl.com> Date: Mon, 25 Oct 2021 12:29:22 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-yang-iptfs-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 19:29:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : A YANG Data Model for IP Traffic Flow Security Authors : Don Fedyk Christian Hopps Filename : draft-ietf-ipsecme-yang-iptfs-02.txt Pages : 27 Date : 2021-10-25 Abstract: This document describes a yang module for the management of IP Traffic Flow Security additions to IKEv2 and IPsec. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-yang-iptfs/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-yang-iptfs-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-yang-iptfs-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 25 14:08:11 2021 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F873A0798; Mon, 25 Oct 2021 14:08:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <163519608583.24606.8591699666158093113@ietfa.amsl.com> Date: Mon, 25 Oct 2021 14:08:05 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-labeled-ipsec-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 21:08:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Labeled IPsec Traffic Selector support for IKEv2 Authors : Paul Wouters Sahana Prasad Filename : draft-ietf-ipsecme-labeled-ipsec-06.txt Pages : 10 Date : 2021-10-25 Abstract: This document defines a new Traffic Selector (TS) Type for Internet Key Exchange version 2 to add support for negotiating Mandatory Access Control (MAC) security labels as a traffic selector of the Security Policy Database (SPD). Security Labels for IPsec are also known as "Labeled IPsec". The new TS type is TS_SECLABEL, which consists of a variable length opaque field specifying the security label. This document updates the IKEv2 TS negotiation specified in RFC 7296 Section 2.9. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-labeled-ipsec/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-labeled-ipsec-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-labeled-ipsec-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 25 14:10:37 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1EB3A08E7 for ; Mon, 25 Oct 2021 14:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdhk3FeZ-_Ka for ; Mon, 25 Oct 2021 14:10:30 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.85]) (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 E05C43A0764 for ; Mon, 25 Oct 2021 14:10:11 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4HdSJx49z0zKXJ; Mon, 25 Oct 2021 23:10:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1635196209; bh=rvkt5t4vpow5GzY3dSeys+wp4jiCzjgchLDL19zgaVQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=duFwkfxvrG0I2cr0g/7NDI+Y9uqlNS77GWkV0skERI+iN8x/cJTWMfZ08+anfYr4i 6ujx7VkYrz7+pEFmwg2arsAo/pKw1XuU60xqAWVqUDIeC81hhdnOUMt5ql6Nc5pNTu 4bk/lpAPbXVHlrX5VmlqLFpdVZSnBg1U2D+i25l4= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id w8nnvGKRSH79; Mon, 25 Oct 2021 23:10:07 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 25 Oct 2021 23:10:07 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 421F012BD15; Mon, 25 Oct 2021 17:10:06 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 40E8012BD14; Mon, 25 Oct 2021 17:10:06 -0400 (EDT) Date: Mon, 25 Oct 2021 17:10:06 -0400 (EDT) From: Paul Wouters To: Valery Smyslov cc: 'Tero Kivinen' , ipsec@ietf.org In-Reply-To: <2d1501d799ba$af76bc40$0e6434c0$@gmail.com> Message-ID: References: <24831.15082.263253.443690@fireball.acr.fi> <2d1501d799ba$af76bc40$0e6434c0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] WGLC of draft-ietf-ipsecme-labeled-ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 21:10:36 -0000 On Wed, 25 Aug 2021, Valery Smyslov wrote: > sorry for being late, the GGLC is already over, but I was really busy to review the draft before. And sorry for my late response.. > 1. Section 1.2. > The last para is erroneous here, since the immediately following the first para of Section 1.3 > states exactly the same with more details. Either remove it or rephrase and move to 1.3 (e.g. > to keep provided example). It is actually different. Section 1.2 only clarifies content of RFC 7296. Sectin 1.3 describes to update to RFC 7296. > 2. Section 2.2. > If the TS_SECLABEL is present in a TSi/TSr, at least one Traffic > Selector of type TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE MUST also > be present in that TSi/TSr. > > I think this requirement was already spelled out in more generic form in 1.3. > Why it is repeated here? Defense in depth against sloppy implementers? I removed this one :P > 3. Section 2.2 > A zero length Security Label MUST NOT be used. If a received TS > payload contains a TS_TYPE of TS_SECLABEL with a zero length Security > Label, that specific Traffic Selector MUST be ignored. If no other > Traffic Selector of TS_TYPE TS_SECLABEL can be selected, a > TS_UNACCEPTABLE Error Notify message MUST be returned. A zero length > Security Label MUST NOT be interpreted as a wildcard security label. > > I wonder why zero-length TS_SECLABEL cannot be used to represent "no security label"? > This would significantly simplify negotiation when using security labels are optional > for initiator. Currently it is proposed that initiator performs two attempts > to establish Child SA in this case - with and without TS_SECLABEL. > If zero-length TS_SECLABEL meant "no security label", then a single CREATE_CHILD_SA > would be sufficient. It would also simplify the IKE state machine for this case. > > Are there any reasons I'm not aware of? If new implementations start using this, it would be incompatible with old implementations that would reject any TS set with unknown TS_TYPE, and would also lead to two attempts. We also wanted to avoid ambiguity with NULL or the empty string. And wanted a clear signal for wanting a TS_SECLABEL to not signify "no sec label". I am nervous that implementations would fail to insist on a label because it got an empty label. So again, defense in depth against sloppy implementers. Note that in all cases I am aware of, there is no use case of "optional security labels" and both ends always need to configure the exact same label. So there is not really a cause of "retrying without security label". I know this might look useful upgrading existing deployments from no label to sec label, but in practise, I have not seen this. People start with insisting proper labels. > 4. Section 2.2 > If multiple Security Labels are allowed for a given IP protocol, > start and end address/port match, multiple TS_SECLABEL can be > included in a TS payload. > > This sentence is unclear for me. If the initiator includes multiple TS_SECLABEL, > does it mean that the responder must select exactly one of them or not? > If yes, then can you please clarify, that the presence of multiple TS_SECLABEL > means that selection any of them is acceptable for the initiator. Changed to: If multiple Security Labels are allowed for a given IP protocol, start and end address/port match, the initiator includes all of the acceptable TS_SECLABEL's and the responder MUST select one of them. > 5. Section 2.2: > What is "TS_set", which is mentioned twice in the last para? > This acronym was never used before in the dicument. Changed. Old text: A responder that selected a TS with TS_SECLABEL MUST use the Security Label for all selector operations on the resulting IPsec SA. It MUST NOT select a TS_set with a TS_SECLABEL without using the specified Security Label, even if it deems the Security Label optional, as the initiator TS_set with TS_SECLABEL means the initiator mandates using that Security Label. New text: A responder that selected a TS with TS_SECLABEL MUST use the Security Label for all selector operations on the resulting TS. It MUST NOT select a TS_SECLABEL without using the specified Security Label, even if it deems the Security Label optional, as the initiator has indicated (and expects) that Security Label will be set for all traffic matching the negotiated TS. (I avoided talking about IPsec SA or Child SA, as one of those _may_ include multiple different TS'es) (If you find the term TS confusing, see Section 1.2 where I blame the WG for an unclear definition in RFC 7296 :) > 6. Section 3. > Each TS payload (TSi and TSr) MUST contain at least one TS_TYPE of > TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE. > > This is repeated for the third time in the document. Can you please keep the only > instance of this requirement? Okay, I removed the middle one as it really talked about TS_LABEL properties only. I left the "update RFC 7296" one and this one which is actually about the negotiation. > 7. Section 3. > A responder MUST create its TS response by selecting one of each > TS_TYPE present in the offered TS by the initiator. If it cannot > select one of each TS_TYPE, it MUST return a TS_UNACCEPTABLE Error > Notify payload. Changed to: A responder MUST create each TS response by creating one of more (narrowed or not) TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE entries, plus one of each further TS_TYPE present in the offered TS by the initiator. If this is not possible, it MUST return a TS_UNACCEPTABLE Error Notify payload. > and later > > Some TS_TYPE's support narrowing, where the responder is allowed to > select a subset of the original TS. Narrowing MUST NOT result in an > empty selector for that TS_TYPE. I removed this paragraph. > This is wrong with regard to TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE. > The responder may return any subset of TSs with TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE. > E.g, if the initiator included 5 TSs with TS_IPV4_ADDR_RANGE and 3 with TS_IPV6_ADDR_RANGE, > then the responder is free to return (just as example) only 2 TS_IPV4_ADDR_RANGE and no TS_IPV6_ADDR_RANGE, > and all of them may have different content (due to narrowing). Agreed. > 8. Section 3.2: > It would be unlikely that the traffic for TSi and TSr would have a > different Security Label, but this specification does allow this to > be specified. > > Can you please provide some examples of possible semantics of > different TS_SECLABELs in TSi and TSr? Sending different > security labels in different directions? Just for curiosity. I cannot, but I wanted to ensure not to accidentally forbid it. What we do see with our implementation though, that we end up with two IPsec Sa's where each is only used in one direction. For example, image you have an SElinux context for nfs-server and nfs-client. What happens is that the NFS client triggers one label on the outgoing connection, triggers ACQUIRE, sets up an IPsec SA with a label "nfs-client". The first packet hits the NFS server, which to reply hits a different SElinux context of "nfs-server". So it will trigger an ACQUIRE and setup a second IPsec SA with a label "nfs-server". Both IPsec SA's will only be used in one direction. I did not add any of this into the document, as it is very SElinux specific, where as the draft is agnostic on the meaning of SEC_LABEL and allows for other mechanisms that might not have this complexity. > 9. Section 3.2: > Rekey of an > IPsec SA MUST only use identical Traffic Selectors, which means the > same TS Type and selectors MUST be used. This guarantees that a > Security Label once negotiated, remains part of the IPsec SA after a > rekey. > > I think it is a too strong requirement. Traditionally in IKEv2 the rekey operation > is equivalent to creating a new Child SA with full negotiation of algorithms and > TSs. I used the RFC 7296 language in the new text: The mechanism of narrowing of Traffic Selectors with TS_IPV4_ADDR_RANGE and TS_IPV6_ADDR_RANGE does not apply to TS_SECLABEL as the Security Label itself is not interpreted and cannot be narrowed. It MUST be matched exactly. Since a rekey MUST NOT narrow down the Traffic Selectors narrower than the scope currently in use, the only valid choice of TS_SECLABEL for a rekey is the identical TS_SECLABEL that is in use by the Child SA being rekeyed. If the TS_LABEL is missing from the TS during the rekey negotiation, the negotiation MUST fail with TS_UNACCEPTABLE. diffs available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-labeled-ipsec-06.txt Paul From nobody Mon Oct 25 14:50:15 2021 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C207F3A1240; Mon, 25 Oct 2021 14:50:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <163519860475.11183.12720763379101629693@ietfa.amsl.com> Date: Mon, 25 Oct 2021 14:50:04 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev1-algo-to-historic-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 21:50:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Deprecation of IKEv1 and obsoleted algorithms Author : Paul Wouters Filename : draft-ietf-ipsecme-ikev1-algo-to-historic-02.txt Pages : 7 Date : 2021-10-25 Abstract: Internet Key Exchange version 1 (IKEv1) is deprecated. Accordingly, IKEv1 has been moved to Historic status. A number of old algorithms that are associated with IKEv1, and not widely implemented for IKEv2 are deprecated as well. This document adds a Status column to the IANA IKEv2 Transform Type registries. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev1-algo-to-historic/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev1-algo-to-historic-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev1-algo-to-historic-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 25 15:00:18 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2E13A0DBF for ; Mon, 25 Oct 2021 15:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aiven.io Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvwL58UZhYgi for ; Mon, 25 Oct 2021 15:00:12 -0700 (PDT) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B83C93A0DD6 for ; Mon, 25 Oct 2021 14:58:20 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id g8so4538093edb.2 for ; Mon, 25 Oct 2021 14:58:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aiven.io; s=google; h=date:from:to:subject:message-id:mime-version:content-id; bh=wa6N5DeaFKsuHfZ9P9eEZLpu8iY9e4YvfbLolsR8a4g=; b=Lx+kbCF5KG3ruFhzg2qbbQcrXgWgEy/T1/8fbyZoADXVoVaVLkH90yM5g4Z0kZcmfq MvtXercZdK6TJjAeuzp+aIRmUE70ciM+I2dzKhpUpujEFt4LQon33kunVtSaB5jYfOUg FMT1LJyXEgM+00MIsMCh8rRG5GIBZw7DSCYbE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-id; bh=wa6N5DeaFKsuHfZ9P9eEZLpu8iY9e4YvfbLolsR8a4g=; b=yKzaj+A5c75LbiIDe4mIks2owAfzP0x/6SQ0scXVxXsaj0RtmFF7kGlIjRp2PQt9Gh CGbzPadhxML8sIWB9aKKc1as/p9s857usI6vneSnPEE4KGmBZ2U4L0MsAYkuUSAy8yEG RpgA1iB95VlO1Kj3/oghtlUaDaibgD2yzTyL1rPMNbbW0l6Dpu6RH8+pcF9mWmHoaefb hPcu1DoW7R64JY4AzJB1eZOppWYwmVsiB543SxjgBKRS+bjhSq1SzuqsZbxgRB3zSQhY ouqyipSraDwzsYrSOOq+lSXi/1y867nXKl4L2spvKnnJ4j9U9Y9KmUhoFUfK78nPUl12 jH6g== X-Gm-Message-State: AOAM530Xpsef0dBQBkVsPPrxNSlHPR0SVXt+L7sFcs71DTfF8HQZJO8X nlwqwLXnVNq+HzbEM3xzUDkczXhTB0DDEF1JRLw= X-Google-Smtp-Source: ABdhPJyMhm9idnkg6GnodrXHhsky/ugkwY2HCjecLRdvM36tdSRyFsAHSnpciHgSMHYhIhlVkgc3Mg== X-Received: by 2002:a50:9d49:: with SMTP id j9mr29370543edk.39.1635199098027; Mon, 25 Oct 2021 14:58:18 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca. [193.110.157.194]) by smtp.gmail.com with ESMTPSA id g8sm2029847edb.71.2021.10.25.14.58.17 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Oct 2021 14:58:17 -0700 (PDT) Date: Mon, 25 Oct 2021 17:58:15 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="1858192029-56735449-1635198790=:376674" Content-ID: Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic (fwd) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 22:00:17 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1858192029-56735449-1635198790=:376674 Content-Type: text/plain; CHARSET=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: <3a6bd8ba-c927-fb34-d4f1-c3d0fcf0f8f6@aiven.io> On Mon, 28 Jun 2021, Dan Harkins wrote: > On 6/28/21 1:23 AM, Valery Smyslov wrote: >> - Is it OK that the intended status is Standards Track? Shouldn't it be >> BCP? I think because it contains IANA actions, it should be Standards Track. >> - The draft states that it updates RFC 7296, 8221, 8247. What in >> particular is being updated? >From the abstract: A number of old algorithms that are associated with IKEv1, and not widely implemented for IKEv2 are deprecated as well. This document adds a Status column to the IANA IKEv2 Transform Type registries. >> I believe the recent IESG directives require a short explanation of >> what is being updated >> to be present in Abstract. In any case, it should be clearly indicated >> in the body of the document. >> Have I missed it? I think you did? :) >> - Section3: I think that phrase "IKEv2 is a more secure protocol than >> IKEv1 in every aspect." is a bit too vague. > >   You know, that was bugging me too. "in every aspect" is laying it on a bit > thick. IKEv1 > has a security proof. The much maligned PSK mode authenticates the key as > well as the > exchange which is better than what IKEv2 does (and why IKEv1 did not need an > update to do > PQC). So saying it's less secure "in every aspect" just isn't true. But I > couldn't figure > out a better way to say it.... I have removed "in every aspect", as the text was proposed by Dan, and now proposed for removal by Dan. >> I believe it's better to list security aspects where we believe IKEv2 >> is superior: >> >> * IKEv2 supports modern cryptographic primitives, including AEAD >> ciphers >> * IKEv2 provides real defense against DoS (cookies, core spec) and DDoS >> (puzzles, RFC 8019) attacks >> * support for post-quantum crypto in IKEv2 is being developed >> (draft-ietf-ipsecme-ikev2-multiple-ke) >> * IKEv2 supports various authentication methods via integration with >> EAP (core spec) >> * an extension that allows build PAKE methods in IKEv2 exists (RFC >> 6467) >> * did I forget something? > >   But this is great! I agree that such a brief summary of the superior > features would be better than a factually challenged "in every aspect" > statement. Listing the good new stuff does not really put the focus on the deployed old bad stuff. I believe it is better to focus on why IKEv1 is bad. But I have added a paragraph paraphrasing this text. I did not use a bullet list to make it more informal and not look like it is claiming a complete list of items. I also removed DH 5 from mentioned as some indicated it is probably still pretty safe, so I changed "2 and 5" to "1 and 2". And I incorporated Valery's earlier comments. Diff available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev1-algo-to-historic-02.txt Paul --1858192029-56735449-1635198790=:376674-- From nobody Tue Oct 26 05:26:08 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACE53A110C for ; Tue, 26 Oct 2021 05:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQMqEvT-Ujce for ; Tue, 26 Oct 2021 05:26:01 -0700 (PDT) Received: from gg.genua.de (gg-0.genua.de [80.154.94.10]) (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 DABDD3A0C7F for ; Tue, 26 Oct 2021 05:26:00 -0700 (PDT) Received: from gg.genua.de (localhost [127.0.0.1]) by gg.genua.de (Postfix) with ESMTP id F121433F1ED; Tue, 26 Oct 2021 14:25:56 +0200 (CEST) Received: (from localhost) by gg.genua.de (MSCAN) id 5/gg.genua.de/smtp-gw/mscan; Tue Oct 26 14:25:56 2021 From: Daniel Herzinger To: CJ Tjhai , "Kampanakis, Panos" CC: Valery Smyslov , "ipsec@ietf.org" , "ietf@gazdag.de" Thread-Topic: [IPsec] Cost-efficient quantum-resistant DoS protection Thread-Index: AQHXxAHuDuDAcAFigkC0od08vH3ixavaVyuAgAMloACAAA4JAIAF0SVn Date: Tue, 26 Oct 2021 12:25:37 +0000 Message-ID: <4d3d0181b23048bb9b57f1c97672c1ea@genua.de> References: <935923623769463b80caf7b64bfe430a@genua.de> <07a701d7c500$5c3fdcc0$14bf9640$@gmail.com> <994547d5af7a47b2b4819136af4b29fd@EX13D01ANC003.ant.amazon.com>, In-Reply-To: Accept-Language: de-DE, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.217.185] MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="----FED3DD826F323787C234CAB6A1B12176" Archived-At: Subject: Re: [IPsec] Cost-efficient quantum-resistant DoS protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2021 12:26:07 -0000 ------FED3DD826F323787C234CAB6A1B12176 Content-Language: de-DE Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, the fact is that accepting a significantly increased amount of data from an= unauthenticated peer also significantly increases the surface to DoS attac= ks. Even without surpassing the 64KB limit, this must be a concern. IKEv2's= cookie mechanism and puzzles try to increase the cost of the attacker per = each connection. Now, an attacker must still accept these costs but can use= one connection to trigger several key exchanges, all significantly larger = than what we had with DH, making the trade-off way better for them compared= to non-pqc IKEv2. So, the attacker could, e.g., negotiate several FrodoKEM= s (all with different parameters to circumvent the rule that all key exchan= ge methods must be different). Compared to classical non-hybrid (EC)DH, suc= h a DoS attack requires significantly less cost to have the same effect. The introduction of MB-sized key exchanges just amplifies this problem even= further (also allowing several McEliece KEMs with different parameters cir= cumventing this constraint). Thus, while we should already thoroughly asses= and mitigate the risk of this possible weakness for https://datatracker.ie= tf.org/doc/draft-ietf-ipsecme-ikev2-multiple-ke/, we definitely must do it = for https://datatracker.ietf.org/doc/draft-tjhai-ikev2-beyond-64k-limit/. Currently, there is no place defined where a McEliece-sized key exchange ca= n take place. So, at least one of the two drafts (probably beyond-64k or mu= ltiple-ke) or better both should make this clear. At the moment, beyond-64k= defines how the transmission of such key exchanges could look like but the= question of where these ideas could be put into action are left to the rea= der, leading to inevitable confusion. The fact that there are several draft= s aiming at the same problem, without really defining their contact points = or interactions, further exacerbates this. The most obvious way to prevent an attacker from exploiting the new attack = surface is to accept the larger key exchanges only from an already authenti= cated peer. As mentioned before, we think childless IKEv2 with immediate re= keying would be a good compromise to achieve that. > Imo, McEliece is not practical for live protocols like TLS or IKEv2. McEliece is more trusted than its pqc alternatives which also makes it the = favored choice of some agencies like the German BSI. Obviously, they all kn= ow the challenges of integrating such large key exchanges, still they would= surely appreciate any effort which goes into this direction. This justifie= s pursuing the idea further, especially since first measurements look bette= r than one would probably expect. To give more insight about these measurements, we implemented all three dra= fts and tested the performance of a medium-sized McEliece key exchange unde= r different networking conditions (variable latency, packet loss, and throu= ghput). Especially when packet loss or throughput surpass specific threshho= lds (~ above 1% packet loss and below 3Mbit of throughput), the overall per= formance suffers significantly. Yet, we deem those values acceptable, as lo= ng as we don't use cellular or similarly unreliable networks. Furthermore, = we expect a gateway communicating with many peers to have higher requiremen= ts to its network uplink. Yet, as this will most likely be positioned in a = data center, this challenge should also be doable. Altogether, this left us= with a surprisingly positive view on the possibility of adopting McEliece-= sized key exchanges at least for some use-cases. The introduction of new Transform-IDs like SNTRUP761X25519 is a good short-= term solution, as it addresses the problem without requiring much effort in= terms of standardization or implementation. This becomes even more importa= nt, as intermediate exchanges and their high complexity, due to their inter= connectedness with authentication, mean that especially the IKEv2 implement= ations of smaller projects will take their time for its integration. Thus, = having an easier short-term solution at hand means a real advantage. Also, the constrained size of such transforms mostly eliminates the aforeme= ntioned DoS risks. Finally, should the beyond-64k draft be adopted, then having a small set of= such additional Tranform-IDs is even more beneficial since it makes preven= ting the unlikely yet possible attack described in our initial mail easier. Regards, Stefan and Daniel ________________________________________ Von: CJ Tjhai Gesendet: Donnerstag, 21. Oktober 2021 18:39:16 An: Kampanakis, Panos Cc: Valery Smyslov; Daniel Herzinger; ipsec@ietf.org; ietf@gazdag.de Betreff: Re: [IPsec] Cost-efficient quantum-resistant DoS protection Hi Panos, There are two drafts involved here. a) the main draft, https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev= 2-multiple-ke/, cannot support any public-key larger than 64KB, so it can n= ever be used for KEMs like McEliece. So the option 3 is implied here. b) on the other hand, https://datatracker.ietf.org/doc/draft-tjhai-ikev2-be= yond-64k-limit/ is an attempt to address the issue with transferring payloa= d larger than 64KB. As you pointed out, transferring large blob of data in = a live protocol is challenging and therefore it deservers separate treatmen= ts and considerations. It was deliberate that we split the hybrid key excha= nge drafts into two, the second draft is there just in case there is any in= terest in the working group on supporting the use KEMs like McEliece. Cheers, CJ On Thu, 21 Oct 2021 at 16:49, Kampanakis, Panos > wrote: Hi Valery, Tero, > Not really. First, the situation with seven McEliece is not possible, sin= ce all negotiated Key Exchange methods MUST be different. Then, you seem to assume that the responder blindly accepts all the key exc= hanges at the initiator's will. This is not true. First peers negotiate which key exchanges they will perfo= rm (including additional key exchanges), and you can limit the types and th= e number additional key exchanges the responder will accept via its local p= olicy. I think the point is valid though if the responder supports McEliece. A mis= creant can that way make the responder put a lot of data on the wire like a= n amplification attack although the initiator has not been validated. QUIC = has a 3x amplification protection limits for that matter. Sure, the issue existed even in ECDH exchanges, but the impact is much high= er when we talk MB of public keys. Imo, McEliece is not practical for live protocols like TLS or IKEv2. Too ma= ny packets mean pretty high loss probability in unstable networks which mea= ns pretty bad performance unless everything happens in the datacenter or ro= bust end-to-end network paths. The PQ KEMs that will end up being standardi= zed are likely to have just a few KBs of public key and ciphertext which is= better for the general case. So, I would say option 3 (prohibit the use of very large KE payloads like M= cEliece's MB sized public keys) is more practical. Rgs, Panos -----Original Message----- From: IPsec > On Beha= lf Of Valery Smyslov Sent: Tuesday, October 19, 2021 11:46 AM To: 'Daniel Herzinger' >; ipsec@ietf.org Cc: ietf@gazdag.de Subject: RE: [EXTERNAL] [IPsec] Cost-efficient quantum-resistant DoS protec= tion CAUTION: This email originated from outside of the organization. Do not cli= ck links or open attachments unless you can confirm the sender and know the= content is safe. Hi Daniel and Stefan-Lukas, > Hi, > > in response to the new version of > draft-ietf-ipsecme-ikev2-multiple-ke-04.txt, we wanted to emphasize > the issue of DoS attacks during intermediate exchanges. The new > version does address it by mentioning the option of simply avoiding > intermediate exchanges altogether but still require additional key > exchanges. Yet, this protects only against record-and-harvest attacks > but not against an attacker with a strong quantum computer at the time > of the handshake, regardless of quantum-resistant authentication > (since they can break the initial shared secret and therefore > recalculate the MAC which authenticates the followup exchanges, fully > establishing a man-in-the-middle). We doubt that an attacker, even with a= strong quantum computer, is able to break a key exchange in such a short t= ime period. Still, this assumption is too theoretical to rely on. This, tog= ether with the fact that Group-IKE is incompatible with key exchanges durin= g followup exchanges, makes the option seem inferior to just sticking to in= termediate exchanges during the handshake. However, we must also consider t= he draft-tjhai-ikev2-beyond-64k-limit-01.txt. > An attacker who exploits the large key exchanges, e.g., by requesting > seven additional maximum size McEliece key exchanges, can force a gateway= to accept and process 1.4MB of data per McEliece KEM. Not really. First, the situation with seven McEliece is not possible, since= all negotiated Key Exchange methods MUST be different. Then, you seem to assume that the responder blindly accepts all the key exc= hanges at the initiator's will. This is not true. First peers negotiate which key exchanges they will perfo= rm (including additional key exchanges), and you can limit the types and th= e number additional key exchanges the responder will accept via its local p= olicy. > This leaves us at > a situation where we must pick one of the following options: > > 1. Accept the highly increased risk of DoS attacks. > 2. Prohibit the use of large KE payloads, hence the McEliece mechanism. > 3. Prohibit the use of intermediate exchanges, leaving the IKE SA > initially unprotected and being vulnerable to an attacker with a quantum = computer during the handshake. > > To us, none of these options seems desirable. Thus, we propose another > solution which sees one new transform type, e.g., SNTRUP761X25519, > which then defines a combination of one classical algorithm (like I'm confused here - did you mean new transform type or new transform ID? Transform types define a kind of algorithms (or other features, like ESN), = while transform IDs define a particular algorithm of this type. Unless I'm missing something I presume you meant new transform ID which def= ines a new key exchange algorithm which is a combination of SNTRUP761 and X= 25519. Correct me if I'm wrong. > ECDH based on curve25519) and one pqc algorithm which fits into > IKE_SA_INIT without fragmentation (like sntruprime761). The two > secrets get concatinated and then fed to a hash function. The > resulting hash is used as the shared secret for further key > derivation. This mechanism is low effort in terms of implementation > and does not affect the state machine at all, but already offers a > high level of protection against all attacks as long as there is no major= break-through in cryptanalysis. Furthermore, it is the accepted approach f= or most of the applications of post-quantum key exchanges. For higher long-= term security, it can be combined with other, more conventional algorithms = which follow either in intermediate or followup exchanges. I think that this combined key exchange algorithm can also be implemented (= with more flexibility) by doing IKE_SA_INIT(X25519)+IKE_INTERMEDIATE(SNTRUP= 761). I don't think your approach has real advantages in terms of consuming= responder's resources. The responder still needs to perform both X25519 an= d SNTRUP761 before it authenticates the initiator. Yes, you save one round trip, but the amount of data sent on the wire and t= he amount of CPU cycles are roughly the same. I'd like also mention that wh= ile X25519 and SNTRUP761 public keys are fit into a single 1500 bytes IKE m= essage, they leave relatively little space for SA payload, so initiator may= be limited in expressing its proposals. > We then propose to restrict the use of large key exchanges to the > context of option 3, which removes the risk of the described DoS > attacks. Yet, to prevent the insecurities of plain option 3, we also prop= ose to make it mandatory to combine it with the new hybrid transform type, = i.e., SNTRUP761X25519. Are you proposing to stick with these two particular algorithms? I don't think it's a good idea, giving the algorithm agility requirements. I think that the same result can be achieved with the current draft: IKE_SA_INIT(X25519 or whatever else) IKE_INTERMEDIATE(SNTRUP761 or whatever else with small public key) IKE_AUTH= (Childless if you want) CREATE_CHILD_SA+IKE_FOLLOWUP_KE(McEliece or whateve= r else with long public key) This leaves much more flexibility in selecting particular algorithms. > The only downside of this approach is that G-IKE is then incompatible > with the McEliece exchange. However, the fact that G-IKE exchanges > sensitive information before authentication makes it impossible to be > not vulnerable against the discussed DoS attack and, at the same time, su= pport the McEliece algorithm. Thus, we see that as a decision to be made in= the G-IKE standardization track, not in IKEv2. I agree that G-IKEv2 is very special, but I also agree with Tero's previous= message that protecting IKEv2 and (G-IKEv2 too) against DoS attacks leaves= in slightly different area. We have some mechanisms for this (not perfect, but that is that). Regards, Valery. > Regards, > > Stefan-Lukas Gazdag, Daniel Herzinger _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ________________________________ PQ Solutions Limited (trading as =91Post-Quantum=92) is a private limited c= ompany incorporated in England and Wales with registered number 06808505. This email is meant only for the intended recipient. If you have received t= his email in error, any review, use, dissemination, distribution, or copyin= g of this email is strictly prohibited. Please notify us immediately of the= error by return email and please delete this message from your system. Tha= nk you in advance for your cooperation. For more information about Post-Quantum, please visit www.post-quantum.com<= http://www.post-quantum.com>. In the course of our business relationship, we may collect, store and trans= fer information about you. Please see our privacy notice at www.post-quantu= m.com/privacy-notice to learn a= bout how we use this information. ------FED3DD826F323787C234CAB6A1B12176 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIU+QYJKoZIhvcNAQcCoIIU6jCCFOYCAQExDTALBglghkgBZQMEAgEwCwYJKoZI hvcNAQcBoIIRQDCCBA4wggL2oAMCAQICAw/drDANBgkqhkiG9w0BAQsFADBFMQsw CQYDVQQGEwJERTEVMBMGA1UECgwMRC1UcnVzdCBHbWJIMR8wHQYDVQQDDBZELVRS VVNUIFJvb3QgQ0EgMyAyMDEzMB4XDTEzMDkyMDA4MjU1MVoXDTI4MDkyMDA4MjU1 MVowRTELMAkGA1UEBhMCREUxFTATBgNVBAoMDEQtVHJ1c3QgR21iSDEfMB0GA1UE AwwWRC1UUlVTVCBSb290IENBIDMgMjAxMzCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAMR7QpKCH+ztVJiOEsDKCd+TbjqTXBvkEHeeTmmIbPbhafL2m6Jh sb0HIHSYZfGMJgjNqDXKgDbRY23oRHqCw2xe3rvoNtLEaDaMnzK9hCLg3MLuEEY5 ba+TOa6H5sO8Ccksa2db2Zt2dUwL4LvF17w+efJfvtGQV/mu9mZfMb/TbY+nukrz I2W7t++jJdcK6li274j6+nmyUljV8KyMoVF0KZWqUTuQMgOfHHJ0kN497WHS5eP9 ZEflubdKqfcfrpaGBKwv46SBd7daFv/YDz/2t3jMpK/6WzwSW6hSiXLviPPVRIGG lSOfe9282TTvfJQ8qsBBwuOdUBrA5Bki/LMCAwEAAaOCAQUwggEBMA8GA1UdEwEB /wQFMAMBAf8wHQYDVR0OBBYEFD+QyH3HFW/zJI+pwy9Log8hsi/nMA4GA1UdDwEB /wQEAwIBBjCBvgYDVR0fBIG2MIGzMHSgcqBwhm5sZGFwOi8vZGlyZWN0b3J5LmQt dHJ1c3QubmV0L0NOPUQtVFJVU1QlMjBSb290JTIwQ0ElMjAzJTIwMjAxMyxPPUQt VHJ1c3QlMjBHbWJILEM9REU/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDA7oDmg N4Y1aHR0cDovL2NybC5kLXRydXN0Lm5ldC9jcmwvZC10cnVzdF9yb290X2NhXzNf MjAxMy5jcmwwDQYJKoZIhvcNAQELBQADggEBAA5ZDljkdEgjRM80IbWcFBqtmku3 s4htXKkXcPAqn417+XuF+sc56BAIsDUrX88C0tOcyAse7gVUrjeTBAl9bI/CdLz4 HJS+MQFALfMkILeEVSxcyPV0ShAZi6PH7TXWCUjTDsC6OaiwRgKw28aIWcK+/Hux K89+YodVlswBb5tnIZU1i/gQ/HEbt0s3aaY71uyL7sGw8yXJj5J9oerDykS/JqV0 kpzjdOuddNnLTYfY/LRpbIugQwdgeJfp2ZN8wka8mzdSo+2KPBOpe1NLSZoRBSwL blasHy6CbOBpZ7UObS3Z5MAV8T/6GHLhFW0nWy0wKCufSJpkK5nv8nVJX1wwggT0 MIID3KADAgECAgMP4PYwDQYJKoZIhvcNAQELBQAwRTELMAkGA1UEBhMCREUxFTAT BgNVBAoMDEQtVHJ1c3QgR21iSDEfMB0GA1UEAwwWRC1UUlVTVCBSb290IENBIDMg MjAxMzAeFw0xMzA5MjcwNzMwNDBaFw0yODA5MjAwODI1NTFaMFsxCzAJBgNVBAYT AkRFMRUwEwYDVQQKDAxELVRydXN0IEdtYkgxNTAzBgNVBAMMLEQtVFJVU1QgQXBw bGljYXRpb24gQ2VydGlmaWNhdGVzIENBIDMtMSAyMDEzMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAsL/U1GFo1h3boKtaIzrEMPZHGI4FKLKLkjWJZYh1 CSa4URX8j52diNu1tmcTpwKOMiv03awa2lEElvrqVEhpMHOxK42q7WG7c4d0lkc7 d+cTrexeZlGAZ8rIsXcASttIf0106PkzjHclKZrJ6iN11ToWkjpPBsE9THKJ/2aw tRHDVQTq5Ode7n1aGay3/nNIeMf1ALe4Q93Xx2glcXU0ZgLPftRQKJF5ql800EgW WPe+tHArNBWzPh+NhoMzKfghnR+kPyUiFHd+ZzU+FU1XAvrqw3UAzPhp4vTKVXS+ IgqE9bRZW5CzBnXyZPFFtbuA3UJHPwKnS0bHNrw6DxIjrwIDAQABo4IB1TCCAdEw HwYDVR0jBBgwFoAUP5DIfccVb/Mkj6nDL0uiDyGyL+cwQgYIKwYBBQUHAQEENjA0 MDIGCCsGAQUFBzABhiZodHRwOi8vcm9vdC1jYS0zLTIwMTMub2NzcC5kLXRydXN0 Lm5ldDBmBgNVHSAEXzBdMFsGCysGAQQBpTQCgUgBMEwwSgYIKwYBBQUHAgEWPmh0 dHA6Ly93d3cuZC10cnVzdC5uZXQvaW50ZXJuZXQvZmlsZXMvRC1UUlVTVF9Sb290 X1BLSV9DUFMucGRmMIG+BgNVHR8EgbYwgbMwdKByoHCGbmxkYXA6Ly9kaXJlY3Rv cnkuZC10cnVzdC5uZXQvQ049RC1UUlVTVCUyMFJvb3QlMjBDQSUyMDMlMjAyMDEz LE89RC1UcnVzdCUyMEdtYkgsQz1ERT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0 MDugOaA3hjVodHRwOi8vY3JsLmQtdHJ1c3QubmV0L2NybC9kLXRydXN0X3Jvb3Rf Y2FfM18yMDEzLmNybDAdBgNVHQ4EFgQUGQOq2SJFxxpiqedcmbCd3u3UuLUwDgYD VR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwDQYJKoZIhvcNAQELBQAD ggEBABCOUPipaQNkTuhlpNOQk8lDCndO0Y9nuN8+Y99m/odfdUDN2MmOg0ICPVWN yg9bIHfxytRkNlFzCrc7B9KmzPAAiu7UwOXl3dnRrFJpluGcAbnDGRr1Ssgvb2HD mZwlU2K7TpMOt6XayFkiefx5q4WC67BbVcIPD1IZ2te0HRdmdh7zhIz2Hw1+bfuz zSNf8/JRYojIyweGq9uDue45yhVDl86O3GJaOphjDVm5c7mTdWg1xbJ244PhmpQH 3h1s+kfD76rg4mwAIQa3QkfX2BqMEc9ASiWm1L9iNA0Z4ng9tiuVm4LJKPVA2lZp px7+KtmVmv0/lv+8eGKwPvw1HlUwgggyMIIHGqADAgECAhBrvsOl+goq9gVz/cEm 7sAlMA0GCSqGSIb3DQEBCwUAMFsxCzAJBgNVBAYTAkRFMRUwEwYDVQQKDAxELVRy dXN0IEdtYkgxNTAzBgNVBAMMLEQtVFJVU1QgQXBwbGljYXRpb24gQ2VydGlmaWNh dGVzIENBIDMtMSAyMDEzMB4XDTIxMDkyMjE4NDExMloXDTIyMDkyNTE4NDExMlow gaoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpnZW51YSBHbWJIMRkwFwYDVQQDExBE YW5pZWwgSGVyemluZ2VyMR4wHAYDVQQHDBVLaXJjaGhlaW0gYi4gTcO8bmNoZW4x DzANBgNVBCoTBkRhbmllbDESMBAGA1UEBBMJSGVyemluZ2VyMRUwEwYDVQQFEwxD U00wMjc2MjM1OTgxDzANBgNVBAgTBkJheWVybjCCAiIwDQYJKoZIhvcNAQEBBQAD ggIPADCCAgoCggIBANqB5XCDmCsmv/nQdEpNf/77grsLiU23WXuM/5tfgBcBd8JZ Dv8r6GijQtSPZHj4nFKbkewHlJgFCGd20NtFMEi0rFnkDfJtFKsd7gZH+9yDdBWx btne1PiNhtgu3urLBs9gwUpBSrZSGo1L64PbKO3gxiBWzvF+ysTyBjYZ0MEhIolX nufVeLla5a3RQGFLqN2wJN5KwiPnix8x/iU0WELposT00Hw+vqX7geZmZkzHUO9a wgdpXx9LfmS5MQ/QSM8Pdjodzn/JGp6iLYlScsRQPlzlVKBJaGTiddRGkLgRpq5n av9loMUgD84JDbuVPPZ/keEvAzx6jS5688aa/TV+qBuNrC9DfpcrgKMVV4FEyBz5 dKKiPDtc3qLUFWLCQ0xBv0AH9VtT4LpbngPVU6xUXSvu30k+wrQosyD12hKxSNld cOkI2P1M0XG9lSW2PJRLJRSj7hrEAYm1zBpN7av232hG5DMx9lgOjfcv/6yIsO0p DFUNHfngOEDnctgNtFQrHNVlXWjGlycmedosZ6+QdfolaFyuLkksFkaayGcUFmde IGTL/9aMqIs6qX9ji8s/wEcwnNZwJoJnGOt8f0JdDIRN+GQ8juUNyEAEUQSD6zMq JvfJp8bRpVYoxxbnwFLVrstgpSfX8g3NeWF5ZkEVNW2023ZoEcqNAZ5g6MB/AgMB AAGjggOgMIIDnDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHwYDVR0j BBgwFoAUGQOq2SJFxxpiqedcmbCd3u3UuLUwggFJBggrBgEFBQcBAQSCATswggE3 MEgGCCsGAQUFBzABhjxodHRwOi8vYXBwbGljYXRpb24tY2VydGlmaWNhdGVzLWNh LTMtMS0yMDEzLm9jc3AuZC10cnVzdC5uZXQwWwYIKwYBBQUHMAKGT2h0dHA6Ly93 d3cuZC10cnVzdC5uZXQvY2dpLWJpbi9ELVRSVVNUX0FwcGxpY2F0aW9uX0NlcnRp ZmljYXRlc19DQV8zLTFfMjAxMy5jcnQwgY0GCCsGAQUFBzAChoGAbGRhcDovL2Rp cmVjdG9yeS5kLXRydXN0Lm5ldC9DTj1ELVRSVVNUJTIwQXBwbGljYXRpb24lMjBD ZXJ0aWZpY2F0ZXMlMjBDQSUyMDMtMSUyMDIwMTMsTz1ELVRydXN0JTIwR21iSCxD PURFP2NBQ2VydGlmaWNhdGU/YmFzZT8wbwYDVR0gBGgwZjBaBgsrBgEEAaU0AoFI AjBLMEkGCCsGAQUFBwIBFj1odHRwOi8vd3d3LmQtdHJ1c3QubmV0L2ludGVybmV0 L2ZpbGVzL0QtVFJVU1RfQ1NNX1BLSV9DUFMucGRmMAgGBgQAj3oBAzCCAUUGA1Ud HwSCATwwggE4MIIBNKCCATCgggEshoGGbGRhcDovL2RpcmVjdG9yeS5kLXRydXN0 Lm5ldC9DTj1ELVRSVVNUJTIwQXBwbGljYXRpb24lMjBDZXJ0aWZpY2F0ZXMlMjBD QSUyMDMtMSUyMDIwMTMsTz1ELVRydXN0JTIwR21iSCxDPURFP2NlcnRpZmljYXRl cmV2b2NhdGlvbmxpc3SGS2h0dHA6Ly9jcmwuZC10cnVzdC5uZXQvY3JsL2QtdHJ1 c3RfYXBwbGljYXRpb25fY2VydGlmaWNhdGVzX2NhXzMtMV8yMDEzLmNybIZUaHR0 cDovL2Nkbi5kLXRydXN0LWNsb3VkY3JsLm5ldC9jcmwvZC10cnVzdF9hcHBsaWNh dGlvbl9jZXJ0aWZpY2F0ZXNfY2FfMy0xXzIwMTMuY3JsMB0GA1UdDgQWBBQ7Mbel rokN1XgEHhDNqQnt4afO2TAOBgNVHQ8BAf8EBAMCBLAwJAYDVR0RBB0wG4EZZGFu aWVsX2hlcnppbmdlckBnZW51YS5kZTANBgkqhkiG9w0BAQsFAAOCAQEAbvMls9Zy PSq5BCwdLvvnT6UApYc34DzgNMqrhJ1QkHioS/145BkovzEC0FvmsMfxKOBpUH4p pL2V5XWbCNlaTokN3+xJyFTCut6LHYE+xPVaYoRTY5upVXXBetOwRxqmGRyF3sXX eeQAZhFKRodpuEM7X4Dno3eSaaPPK/vIl+jaI5A4/liyUA3mJkGBCtxji/UZ5bag B04aWsDkShBCCMi3ro4FutJa0GcJ2OYVwk+LFH1hLs13bzfBloXjMY0KRi+DtOhF xoxtdmrnA3d5JcsLzRV2n5sJ3bvbxrx97lnf2gFmUaeIhKL0VRHBWu0RKZOsQi3G kfw8EhilV8poEDGCA38wggN7AgEBMG8wWzELMAkGA1UEBhMCREUxFTATBgNVBAoM DEQtVHJ1c3QgR21iSDE1MDMGA1UEAwwsRC1UUlVTVCBBcHBsaWNhdGlvbiBDZXJ0 aWZpY2F0ZXMgQ0EgMy0xIDIwMTMCEGu+w6X6Cir2BXP9wSbuwCUwCwYJYIZIAWUD BAIBoIHkMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTIxMTAyNjEyMjUzOFowLwYJKoZIhvcNAQkEMSIEIKvZWcHn7UL+xl3lWtd+dNCD 7srWXEkWvp+kY+egY5tpMHkGCSqGSIb3DQEJDzFsMGowCwYJYIZIAWUDBAEqMAsG CWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqG SIb3DQEBAQUABIICAGDYOb/dREtavYFg5oe185C7gYhE5HZhMsPLAfZTC40CnaFs cqjvrk1bDPLbVxjNLMIa1KgiydbRyHAesoWWZUIUe539fSxx4dLd+qgM33rAY6zO OffueD+zP4NsN++y+ghM+kf84G5GeaY89p2fu60aab2yXpzrnO2d8R5tli1/pG/+ +EjyynShAr0vFN/lT+iyUq/QGvYvLABNXWLrGsWZXYRd2/sFmWECLYLyk6edKQdQ RipxYqYW5Oa9I2V9gNyEEcYOBEpjdCPtqM8M0o+keP19PlBi7At7kPu/29qzuoqx qopMm2jYuzazEoAFfs4RQEKlXd4/bU7eLjP4iUL72b90lxOQq3ovDQMdjA14/hBg Km42N4RhaJyj/DCVvtLwJRdHJZrgRyfCbQ9V2coqYsT+Xk6k6uUD4kUEUjfTo8mI ftim2D4/kNsazD9eiFG03kZQZN2nTBT89hxAm6SSyf6FwXNhWUfr6sD6sIqN0vu9 e2kUIXryGz0BJ2R7Vge4Efn5tD7cz9fnsEStdj5g9MJm/poSLkUbEp87DD90fkTX Xa++N/Bfc18xGa0MDOiXsn+rB1y+lpMQJni4aoMn7DJxBBYrlhUVE8Y0cUjDlrjK UpGNMX/8HNRSV5M9OyEOJjdkTyvFwwnMzZPVbPaOM16uw3p4xIX+zsEapnFu ------FED3DD826F323787C234CAB6A1B12176-- From nobody Tue Oct 26 10:35:40 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC7F83A15B4 for ; Tue, 26 Oct 2021 10:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTGDTTkD8QDn for ; Tue, 26 Oct 2021 10:35:31 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63FFA3A15B7 for ; Tue, 26 Oct 2021 10:35:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 7E54E180A3; Tue, 26 Oct 2021 13:36:30 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id uLIVNo1Se1EJ; Tue, 26 Oct 2021 13:36:30 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 1A8F818039; Tue, 26 Oct 2021 13:36:30 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CF318112B; Tue, 26 Oct 2021 13:35:26 -0400 (EDT) From: Michael Richardson To: Paul Wouters cc: "ipsec\@ietf.org WG" In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic (fwd) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2021 17:35:36 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Paul Wouters wrote: >> On 6/28/21 1:23 AM, Valery Smyslov wrote: >>> - Is it OK that the intended status is Standards Track? Shouldn't i= t be >>> BCP? > I think because it contains IANA actions, it should be Standards Trac= k. Agreed. (It would be funny for it to be Historic, but actually that's wrong) > Listing the good new stuff does not really put the focus on the deplo= yed > old bad stuff. I believe it is better to focus on why IKEv1 is bad. B= ut > I have added a paragraph paraphrasing this text. I did not use a bull= et > list to make it more informal and not look like it is claiming a > complete list of items. Great. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmF4PF4ACgkQgItw+93Q 3WWToQf+Oc2dvfKKYbZmSJwrzV3YbFi7BZ7VS31ajDebq62gJi3b0nl6iaZWuTBx SFFmxOO3gzNO3fhWp3Hmv21AKKXXzlfJEJm9R9EelGSNwoVAoE5MuylNoAfyjH4c qGjVDM7kvJRWQYn67lGa43F80Q+dR/5udC9Q15Pl1E82YHDW0RSPiSn6ILoWxizj BWbrjy708ZUKyaVI5dmjx5vWbqpFbdamIU5eXsePcReis+E3QWEFSf3DiUiNQwWM c70JwuhUvrD57EJ4H5nuxbuYvcirqFOAT8yD0QDQywOl22USa3oVAFa6vuFqgGP1 18y/eF2PHgRJI1dbNhVrC7AGW/4YTQ== =EadL -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Oct 26 10:37:43 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6120F3A15B8 for ; Tue, 26 Oct 2021 10:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.62 X-Spam-Level: X-Spam-Status: No, score=-9.62 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4M99NjChoDi1 for ; Tue, 26 Oct 2021 10:37:36 -0700 (PDT) Received: from smtp-fw-6002.amazon.com (smtp-fw-6002.amazon.com [52.95.49.90]) (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 D0D1C3A15B4 for ; Tue, 26 Oct 2021 10:37:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1635269856; x=1666805856; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=DSZS/L/cHDnjc2Ad1GfBm14Nd/0feXJkxziW2E5iN/0=; b=DbdCf5CeBboWzh3xSlAwUEVIws/O50BKUBUGtXwtadCUu0W3UkUnPu5D IBUhQo4ArWrUlUsJK8UOoI5m1V/DCw47ylXz6MbL6+sjAVxjrzC9FJI7Q wPko96A4rcqCiTyTXymn9fyWVOaxhy4dtXx65s8xux4hYxppZyk4E46ng 0=; X-IronPort-AV: E=Sophos;i="5.87,184,1631577600"; d="scan'208";a="150672113" Received: from iad12-co-svc-p1-lb1-vlan2.amazon.com (HELO email-inbound-relay-pdx-2b-22c2b493.us-west-2.amazon.com) ([10.43.8.2]) by smtp-border-fw-6002.iad6.amazon.com with ESMTP; 26 Oct 2021 17:37:26 +0000 Received: from EX13MTAUWB001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan3.pdx.amazon.com [10.236.137.198]) by email-inbound-relay-pdx-2b-22c2b493.us-west-2.amazon.com (Postfix) with ESMTPS id 2D3484276B; Tue, 26 Oct 2021 17:37:24 +0000 (UTC) Received: from EX13D01ANC003.ant.amazon.com (10.43.157.68) by EX13MTAUWB001.ant.amazon.com (10.43.161.249) with Microsoft SMTP Server (TLS) id 15.0.1497.24; Tue, 26 Oct 2021 17:37:24 +0000 Received: from EX13D01ANC003.ant.amazon.com (10.43.157.68) by EX13D01ANC003.ant.amazon.com (10.43.157.68) with Microsoft SMTP Server (TLS) id 15.0.1497.24; Tue, 26 Oct 2021 17:37:23 +0000 Received: from EX13D01ANC003.ant.amazon.com ([10.43.157.68]) by EX13D01ANC003.ant.amazon.com ([10.43.157.68]) with mapi id 15.00.1497.024; Tue, 26 Oct 2021 17:37:16 +0000 From: "Kampanakis, Panos" To: Daniel Herzinger CC: Valery Smyslov , "ipsec@ietf.org" , "ietf@gazdag.de" Thread-Topic: AW: [IPsec] Cost-efficient quantum-resistant DoS protection Thread-Index: AdfKgoM4fQq+bJnCT1uQuTijcBSWRw== Date: Tue, 26 Oct 2021 17:37:16 +0000 Message-ID: <70b270f5ed3842f28f18dbe1488399e7@EX13D01ANC003.ant.amazon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.156.207] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Cost-efficient quantum-resistant DoS protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2021 17:37:41 -0000 Hi Daniel,=20 > To give more insight about these measurements, we implemented all three d= rafts and tested the performance of a medium-sized McEliece key exchange un= der different networking conditions (variable latency, packet loss, and thr= oughput). Especially when packet loss or throughput surpass specific thresh= holds (~ above 1% packet loss and below 3Mbit of throughput), the overall p= erformance suffers significantly. Yet, we deem those values acceptable, as = long as we don't use cellular or similarly unreliable networks. Furthermore= , we expect a gateway communicating with many peers to have higher requirem= ents to its network uplink. Yet, as this will most likely be positioned in = a data center, this challenge should also be doable. Altogether, this left = us with a surprisingly positive view on the possibility of adopting McEliec= e-sized key exchanges at least for some use-cases. > The introduction of new Transform-IDs like SNTRUP761X25519 is a good shor= t-term solution, as it addresses the problem without requiring much effort = in terms of standardization or implementation. Understood. I am curious to see the measurements published btw. Are the pub= lic somewhere?=20 A couple counter arguments:=20 Cloudflare's tests (https://blog.cloudflare.com/the-tls-post-quantum-experi= ment/ ) showed a bunch of variability for way more compact KEMs than McElie= ce (SIKE, NTRU-HRSS) at the 95% and 99% percentile. https://www.ndss-sympos= ium.org/wp-content/uploads/2020/02/24203-paper.pdf tested similar things, b= ut the tails (9x% percentiles) looked better because it was a controller wi= red environment. Similarly, the datacenter using jumbo frames would not swe= at at all, but the issues arise at >90% percentile and affect folks in infr= astructures that are not as developed as in the western world. Also think a= bout congestion control and how that could impact infrastructures. These ar= e important challenges that McEliece would bring. =20 Also think of the loss probability. https://eprint.iacr.org/2019/1447 talks= about it. If you are sending 2-3 packets for a few KB public key or cipher= text then the total loss probability is 1-(1-p)^3 where p is the link loss = probability. Let's say p=3D1%, that becomes ~3% which is not too bad. Now w= ith 64KB and assuming 1400B packets, the probability becomes 1-(1-p)^45 whi= ch is ~36% with p=3D1%. 36% loss would slow down handshakes significantly, = especially UDP-based ones.=20 BSI may be endorsing the algorithm. It is indeed very mature and trusted. I= am sure many others would endorse it too. But it is impractical to say we = will standardize McEliece for the environments that can afford it and the r= est will pick something else. Migrating algorithms is painful and cumbersom= e as we have seen in hash and other algorithm migrations. Integrating two n= ew PQ KEMs depending on usecase is not straightforward. History has shown t= hat new algorithms that make sense get deployed in TLS, IKEv2, SSH etc.=20 Imo McEliece is not viable for the internet, unless there were significant = redesigns and no other options.=20 As a great cryptographer told me one time, if we are to use McEliece what i= s the point of all this work taking place to come up with better and more e= fficient PQ KEMs? Rgs, Panos=20 -----Original Message----- From: Daniel Herzinger =20 Sent: Tuesday, October 26, 2021 8:26 AM To: CJ Tjhai ; Kampanakis, Panos Cc: Valery Smyslov ; ipsec@ietf.org; ietf@gazdag.de Subject: [EXTERNAL] [UNVERIFIED SENDER] AW: [IPsec] Cost-efficient quantum-= resistant DoS protection Hi, the fact is that accepting a significantly increased amount of data from an= unauthenticated peer also significantly increases the surface to DoS attac= ks. Even without surpassing the 64KB limit, this must be a concern. IKEv2's= cookie mechanism and puzzles try to increase the cost of the attacker per = each connection. Now, an attacker must still accept these costs but can use= one connection to trigger several key exchanges, all significantly larger = than what we had with DH, making the trade-off way better for them compared= to non-pqc IKEv2. So, the attacker could, e.g., negotiate several FrodoKEM= s (all with different parameters to circumvent the rule that all key exchan= ge methods must be different). Compared to classical non-hybrid (EC)DH, suc= h a DoS attack requires significantly less cost to have the same effect. The introduction of MB-sized key exchanges just amplifies this problem even= further (also allowing several McEliece KEMs with different parameters cir= cumventing this constraint). Thus, while we should already thoroughly asses= and mitigate the risk of this possible weakness for https://datatracker.ie= tf.org/doc/draft-ietf-ipsecme-ikev2-multiple-ke/, we definitely must do it = for https://datatracker.ietf.org/doc/draft-tjhai-ikev2-beyond-64k-limit/. Currently, there is no place defined where a McEliece-sized key exchange ca= n take place. So, at least one of the two drafts (probably beyond-64k or mu= ltiple-ke) or better both should make this clear. At the moment, beyond-64k= defines how the transmission of such key exchanges could look like but the= question of where these ideas could be put into action are left to the rea= der, leading to inevitable confusion. The fact that there are several draft= s aiming at the same problem, without really defining their contact points = or interactions, further exacerbates this. The most obvious way to prevent an attacker from exploiting the new attack = surface is to accept the larger key exchanges only from an already authenti= cated peer. As mentioned before, we think childless IKEv2 with immediate re= keying would be a good compromise to achieve that. > Imo, McEliece is not practical for live protocols like TLS or IKEv2. McEliece is more trusted than its pqc alternatives which also makes it the = favored choice of some agencies like the German BSI. Obviously, they all kn= ow the challenges of integrating such large key exchanges, still they would= surely appreciate any effort which goes into this direction. This justifie= s pursuing the idea further, especially since first measurements look bette= r than one would probably expect. To give more insight about these measurements, we implemented all three dra= fts and tested the performance of a medium-sized McEliece key exchange unde= r different networking conditions (variable latency, packet loss, and throu= ghput). Especially when packet loss or throughput surpass specific threshho= lds (~ above 1% packet loss and below 3Mbit of throughput), the overall per= formance suffers significantly. Yet, we deem those values acceptable, as lo= ng as we don't use cellular or similarly unreliable networks. Furthermore, = we expect a gateway communicating with many peers to have higher requiremen= ts to its network uplink. Yet, as this will most likely be positioned in a = data center, this challenge should also be doable. Altogether, this left us= with a surprisingly positive view on the possibility of adopting McEliece-= sized key exchanges at least for some use-cases. The introduction of new Transform-IDs like SNTRUP761X25519 is a good short-= term solution, as it addresses the problem without requiring much effort in= terms of standardization or implementation. This becomes even more importa= nt, as intermediate exchanges and their high complexity, due to their inter= connectedness with authentication, mean that especially the IKEv2 implement= ations of smaller projects will take their time for its integration. Thus, = having an easier short-term solution at hand means a real advantage. Also, the constrained size of such transforms mostly eliminates the aforeme= ntioned DoS risks. Finally, should the beyond-64k draft be adopted, then having a small set of= such additional Tranform-IDs is even more beneficial since it makes preven= ting the unlikely yet possible attack described in our initial mail easier. Regards, Stefan and Daniel ________________________________________ Von: CJ Tjhai Gesendet: Donnerstag, 21. Oktober 2021 18:39:16 An: Kampanakis, Panos Cc: Valery Smyslov; Daniel Herzinger; ipsec@ietf.org; ietf@gazdag.de Betreff: Re: [IPsec] Cost-efficient quantum-resistant DoS protection Hi Panos, There are two drafts involved here. a) the main draft, https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev= 2-multiple-ke/, cannot support any public-key larger than 64KB, so it can n= ever be used for KEMs like McEliece. So the option 3 is implied here. b) on the other hand, https://datatracker.ietf.org/doc/draft-tjhai-ikev2-be= yond-64k-limit/ is an attempt to address the issue with transferring payloa= d larger than 64KB. As you pointed out, transferring large blob of data in = a live protocol is challenging and therefore it deservers separate treatmen= ts and considerations. It was deliberate that we split the hybrid key excha= nge drafts into two, the second draft is there just in case there is any in= terest in the working group on supporting the use KEMs like McEliece. Cheers, CJ On Thu, 21 Oct 2021 at 16:49, Kampanakis, Panos > wrote: Hi Valery, Tero, > Not really. First, the situation with seven McEliece is not possible, sin= ce all negotiated Key Exchange methods MUST be different. Then, you seem to assume that the responder blindly accepts all the key exc= hanges at the initiator's will. This is not true. First peers negotiate which key exchanges they will perfo= rm (including additional key exchanges), and you can limit the types and th= e number additional key exchanges the responder will accept via its local p= olicy. I think the point is valid though if the responder supports McEliece. A mis= creant can that way make the responder put a lot of data on the wire like a= n amplification attack although the initiator has not been validated. QUIC = has a 3x amplification protection limits for that matter. Sure, the issue existed even in ECDH exchanges, but the impact is much high= er when we talk MB of public keys. Imo, McEliece is not practical for live protocols like TLS or IKEv2. Too ma= ny packets mean pretty high loss probability in unstable networks which mea= ns pretty bad performance unless everything happens in the datacenter or ro= bust end-to-end network paths. The PQ KEMs that will end up being standardi= zed are likely to have just a few KBs of public key and ciphertext which is= better for the general case. So, I would say option 3 (prohibit the use of very large KE payloads like M= cEliece's MB sized public keys) is more practical. Rgs, Panos -----Original Message----- From: IPsec > On Beha= lf Of Valery Smyslov Sent: Tuesday, October 19, 2021 11:46 AM To: 'Daniel Herzinger' >; ipsec@ietf.org Cc: ietf@gazdag.de Subject: RE: [EXTERNAL] [IPsec] Cost-efficient quantum-resistant DoS protec= tion CAUTION: This email originated from outside of the organization. Do not cli= ck links or open attachments unless you can confirm the sender and know the= content is safe. Hi Daniel and Stefan-Lukas, > Hi, > > in response to the new version of > draft-ietf-ipsecme-ikev2-multiple-ke-04.txt, we wanted to emphasize > the issue of DoS attacks during intermediate exchanges. The new > version does address it by mentioning the option of simply avoiding > intermediate exchanges altogether but still require additional key > exchanges. Yet, this protects only against record-and-harvest attacks > but not against an attacker with a strong quantum computer at the time > of the handshake, regardless of quantum-resistant authentication > (since they can break the initial shared secret and therefore > recalculate the MAC which authenticates the followup exchanges, fully > establishing a man-in-the-middle). We doubt that an attacker, even with a= strong quantum computer, is able to break a key exchange in such a short t= ime period. Still, this assumption is too theoretical to rely on. This, tog= ether with the fact that Group-IKE is incompatible with key exchanges durin= g followup exchanges, makes the option seem inferior to just sticking to in= termediate exchanges during the handshake. However, we must also consider t= he draft-tjhai-ikev2-beyond-64k-limit-01.txt. > An attacker who exploits the large key exchanges, e.g., by requesting > seven additional maximum size McEliece key exchanges, can force a gateway= to accept and process 1.4MB of data per McEliece KEM. Not really. First, the situation with seven McEliece is not possible, since= all negotiated Key Exchange methods MUST be different. Then, you seem to assume that the responder blindly accepts all the key exc= hanges at the initiator's will. This is not true. First peers negotiate which key exchanges they will perfo= rm (including additional key exchanges), and you can limit the types and th= e number additional key exchanges the responder will accept via its local p= olicy. > This leaves us at > a situation where we must pick one of the following options: > > 1. Accept the highly increased risk of DoS attacks. > 2. Prohibit the use of large KE payloads, hence the McEliece mechanism. > 3. Prohibit the use of intermediate exchanges, leaving the IKE SA > initially unprotected and being vulnerable to an attacker with a quantum = computer during the handshake. > > To us, none of these options seems desirable. Thus, we propose another > solution which sees one new transform type, e.g., SNTRUP761X25519, > which then defines a combination of one classical algorithm (like I'm confused here - did you mean new transform type or new transform ID? Transform types define a kind of algorithms (or other features, like ESN), = while transform IDs define a particular algorithm of this type. Unless I'm missing something I presume you meant new transform ID which def= ines a new key exchange algorithm which is a combination of SNTRUP761 and X= 25519. Correct me if I'm wrong. > ECDH based on curve25519) and one pqc algorithm which fits into > IKE_SA_INIT without fragmentation (like sntruprime761). The two > secrets get concatinated and then fed to a hash function. The > resulting hash is used as the shared secret for further key > derivation. This mechanism is low effort in terms of implementation > and does not affect the state machine at all, but already offers a > high level of protection against all attacks as long as there is no major= break-through in cryptanalysis. Furthermore, it is the accepted approach f= or most of the applications of post-quantum key exchanges. For higher long-= term security, it can be combined with other, more conventional algorithms = which follow either in intermediate or followup exchanges. I think that this combined key exchange algorithm can also be implemented (= with more flexibility) by doing IKE_SA_INIT(X25519)+IKE_INTERMEDIATE(SNTRUP= 761). I don't think your approach has real advantages in terms of consuming= responder's resources. The responder still needs to perform both X25519 an= d SNTRUP761 before it authenticates the initiator. Yes, you save one round trip, but the amount of data sent on the wire and t= he amount of CPU cycles are roughly the same. I'd like also mention that wh= ile X25519 and SNTRUP761 public keys are fit into a single 1500 bytes IKE m= essage, they leave relatively little space for SA payload, so initiator may= be limited in expressing its proposals. > We then propose to restrict the use of large key exchanges to the > context of option 3, which removes the risk of the described DoS > attacks. Yet, to prevent the insecurities of plain option 3, we also prop= ose to make it mandatory to combine it with the new hybrid transform type, = i.e., SNTRUP761X25519. Are you proposing to stick with these two particular algorithms? I don't think it's a good idea, giving the algorithm agility requirements. I think that the same result can be achieved with the current draft: IKE_SA_INIT(X25519 or whatever else) IKE_INTERMEDIATE(SNTRUP761 or whatever else with small public key) IKE_AUTH= (Childless if you want) CREATE_CHILD_SA+IKE_FOLLOWUP_KE(McEliece or whateve= r else with long public key) This leaves much more flexibility in selecting particular algorithms. > The only downside of this approach is that G-IKE is then incompatible > with the McEliece exchange. However, the fact that G-IKE exchanges > sensitive information before authentication makes it impossible to be > not vulnerable against the discussed DoS attack and, at the same time, su= pport the McEliece algorithm. Thus, we see that as a decision to be made in= the G-IKE standardization track, not in IKEv2. I agree that G-IKEv2 is very special, but I also agree with Tero's previous= message that protecting IKEv2 and (G-IKEv2 too) against DoS attacks leaves= in slightly different area. We have some mechanisms for this (not perfect, but that is that). Regards, Valery. > Regards, > > Stefan-Lukas Gazdag, Daniel Herzinger _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ________________________________ PQ Solutions Limited (trading as 'Post-Quantum') is a private limited compa= ny incorporated in England and Wales with registered number 06808505. This email is meant only for the intended recipient. If you have received t= his email in error, any review, use, dissemination, distribution, or copyin= g of this email is strictly prohibited. Please notify us immediately of the= error by return email and please delete this message from your system. Tha= nk you in advance for your cooperation. For more information about Post-Quantum, please visit www.post-quantum.com<= http://www.post-quantum.com>. In the course of our business relationship, we may collect, store and trans= fer information about you. Please see our privacy notice at www.post-quantu= m.com/privacy-notice to learn a= bout how we use this information. From nobody Wed Oct 27 00:08:20 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C803A0BC2; Wed, 27 Oct 2021 00:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id anvz2R-o-3sU; Wed, 27 Oct 2021 00:08:14 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D24203A0BC0; Wed, 27 Oct 2021 00:08:13 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id l13so4104070lfg.6; Wed, 27 Oct 2021 00:08:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=I1Crbjg/zk98XGTpL0kQP4PBp2cHOKH2jCXS8IdIkyk=; b=M4n6ncIjdOtUBL/bdrtpcubzsMFeJzlOUL395h27B2wYmnX82Eoj1mxIITwu9u5vbk Vyi4K3m5cYb2etcTT6wVOGCk6nQbzpeQ2yP5JRiSdarVHZaEDm0Uj4EXyDbMQQRec3oA JgmadCH0qbEjzM3dyCuHHIn+KWgS9IFdvtdxlcRPAkIfx1UEIs4mOvTUuH4QdTrstF/B Nn4kSd0LJaLMXbt/sUTZUn+61xAb2ogHoQKZRbsnYum0FzT2XY8PWPGExZeeACnAonOg qpidzVs/bWyXjdA5i57+lxeH29ou5THf5HsXkjz2K4cYpUR1YuAzOm+kbEj5DkR67klb pjXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:content-language :thread-index; bh=I1Crbjg/zk98XGTpL0kQP4PBp2cHOKH2jCXS8IdIkyk=; b=DuCYKx4Dl66qc1Ew/kaC7+3ytPqe8NwWmP4AnnahoKHY03vtOm9CjcUan+bjsrdhGj 3eJQAIdMPyR3YjTNBn7Kqy4MWT3tvrGWt6TuXWMuOGrZfxSgUxw3dIkeB9fKK31cChIe 7r+biIoZXKHS3K0iiMNZQDPCCJ/jk0CxaT97CfHx24FSgwcJv6avmxBaEDcBeV83vRhs Y91VfdPu4oSWquq1s3VeQ4rjCn5Vo1YVq0usYCD1Y72buRHT4K6ZdWrhQELe3l1JqnBy slZmjn+YUGg8ZVPpL8k2nXzctg8EJpcXzIy+QzHUuEgRQobJa6U9Xab6FA6tD4vz4Hd0 cgmg== X-Gm-Message-State: AOAM533+Fy2n5TWMVqOfRIEJS6r5AZHv/RUWEmgDhznlgo7NLRwkeLGn 6otPG/10M/xIMLQWY12gXDNsoKHM0E4= X-Google-Smtp-Source: ABdhPJxPRPDfE5RT6/+TaehuLh1dfcyZGNDFi8kJfFJkQ3ltTBXzL9xCbTz20P1loE3dq4RxeCeclg== X-Received: by 2002:a05:6512:1294:: with SMTP id u20mr26887934lfs.218.1635318490987; Wed, 27 Oct 2021 00:08:10 -0700 (PDT) Received: from buildpc ([93.188.44.204]) by smtp.gmail.com with ESMTPSA id g10sm2145213lfu.103.2021.10.27.00.08.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Oct 2021 00:08:10 -0700 (PDT) From: "Valery Smyslov" To: Cc: "'Tommy Pauly'" , References: <163518594088.29638.3891670131687133802@ietfa.amsl.com> In-Reply-To: <163518594088.29638.3891670131687133802@ietfa.amsl.com> Date: Wed, 27 Oct 2021 10:08:11 +0300 Message-ID: <03a501d7cb01$6795df00$36c19d00$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: ru Thread-Index: AQFT6l9BbF3RGzOtPI4NalxgbPChSqzuLSQQ Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc8229bis-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2021 07:08:19 -0000 Hi, the new version of the draft contains virtually no changes (one typo fixed). We believe the document is ready for WGLC. Regards, Tommy & Valery. > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. > > Title : TCP Encapsulation of IKE and IPsec Packets > Authors : Valery Smyslov > Tommy Pauly > Filename : draft-ietf-ipsecme-rfc8229bis-01.txt > Pages : 30 > Date : 2021-10-25 > > Abstract: > This document describes a method to transport Internet Key Exchange > Protocol (IKE) and IPsec packets over a TCP connection for traversing > network middleboxes that may block IKE negotiation over UDP. This > method, referred to as "TCP encapsulation", involves sending both IKE > packets for Security Association establishment and Encapsulating > Security Payload (ESP) packets over a TCP connection. This method is > intended to be used as a fallback option when IKE cannot be > negotiated over UDP. > > TCP encapsulation for IKE and IPsec was defined in [RFC8229]. This > document updates specification for TCP encapsulation by including > additional clarifications obtained during implementation and > deployment of this method. This documents makes RFC8229 obsolete. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc8229bis/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-rfc8229bis-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc8229bis-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Oct 28 08:24:45 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4AD3A0A1A for ; Thu, 28 Oct 2021 08:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.618 X-Spam-Level: X-Spam-Status: No, score=-9.618 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=m8tMK354; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=nEncvF1A Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdzLRAn14sSi for ; Thu, 28 Oct 2021 08:24:39 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AEC43A09FE for ; Thu, 28 Oct 2021 08:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20126; q=dns/txt; s=iport; t=1635434679; x=1636644279; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KQn7I3Wg/AApt6yXRRrlZy+VlrQIkP9vK0Xdi3B1Fwg=; b=m8tMK354lJWHiZoPBu+XW/ex3RuEvb0EaTpiGjaDtebk0ho392bVvGwj nF1N5HSfjZ/F5tHNnMAa2vS0+orjoAfWo41m7nLqufqVi3yaO+wB4NDc1 iMR+rfQtj1qRYMS1z30Noj8R8eI/jTIudMnyPzyBo7C6XpZDEvgrl2A1k U=; IronPort-PHdr: =?us-ascii?q?A9a23=3AKuvhhhXqqQMGGyM3aRbQVOtRVAPV8K0aAWYlg?= =?us-ascii?q?6HPw5pCd6259NLjMVDRo/J3gwyBUYba7qdCjOzb++DlVHcb6JmM+HYFbNRXV?= =?us-ascii?q?hADhMlX+m5oAMOMBUDhavK/aSs8EZdOUVZ/9De6PFRbXsHkaA6arni79zVHH?= =?us-ascii?q?BL5OEJ8Lfj0HYiHicOx2qiy9pTfbh8OiiC6ZOZ5LQ69qkPascxF6bY=3D?= IronPort-Data: =?us-ascii?q?A9a23=3A35stjK7kNpT9E/N7QMXjjwxRtMPFchMFZxGqf?= =?us-ascii?q?qrLsTDasY5as4F+vmoWWj3VbvvbamP1e4h+adm38k8G7MPcyNVmS1dpqS9nZ?= =?us-ascii?q?n8b8sCt6fZ1gavT04J+FiBIJa5ex512huLocYZkERcwmj/3auK49CEmhfnSL?= =?us-ascii?q?lbBILes1h5ZFFcMpBgJ0XqPq8Zh6mJZqYDR7zGl4LsekOWHULOR4AOYB0pPg?= =?us-ascii?q?061RLyDi9yp0N8QlgRWifmmJzYynVFNZH4UDfnZw3cV3uBp8uCGq+brlNlV/?= =?us-ascii?q?0vD9BsrT9iiiLu+LgsBQ6XZOk6FjX8+t6qK20cZ4HdtlPdgcqNBNC+7iB3R9?= =?us-ascii?q?zx14M5DsYGwUwozFqbNg+8aFRJfFkmSOIUYqOOccSnn4Z37I0ruNiGEL+9VJ?= =?us-ascii?q?EA7IYMw9e9lDWhBs/AVQBgWawGYg+WohrO2VudEicEqLc2tN4Qa0llh1SrUB?= =?us-ascii?q?t4nTIzNBaLQ6rdw0D42h81KKvbTfdgYbzVidjzPbhtSMxEbBfoWn/+hgH7kJ?= =?us-ascii?q?mEAoVect60xpWPUySR91bH3O5zUd8CEA8JPkS6lSsjul4jiKgsRONrawj2f/?= =?us-ascii?q?zfwwOTOhij8HokVEdWFGjdRqAX77gQu5Nc+DzNXecWEt3M=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3ARs3nC6i3E11st8wp+YNL9I2G9XBQX3h13D?= =?us-ascii?q?Abv31ZSRFFG/FwyPrOoB1L73HJYWgqN03IwerwR5VpQRvnhPlICPoqTMmftW?= =?us-ascii?q?7dySqVxeBZnMXfKljbexEWmdQtrpuIH5IObeEYSGIK8foSgzPIU+rIouP3ip?= =?us-ascii?q?xA7N22pxwGIG0aCNAD0+46MHfnLqQcfnghOXNNLuvl2iMxnUvYRZ14VLXeOl?= =?us-ascii?q?A1G8z44/HbnpPvZhALQzQ97hOVsD+u4LnmVzCFwxY3SVp0sPQf2FmAtza8yr?= =?us-ascii?q?Sosvm9xBOZ/XTU9Y5qlNzozcYGLNCQi/ISNi7nhm+TFcZcsvy5zXUISdOUmR?= =?us-ascii?q?EXeer30lEd1gNImirsl1SO0F/QMs/boW4TAjHZuASlaDDY0L3ErXoBerp8bM?= =?us-ascii?q?RiA0HkA45KhqAh7EqNtFjp6qa/RCmw7xjV9pzGUQpnmVGzpmdnmekPj2ZHWY?= =?us-ascii?q?9bc7NJq5cDlXklXavoMRiKo7zPKtMeRv00JcwmBm+yfjTcpC1i0dasVnM8El?= =?us-ascii?q?OPRVUDoNWc13xTkGpix0UVycQDljNYnahNBKVs9qDBKOBlhbtORsgZYeZ0A/?= =?us-ascii?q?oAW9K+DijITQjXOGyfLFz7HOUMOm7LqZTw/LIpjdvaNKAg3d83gtDMQVlYvW?= =?us-ascii?q?k9dwbnDtCPxoRC9lTXTGC0TV3Wu4ljDlhCy/TBrZbQQFi+oWEV4r2dSq8kc7?= =?us-ascii?q?/mst6ISeZrP8M=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASCgC3v3ph/5tdJa1aHgEBCxIMQIM?= =?us-ascii?q?rKSgHd1oTJDECiAwDhTmIDQOBE4lihSGHZCiCU4FCgREDVAsBAQENAQEqDQo?= =?us-ascii?q?EAQGFAAKCUgIlOBMBAgQBAQESAQEFAQEBAgEGBIERE4VoDYZCAQEBAQEBAQE?= =?us-ascii?q?BECgGAQEHJQICBwEEBwQCAQgRBAEBHwkHIQYLFAkIAQEEAQkEBQgTB4JQOII?= =?us-ascii?q?dAw4hAQ6hDQGBOgKJajV4gTOBAYIIAQEGBASBNgETPgIBgn8NC4I1CYE6gwa?= =?us-ascii?q?HEIFTgTJ5AiccgUlEJm4BQ4FmSjc+ggAhQgEBAQEBgR4KAQsBBQIBIgoaBoM?= =?us-ascii?q?jgi6NMwkBEA5NByIIEyMHFBsBEw8BCQsMAg0gAQcBAxULCAIMBwUXDwIICQE?= =?us-ascii?q?HDhcCAQQJDA0HCAIRAhgPkTsoBwGCbahwaAqDMopLjUZ+glWDMhWDa0KLL5d?= =?us-ascii?q?IlgwfiQyDR4NGhEOLUisPAwwEhGMCBAIEBQIOAQEGgXgkKz5wcBU7gmkJSBk?= =?us-ascii?q?Pi0iCWAkCARaBBAEBAYJJhRSFSnQCEiQCBgsBAQMJkCkBASYHghcBAQ?= X-IronPort-AV: E=Sophos;i="5.87,190,1631577600"; d="scan'208";a="684389089" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Oct 2021 15:24:37 +0000 Received: from mail.cisco.com (xbe-rcd-003.cisco.com [173.37.102.18]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 19SFOaHk015852 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Thu, 28 Oct 2021 15:24:37 GMT Received: from xfe-aln-005.cisco.com (173.37.135.125) by xbe-rcd-003.cisco.com (173.37.102.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 28 Oct 2021 10:24:36 -0500 Received: from xfe-aln-001.cisco.com (173.37.135.121) by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 28 Oct 2021 10:24:36 -0500 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-001.cisco.com (173.37.135.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Thu, 28 Oct 2021 10:24:35 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JMWYoGwVTLfYZBt5cvYQZb3dW/xFmyTz29+6XLSxYA67UbZkBRcszNGbsb72bzmnNPj9tg/uppjZcFSDJxhwEXnOhen6IU5/xweSNa4D3/ANVVTuCWVBmX+mVPnh3ngvCrTxfDLY4gThpQInlOOiuwsddxrqT6Oxk2+qSDHapbPyTG0rqsGt7K5qFk9evmqkP8xGAStZ2jstZxRnzb/GrLPNJsWgpDRNhxnGaKdNQM4TDWIK7H1aUGjVnsMEE4kK2M8vrWw25y9hPDVOBBlkE/KjAYmsTSwyiemu0YrAcgYwexyje94qyj81ATNSjkpCJqb6QIKPThJOs0bBCKN1vA== 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=jX4hdoWyOWmkct2jYFbu6ClwdssdgwyWRsNz1/YWFw8=; b=MCVpzTt06Em/1SQ0OmmQAqQj5bBCbCMHs5t35Be5q/8WnnhKwm3UdXnYFvU583ecvvz5EQL5Q4sjy5MhG+NBWjQpjzu3NiPTq4EgnDG4LKp31G/iqLE8etumQaUuUz872MLYGUjFkZSursZ1Rln6irLM65hbTLYpr2aj3/hP5XLmG/nBYUwLULddqUV2GbiVnsNdHB0EBcxYL2j/Xgata/yUQjqXUeeitqOo0Y13fOB8ee4oq5gNb/EXM9FtXXCs5MlqaY1DoqdtIR6SdFPiYLGRjJ74obX6FpmceGaEsyEjsQN042po7rc6t57p41Urx+iXMZpiOTxGmruVTi4Etw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jX4hdoWyOWmkct2jYFbu6ClwdssdgwyWRsNz1/YWFw8=; b=nEncvF1Aae9tn+L3NkJI+QFC8mtpqXxKoDv8GUG6dXNEy0E3Mxwg7hWFJGdKRExeKT+t4xZe24dD5WYQY4fldhtg9sRkO502J6jSymd9qnZR+O5HoJOpHymrkZEqoGgb0VaYacTSNBHvGCfy0UceR/j4IgWNyfRiL2Pn6p2UB58= Received: from BL3PR11MB5682.namprd11.prod.outlook.com (2603:10b6:208:33d::18) by MN2PR11MB4519.namprd11.prod.outlook.com (2603:10b6:208:26c::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4649.15; Thu, 28 Oct 2021 15:24:34 +0000 Received: from BL3PR11MB5682.namprd11.prod.outlook.com ([fe80::7967:f6c7:1632:1549]) by BL3PR11MB5682.namprd11.prod.outlook.com ([fe80::7967:f6c7:1632:1549%7]) with mapi id 15.20.4649.015; Thu, 28 Oct 2021 15:24:34 +0000 From: "Scott Fluhrer (sfluhrer)" To: "Kampanakis, Panos" , Daniel Herzinger CC: "ipsec@ietf.org" , Valery Smyslov , "ietf@gazdag.de" Thread-Topic: [IPsec] Cost-efficient quantum-resistant DoS protection Thread-Index: AdfKgoM4fQq+bJnCT1uQuTijcBSWRwBjM5bg Date: Thu, 28 Oct 2021 15:24:34 +0000 Message-ID: References: <70b270f5ed3842f28f18dbe1488399e7@EX13D01ANC003.ant.amazon.com> In-Reply-To: <70b270f5ed3842f28f18dbe1488399e7@EX13D01ANC003.ant.amazon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 16889d5d-c715-4138-bf49-08d99a270c05 x-ms-traffictypediagnostic: MN2PR11MB4519: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: GTdrwJYaQwjqes9zqKyUbT3o8P04flY0GINnwwaCx82y95ks5zbm8P/LdqP6NepQ1hjNqhLJ1Kwz5ivpvW1ezvFlVxcYouKibG5OO1tYDDDr417DTo2MiCIuqhr+0YDlQ0adYHFqJafpQ+1oBjg3FlgS4jcAAdzLki24u6N4qa0QdbFJaClayKDwTSBVUVbng7L2gINlVf2nbPdXnX+i2I9+sLAXIV/xnU17JATeQi34jw8EBNewGae0c1qx9rSZQ3K6aBzdf1wWXMVzsZP61NmALm9MByeGsq5YZNmu96XxDFpBj3+Xyucmvs8mpEZj1SgJpbJxUQLHQSeCD0Z5+D1x0D1FU4pv0oEQmMjV9sb3XAsXPiB3wSDafBNWj3+qrpsgtYtC5bbi7uj2Op4Cw4x+YCq3goYE6ryf2pPuRr/EDaq3pnZ8GcPb2S8AYa/I9II60Cah3pTkKeTZIwW57gBnWfWd/AZLnBXQeahjuRYs9MLiUTw84bjd4XDZmngop3FrkYs8P3GtXWucQ7eFln7LJQQ9SH877IjJzuL1xycegSlkzEXMeHPfCJKWG/OgxBa2rww0a3+XjziYL8pLU3AjbGusJgleNHnsQs+oTF9Dj5ftacnhF7Oo3MKSihAuG4B7QrOoPXtBTZtmM9wR9Kbk3oPE34RSqB8SGgCmP6SygZl/m677pgdjlVXQ0mV2uKzO/4B32dBgV16nAxpHw+OLf43yTLxWObdlRxGTBihnNQmM8vVz7xCFl4IiyW2HxR5/EOkWWm5NyuEOMh4GhER0KbxCqv8U2h0TRikBhRogW6XjO3d44yq+D6dIzzABQpzacU/A/zXUIV15tMvy0CuV4cNEZF6ZdCL4Ew6d45A= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL3PR11MB5682.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(66476007)(66556008)(64756008)(26005)(53546011)(66446008)(33656002)(8676002)(83380400001)(6506007)(966005)(8936002)(110136005)(5660300002)(54906003)(38100700002)(30864003)(66946007)(38070700005)(122000001)(52536014)(7696005)(316002)(9686003)(86362001)(66574015)(508600001)(15974865002)(2906002)(71200400001)(4326008)(55016002)(76116006)(186003)(15398625002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?LiawFS8g5I9SQ/trzH+mMM5RlQZ4Zpb1/siMYUe56Rg/0RdaB6MZJPaPfrun?= =?us-ascii?Q?gy01cXvYF/kzfaRqJuqa1PJbtjoUYJApL6eC5dP1qjD1BHszCTCQmrZoKk6U?= =?us-ascii?Q?aqeP62mru5j96X9Qu95YahuMsFFvkqVL0P6tgbSXdEX4859SX7xzOTohB7OI?= =?us-ascii?Q?pr88VGpO20q5ezyHIBrezKo+qqjzvvzAirhDVDnggnMERb/AT6cevzI4cR0x?= =?us-ascii?Q?Utf5Nm1toP0LkrKqIQkRZl8yc108Ze6cc7kgICSAWGCRriaVE1M7P6pggwAb?= =?us-ascii?Q?M4qIgcnk61fUHOgWIVLNz96kB32KIwxKEUBjCN67hUsn+2wjMcbn+CAYpsHO?= =?us-ascii?Q?W9b0xFUTUHVBi0N8hDoeQ/0+fsCzliMtJZc8d012TAiE0hJ8/e1+pcyc7+Pd?= =?us-ascii?Q?DnL3BmlELwr4htPuB2R4PIewXYV+pUIZj4RAIU0n/uT7vxHTCT+XVwte9acy?= =?us-ascii?Q?0INowJXrT75p34oF6GPkrzgcEM/u0xLAJRuQNM/355SBXPL9vMZB6yWtNOg8?= =?us-ascii?Q?tHtKJFss05rqhr4e2e0nVsuwNBPrm82Rj0wpMhCssiS2QmL1xCmwtpEKywn8?= =?us-ascii?Q?nsl/4p7X5YrylIigNlw1AhjY+uo54eNirEUb8+HXvS5yvMjUWXr8JRVQ8YtK?= =?us-ascii?Q?0c7407SaZ5f+lXqCBpabjchK56i+lSQQFJyQ4+sFJQ7WXQUk3q5NhfCgyGyj?= =?us-ascii?Q?Nv29Oc2PdQCVN6cLpYMZwHSwfWxwFGtMgIRwRMehRlTKkqWRh6eO9bWcd/O6?= =?us-ascii?Q?LM06sj6jZB6AsrodnlP5PGrcwnwInPVvtzYkyTkIlZ+a+4spIHAqkECRn1GP?= =?us-ascii?Q?QAYq9bTtwfqb77HREy9hXgXeOeJcBlY91Ob+tiz/sPMKya9SYmupuYeN39iw?= =?us-ascii?Q?OX+Vd0XNzpm/kEaqbuWD3cwTShMa7noU4zf782x05Dt3ZYCJYDxFWN3ycsox?= =?us-ascii?Q?U8UWcBtZ8+wxYYqvmMTfe9ERl6hIspuLehlnZtBRS39K57qDH+YPgO+5IspZ?= =?us-ascii?Q?HQ39eCsNMoWGePwUeNykx8NAfOVPL6el1I/OoulNXAX0VYgOnhznhdgilVr0?= =?us-ascii?Q?Po0JHkE7HYtJPdESLwN2AFNltApNv3dXs8OpJr6qS5zbzAzHEev5Zn06Aevv?= =?us-ascii?Q?7FTZ8ovVGXQncApDvJIUkNiKtQNfMX5Vl69V2WyymNRKzlQzpEbVAMofJc0J?= =?us-ascii?Q?vuBAF05gkP9NMWUmkMbYkREwiPiHLNbYM3/VQ2ma9F0u2RW7EjHaPM6wkW3T?= =?us-ascii?Q?vWF5QMyT+Mhpi7jtEaBG0Y8JGD/sm0z2kIZtC28bMc7YpsQxkScmpLBzEm5r?= =?us-ascii?Q?dGhpq08UsSI5ghUodHbxAT/XOHP3DQ+f6Vdi9GNXkLHH64J0mQvr+5CEMiyD?= =?us-ascii?Q?n3Mh/KdNHGCpUfI9T3qHbB3u8iTBBkXSSoxndwZBAfmeQEdhaByMC+I1r4hI?= =?us-ascii?Q?gHkPOJrnmjvJSWCKP4CYpwAkMYAY3xF5EIXOuzihCMN1r0kZZ1QSTu6+ZYPN?= =?us-ascii?Q?CZ1UJz3eupRMcuP427HsNnNOrGHyQcLgDxx3UtLevVwksp78hNMneQlNvzOd?= =?us-ascii?Q?C/ewvPamWEXSPtbOarV931NzNH28x/5q8yoof1I1EpiLJNcykYc960l8uRiU?= =?us-ascii?Q?6w=3D=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL3PR11MB5682.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 16889d5d-c715-4138-bf49-08d99a270c05 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Oct 2021 15:24:34.4874 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: uigvPgywFPXUtOHaDPCMFOm2a2eSKYinMpPcXDWAdVteOvAOrvsW00d/rRfBaSw+3uTW2kaueIVgIPFKUH57dg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4519 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.18, xbe-rcd-003.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [IPsec] Cost-efficient quantum-resistant DoS protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2021 15:24:44 -0000 Sorry if I ask such an obvious question, but would McEliece perform better = against packet loss if we introduce a more intelligent ack/retry method? F= or each, the ack would list which segments of the packet have been received= (e.g. bytes 0-3240 and bytes 6780-9800), so that on a retransmit, we only = need to resend the segments that were dropped? And, of course, we'd resend= the ack multiple times, in case that is dropped. Of course, the complexity of all this wouldn't be warranted in the original= envisioned use cases of IKE fragmentation (where it was never expected tha= t there would be that many fragments) - given that the use case has changed= , would it make sense to revisit this? -----Original Message----- From: IPsec On Behalf Of Kampanakis, Panos Sent: Tuesday, October 26, 2021 1:37 PM To: Daniel Herzinger Cc: ipsec@ietf.org; Valery Smyslov ; ietf@gazdag.de Subject: Re: [IPsec] Cost-efficient quantum-resistant DoS protection Hi Daniel,=20 > To give more insight about these measurements, we implemented all three d= rafts and tested the performance of a medium-sized McEliece key exchange un= der different networking conditions (variable latency, packet loss, and thr= oughput). Especially when packet loss or throughput surpass specific thresh= holds (~ above 1% packet loss and below 3Mbit of throughput), the overall p= erformance suffers significantly. Yet, we deem those values acceptable, as = long as we don't use cellular or similarly unreliable networks. Furthermore= , we expect a gateway communicating with many peers to have higher requirem= ents to its network uplink. Yet, as this will most likely be positioned in = a data center, this challenge should also be doable. Altogether, this left = us with a surprisingly positive view on the possibility of adopting McEliec= e-sized key exchanges at least for some use-cases. > The introduction of new Transform-IDs like SNTRUP761X25519 is a good shor= t-term solution, as it addresses the problem without requiring much effort = in terms of standardization or implementation. Understood. I am curious to see the measurements published btw. Are the pub= lic somewhere?=20 A couple counter arguments:=20 Cloudflare's tests (https://blog.cloudflare.com/the-tls-post-quantum-experi= ment/ ) showed a bunch of variability for way more compact KEMs than McElie= ce (SIKE, NTRU-HRSS) at the 95% and 99% percentile. https://www.ndss-sympos= ium.org/wp-content/uploads/2020/02/24203-paper.pdf tested similar things, b= ut the tails (9x% percentiles) looked better because it was a controller wi= red environment. Similarly, the datacenter using jumbo frames would not swe= at at all, but the issues arise at >90% percentile and affect folks in infr= astructures that are not as developed as in the western world. Also think a= bout congestion control and how that could impact infrastructures. These ar= e important challenges that McEliece would bring. =20 Also think of the loss probability. https://eprint.iacr.org/2019/1447 talks= about it. If you are sending 2-3 packets for a few KB public key or cipher= text then the total loss probability is 1-(1-p)^3 where p is the link loss = probability. Let's say p=3D1%, that becomes ~3% which is not too bad. Now w= ith 64KB and assuming 1400B packets, the probability becomes 1-(1-p)^45 whi= ch is ~36% with p=3D1%. 36% loss would slow down handshakes significantly, = especially UDP-based ones.=20 BSI may be endorsing the algorithm. It is indeed very mature and trusted. I= am sure many others would endorse it too. But it is impractical to say we = will standardize McEliece for the environments that can afford it and the r= est will pick something else. Migrating algorithms is painful and cumbersom= e as we have seen in hash and other algorithm migrations. Integrating two n= ew PQ KEMs depending on usecase is not straightforward. History has shown t= hat new algorithms that make sense get deployed in TLS, IKEv2, SSH etc.=20 Imo McEliece is not viable for the internet, unless there were significant = redesigns and no other options.=20 As a great cryptographer told me one time, if we are to use McEliece what i= s the point of all this work taking place to come up with better and more e= fficient PQ KEMs? Rgs, Panos=20 -----Original Message----- From: Daniel Herzinger =20 Sent: Tuesday, October 26, 2021 8:26 AM To: CJ Tjhai ; Kampanakis, Panos Cc: Valery Smyslov ; ipsec@ietf.org; ietf@gazdag.de Subject: [EXTERNAL] [UNVERIFIED SENDER] AW: [IPsec] Cost-efficient quantum-= resistant DoS protection Hi, the fact is that accepting a significantly increased amount of data from an= unauthenticated peer also significantly increases the surface to DoS attac= ks. Even without surpassing the 64KB limit, this must be a concern. IKEv2's= cookie mechanism and puzzles try to increase the cost of the attacker per = each connection. Now, an attacker must still accept these costs but can use= one connection to trigger several key exchanges, all significantly larger = than what we had with DH, making the trade-off way better for them compared= to non-pqc IKEv2. So, the attacker could, e.g., negotiate several FrodoKEM= s (all with different parameters to circumvent the rule that all key exchan= ge methods must be different). Compared to classical non-hybrid (EC)DH, suc= h a DoS attack requires significantly less cost to have the same effect. The introduction of MB-sized key exchanges just amplifies this problem even= further (also allowing several McEliece KEMs with different parameters cir= cumventing this constraint). Thus, while we should already thoroughly asses= and mitigate the risk of this possible weakness for https://datatracker.ie= tf.org/doc/draft-ietf-ipsecme-ikev2-multiple-ke/, we definitely must do it = for https://datatracker.ietf.org/doc/draft-tjhai-ikev2-beyond-64k-limit/. Currently, there is no place defined where a McEliece-sized key exchange ca= n take place. So, at least one of the two drafts (probably beyond-64k or mu= ltiple-ke) or better both should make this clear. At the moment, beyond-64k= defines how the transmission of such key exchanges could look like but the= question of where these ideas could be put into action are left to the rea= der, leading to inevitable confusion. The fact that there are several draft= s aiming at the same problem, without really defining their contact points = or interactions, further exacerbates this. The most obvious way to prevent an attacker from exploiting the new attack = surface is to accept the larger key exchanges only from an already authenti= cated peer. As mentioned before, we think childless IKEv2 with immediate re= keying would be a good compromise to achieve that. > Imo, McEliece is not practical for live protocols like TLS or IKEv2. McEliece is more trusted than its pqc alternatives which also makes it the = favored choice of some agencies like the German BSI. Obviously, they all kn= ow the challenges of integrating such large key exchanges, still they would= surely appreciate any effort which goes into this direction. This justifie= s pursuing the idea further, especially since first measurements look bette= r than one would probably expect. To give more insight about these measurements, we implemented all three dra= fts and tested the performance of a medium-sized McEliece key exchange unde= r different networking conditions (variable latency, packet loss, and throu= ghput). Especially when packet loss or throughput surpass specific threshho= lds (~ above 1% packet loss and below 3Mbit of throughput), the overall per= formance suffers significantly. Yet, we deem those values acceptable, as lo= ng as we don't use cellular or similarly unreliable networks. Furthermore, = we expect a gateway communicating with many peers to have higher requiremen= ts to its network uplink. Yet, as this will most likely be positioned in a = data center, this challenge should also be doable. Altogether, this left us= with a surprisingly positive view on the possibility of adopting McEliece-= sized key exchanges at least for some use-cases. The introduction of new Transform-IDs like SNTRUP761X25519 is a good short-= term solution, as it addresses the problem without requiring much effort in= terms of standardization or implementation. This becomes even more importa= nt, as intermediate exchanges and their high complexity, due to their inter= connectedness with authentication, mean that especially the IKEv2 implement= ations of smaller projects will take their time for its integration. Thus, = having an easier short-term solution at hand means a real advantage. Also, the constrained size of such transforms mostly eliminates the aforeme= ntioned DoS risks. Finally, should the beyond-64k draft be adopted, then having a small set of= such additional Tranform-IDs is even more beneficial since it makes preven= ting the unlikely yet possible attack described in our initial mail easier. Regards, Stefan and Daniel ________________________________________ Von: CJ Tjhai Gesendet: Donnerstag, 21. Oktober 2021 18:39:16 An: Kampanakis, Panos Cc: Valery Smyslov; Daniel Herzinger; ipsec@ietf.org; ietf@gazdag.de Betreff: Re: [IPsec] Cost-efficient quantum-resistant DoS protection Hi Panos, There are two drafts involved here. a) the main draft, https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev= 2-multiple-ke/, cannot support any public-key larger than 64KB, so it can n= ever be used for KEMs like McEliece. So the option 3 is implied here. b) on the other hand, https://datatracker.ietf.org/doc/draft-tjhai-ikev2-be= yond-64k-limit/ is an attempt to address the issue with transferring payloa= d larger than 64KB. As you pointed out, transferring large blob of data in = a live protocol is challenging and therefore it deservers separate treatmen= ts and considerations. It was deliberate that we split the hybrid key excha= nge drafts into two, the second draft is there just in case there is any in= terest in the working group on supporting the use KEMs like McEliece. Cheers, CJ On Thu, 21 Oct 2021 at 16:49, Kampanakis, Panos > wrote: Hi Valery, Tero, > Not really. First, the situation with seven McEliece is not possible, sin= ce all negotiated Key Exchange methods MUST be different. Then, you seem to assume that the responder blindly accepts all the key exc= hanges at the initiator's will. This is not true. First peers negotiate which key exchanges they will perfo= rm (including additional key exchanges), and you can limit the types and th= e number additional key exchanges the responder will accept via its local p= olicy. I think the point is valid though if the responder supports McEliece. A mis= creant can that way make the responder put a lot of data on the wire like a= n amplification attack although the initiator has not been validated. QUIC = has a 3x amplification protection limits for that matter. Sure, the issue existed even in ECDH exchanges, but the impact is much high= er when we talk MB of public keys. Imo, McEliece is not practical for live protocols like TLS or IKEv2. Too ma= ny packets mean pretty high loss probability in unstable networks which mea= ns pretty bad performance unless everything happens in the datacenter or ro= bust end-to-end network paths. The PQ KEMs that will end up being standardi= zed are likely to have just a few KBs of public key and ciphertext which is= better for the general case. So, I would say option 3 (prohibit the use of very large KE payloads like M= cEliece's MB sized public keys) is more practical. Rgs, Panos -----Original Message----- From: IPsec > On Beha= lf Of Valery Smyslov Sent: Tuesday, October 19, 2021 11:46 AM To: 'Daniel Herzinger' >; ipsec@ietf.org Cc: ietf@gazdag.de Subject: RE: [EXTERNAL] [IPsec] Cost-efficient quantum-resistant DoS protec= tion CAUTION: This email originated from outside of the organization. Do not cli= ck links or open attachments unless you can confirm the sender and know the= content is safe. Hi Daniel and Stefan-Lukas, > Hi, > > in response to the new version of > draft-ietf-ipsecme-ikev2-multiple-ke-04.txt, we wanted to emphasize > the issue of DoS attacks during intermediate exchanges. The new > version does address it by mentioning the option of simply avoiding > intermediate exchanges altogether but still require additional key > exchanges. Yet, this protects only against record-and-harvest attacks > but not against an attacker with a strong quantum computer at the time > of the handshake, regardless of quantum-resistant authentication > (since they can break the initial shared secret and therefore > recalculate the MAC which authenticates the followup exchanges, fully > establishing a man-in-the-middle). We doubt that an attacker, even with a= strong quantum computer, is able to break a key exchange in such a short t= ime period. Still, this assumption is too theoretical to rely on. This, tog= ether with the fact that Group-IKE is incompatible with key exchanges durin= g followup exchanges, makes the option seem inferior to just sticking to in= termediate exchanges during the handshake. However, we must also consider t= he draft-tjhai-ikev2-beyond-64k-limit-01.txt. > An attacker who exploits the large key exchanges, e.g., by requesting > seven additional maximum size McEliece key exchanges, can force a gateway= to accept and process 1.4MB of data per McEliece KEM. Not really. First, the situation with seven McEliece is not possible, since= all negotiated Key Exchange methods MUST be different. Then, you seem to assume that the responder blindly accepts all the key exc= hanges at the initiator's will. This is not true. First peers negotiate which key exchanges they will perfo= rm (including additional key exchanges), and you can limit the types and th= e number additional key exchanges the responder will accept via its local p= olicy. > This leaves us at > a situation where we must pick one of the following options: > > 1. Accept the highly increased risk of DoS attacks. > 2. Prohibit the use of large KE payloads, hence the McEliece mechanism. > 3. Prohibit the use of intermediate exchanges, leaving the IKE SA > initially unprotected and being vulnerable to an attacker with a quantum = computer during the handshake. > > To us, none of these options seems desirable. Thus, we propose another > solution which sees one new transform type, e.g., SNTRUP761X25519, > which then defines a combination of one classical algorithm (like I'm confused here - did you mean new transform type or new transform ID? Transform types define a kind of algorithms (or other features, like ESN), = while transform IDs define a particular algorithm of this type. Unless I'm missing something I presume you meant new transform ID which def= ines a new key exchange algorithm which is a combination of SNTRUP761 and X= 25519. Correct me if I'm wrong. > ECDH based on curve25519) and one pqc algorithm which fits into > IKE_SA_INIT without fragmentation (like sntruprime761). The two > secrets get concatinated and then fed to a hash function. The > resulting hash is used as the shared secret for further key > derivation. This mechanism is low effort in terms of implementation > and does not affect the state machine at all, but already offers a > high level of protection against all attacks as long as there is no major= break-through in cryptanalysis. Furthermore, it is the accepted approach f= or most of the applications of post-quantum key exchanges. For higher long-= term security, it can be combined with other, more conventional algorithms = which follow either in intermediate or followup exchanges. I think that this combined key exchange algorithm can also be implemented (= with more flexibility) by doing IKE_SA_INIT(X25519)+IKE_INTERMEDIATE(SNTRUP= 761). I don't think your approach has real advantages in terms of consuming= responder's resources. The responder still needs to perform both X25519 an= d SNTRUP761 before it authenticates the initiator. Yes, you save one round trip, but the amount of data sent on the wire and t= he amount of CPU cycles are roughly the same. I'd like also mention that wh= ile X25519 and SNTRUP761 public keys are fit into a single 1500 bytes IKE m= essage, they leave relatively little space for SA payload, so initiator may= be limited in expressing its proposals. > We then propose to restrict the use of large key exchanges to the > context of option 3, which removes the risk of the described DoS > attacks. Yet, to prevent the insecurities of plain option 3, we also prop= ose to make it mandatory to combine it with the new hybrid transform type, = i.e., SNTRUP761X25519. Are you proposing to stick with these two particular algorithms? I don't think it's a good idea, giving the algorithm agility requirements. I think that the same result can be achieved with the current draft: IKE_SA_INIT(X25519 or whatever else) IKE_INTERMEDIATE(SNTRUP761 or whatever else with small public key) IKE_AUTH= (Childless if you want) CREATE_CHILD_SA+IKE_FOLLOWUP_KE(McEliece or whateve= r else with long public key) This leaves much more flexibility in selecting particular algorithms. > The only downside of this approach is that G-IKE is then incompatible > with the McEliece exchange. However, the fact that G-IKE exchanges > sensitive information before authentication makes it impossible to be > not vulnerable against the discussed DoS attack and, at the same time, su= pport the McEliece algorithm. Thus, we see that as a decision to be made in= the G-IKE standardization track, not in IKEv2. I agree that G-IKEv2 is very special, but I also agree with Tero's previous= message that protecting IKEv2 and (G-IKEv2 too) against DoS attacks leaves= in slightly different area. We have some mechanisms for this (not perfect, but that is that). Regards, Valery. > Regards, > > Stefan-Lukas Gazdag, Daniel Herzinger _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ________________________________ PQ Solutions Limited (trading as 'Post-Quantum') is a private limited compa= ny incorporated in England and Wales with registered number 06808505. This email is meant only for the intended recipient. If you have received t= his email in error, any review, use, dissemination, distribution, or copyin= g of this email is strictly prohibited. Please notify us immediately of the= error by return email and please delete this message from your system. Tha= nk you in advance for your cooperation. For more information about Post-Quantum, please visit www.post-quantum.com<= http://www.post-quantum.com>. In the course of our business relationship, we may collect, store and trans= fer information about you. Please see our privacy notice at www.post-quantu= m.com/privacy-notice to learn a= bout how we use this information. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Oct 28 19:19:48 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE023A0959; Thu, 28 Oct 2021 19:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZRESOKMaRDE; Thu, 28 Oct 2021 19:19:43 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94F1D3A0954; Thu, 28 Oct 2021 19:19:43 -0700 (PDT) Received: from fraeml705-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HgQxn4Vw8z67WcW; Fri, 29 Oct 2021 10:15:25 +0800 (CST) Received: from kwepeml100004.china.huawei.com (7.221.188.19) by fraeml705-chm.china.huawei.com (10.206.15.54) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.15; Fri, 29 Oct 2021 04:19:39 +0200 Received: from kwepeml500004.china.huawei.com (7.221.188.141) by kwepeml100004.china.huawei.com (7.221.188.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Fri, 29 Oct 2021 10:19:37 +0800 Received: from kwepeml500004.china.huawei.com ([7.221.188.141]) by kwepeml500004.china.huawei.com ([7.221.188.141]) with mapi id 15.01.2308.015; Fri, 29 Oct 2021 10:19:37 +0800 From: "Panwei (William)" To: "draft-pwouters-ipsecme-multi-sa-performance@ietf.org" CC: "ipsec@ietf.org" Thread-Topic: Comments on draft-pwouters-multi-sa-performance Thread-Index: AdfL2PwR5lphcqWoSvCzgV2vdsvQZA== Date: Fri, 29 Oct 2021 02:19:37 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.99.246] Content-Type: multipart/alternative; boundary="_000_cc0b5528e7c047e0a9073f637218f013huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [IPsec] Comments on draft-pwouters-multi-sa-performance X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2021 02:19:46 -0000 --_000_cc0b5528e7c047e0a9073f637218f013huaweicom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYXV0aG9ycywNCg0KSaGvdmUgcmVhZCB0aGUgcmVjZW50IHZlcnNpb24uIFRoaXMgaXMgYW4g aW50ZXJlc3Rpbmcgc29sdXRpb24uIEkgdGhpbmsgaXQgc2hvdWxkIGJlIGFkb3B0ZWQuIEJlbG93 IGFyZSBzb21lIGNvbW1lbnRzLg0KDQoxLg0KVGhlIENQVV9RVUVVRVMgbm90aWZpY2F0aW9uIHZh bHVlIHJlZmVycyB0byB0aGUgbnVtYmVyIG9mIGFkZGl0aW9uYWwNCnJlc291cmNlLXNwZWNpZmlj IENoaWxkIFNBcyB0aGF0IG1heSBiZSBpbnN0YWxsZWQgZm9yIHRoaXMgcGFydGljdWxhcg0KVFNp L1RTciBjb21iaW5hdGlvbiBleGNsdWRpbmcgdGhlIEZhbGxiYWNrIENoaWxkIFNBLg0KSXMgaXQg bmVjZXNzYXJ5IHRvIGxpbWl0IHRoZSBhbW91bnQgb2YgYWRkaXRpb25hbCBTQXMgYXQgdGhlIGJl Z2lubmluZyB3aGlsZSBUU19NQVhfUVVFVUUgY2FuIGJlIHVzZWQgdG8gcmVqZWN0IHRoZSByZXF1 ZXN0IG9mIGNyZWF0aW5nIGFkZGl0aW9uYWwgU0EgYXQgYW55IHRpbWU/IEluIHRoZSB2aXJ0dWFs aXphdGlvbiBzY2VuYXJpbywgdGhlIG5ldyBWTXMgY2FuIGJlIGxhdW5jaGVkIG9uLWRlbWFuZCwg aW4gb3RoZXIgd29yZHMsIGl0IG1heSBiZSBzZWVuIGFzIHRoZSBudW1iZXIgb2YgQ1BVcyBpc26h r3QgZml4ZWQsIHNvIG1heWJlIGxpbWl0aW5nIHRoZSBhZGRpdGlvbiBTQXMgYXQgdGhlIGJlZ2lu bmluZyB3aWxsIGRhbWFnZSB0aGUgZmxleGliaWxpdHkuDQoNCjIuDQpUaGUgQ1BVX1FVRVVFUyBu b3RpZmljYXRpb24gcGF5bG9hZCBpcyBzZW50IGluIHRoZSBJS0VfQVVUSCBvcg0KQ1JFQVRFX0NI SUxEX1NBIEV4Y2hhbmdlIGluZGljYXRpbmcgdGhlIG5lZ290aWF0ZWQgQ2hpbGQgU0EgaXMgYQ0K RmFsbGJhY2sgU0EuDQpCZWZvcmUgYWRkaXRpb25hbCBTQXMgYXJlIGNyZWF0ZWQsIGlzIHRoZXJl IGFueSBkaWZmZXJlbmNlIGJldHdlZW4gdXNpbmcgdGhpcyBmaXJzdC9GYWxsYmFjayBTQSBhbmQg dXNpbmcgb3RoZXIgbm9ybWFsIFNBPyBJIHRoaW5rIHRoZXJlIGlzIG5vIGRpZmZlcmVuY2UuIFNv IG1heWJlIHdlIGRvbqGvdCBuZWVkIHRvIGFkZCB0aGlzIG5vdGlmaWNhdGlvbiBwYXlsb2FkIHdo ZW4gY3JlYXRpbmcgdGhlIGZpcnN0IFNBLiBXaGVuIHRoZSBpbml0aWF0b3Igd2FudHMgdG8gY3Jl YXRlIGFuIGFkZGl0aW9uYWwgU0EsIGl0IGNhbiBkaXJlY3RseSBzZW5kIHRoZSByZXF1ZXN0IHdp dGggQ1BVX1FVRVVFX0lORk8gbm90aWZpY2F0aW9uIHBheWxvYWQuIFRoZXJlIGFyZSAzIHdheXMg dGhhdCB0aGUgcmVzcG9uZGVyIG1heSByZXBseTogMSkgVGhlIHJlc3BvbmRlciBkb2VzbqGvdCBz dXBwb3J0L3JlY29nbml6ZSB0aGlzIG5vdGlmaWNhdGlvbiwgaXQgd2lsbCBpZ25vcmUgdGhpcyBu b3RpZmljYXRpb24gYW5kIHJlcGx5IGFzIHVzdWFsLiAyKSBJdCBzdXBwb3J0cyB0aGlzIGZ1bmN0 aW9uIGFuZCBpcyB3aWxsaW5nIHRvIGNyZWF0ZSB0aGUgYWRkaXRpb25hbCBTQSwgc28gaXQgd2ls bCByZXBseSB3aXRoIENQVV9RVUVVRV9JTkZPIG5vdGlmaWNhdGlvbiB0b28uIDMpIEl0IHN1cHBv cnRzIHRoaXMgZnVuY3Rpb24sIGJ1dCBpdCBpc26hr3Qgd2lsbGluZyB0byBjcmVhdGUgbW9yZSBh ZGRpdGlvbmFsIFNBcywgc28gaXQgd2lsbCByZXBseSB3aXRoIFRTX01BWF9RVUVVRS4gVGhlcmVm b3JlLCBpdCBzZWVtcyBsaWtlIHRoYXQgQ1BVX1FVRVVFX0lORk8gYW5kIFRTX01BWF9RVUVVRSB0 aGVzZSAyIG5vdGlmaWNhdGlvbnMgYXJlIGVub3VnaCB0byB1c2UsIGFuZCB0aGUgZHJhZnQgY2Fu IGJlIHNpbXBsaWZpZWQgdG8gb25seSB1c2UgdGhlc2UgMiBub3RpZmljYXRpb25zLg0KDQozLg0K Qm90aCBwZWVycyBzZW5kDQp0aGUgcHJlZmVycmVkIG1pbmltdW0gbnVtYmVyIG9mIGFkZGl0aW9u YWwgQ2hpbGQgU0FzIHRvIGluc3RhbGwuDQpGaXJzdCwgSSB0aGluayBzZW5kaW5nIHRoZSBudW1i ZXIgb2YgYWRkaXRpb25hbCBDaGlsZCBTQXMgaXMgdW5uZWNlc3NhcnkuIFNlY29uZCwgd2hlbiB1 c2luZyChsG1pbmltdW2hsSBoZXJlIG15IGZpcnN0IGltcHJlc3Npb24gaXMgdGhhdCBpdCBtZWFu cyAwLCBzbyBpbiBvcmRlciB0byByZW1vdmUgYW1iaWd1aXR5IEkgc3VnZ2VzdCBqdXN0IHNheWlu ZyChsHRoZSBwcmVmZXJyZWQgbnVtYmVyobEgKGlmIHlvdSB0aGluayBzZW5kaW5nIHRoZSBudW1i ZXIgaXMgbmVjZXNzYXJ5KS4NCg0KNC4NCklmIGEgQ1JFQVRFX0NISUxEX1NBIGV4Y2hhbmdlIHJl cXVlc3QgY29udGFpbmluZyBib3RoIGENCkNQVV9RVUVVRV9JTkZPIGFuZCBhIENQVV9RVUVVRVMg bm90aWZpY2F0aW9uIGlzIHJlY2VpdmVkLCB0aGUNCnJlc3BvbmRlciBNVVNUIGlnbm9yZSB0aGUg Q1BVX1FVRVVFX0lORk8gcGF5bG9hZC4gSWYgYQ0KQ1JFQVRFX0NISUxEX1NBIGV4Y2hhbmdlIHJl cGx5IGlzIHJlY2VpdmVkIHdpdGggYm90aCBDUFVfUVVFVUVfSU5GTw0KYW5kIENQVV9RVUVVRVMg bm90aWZpY2F0aW9ucywgdGhlIGluaXRpYXRvciBNVVNUIGlnbm9yZSB0aGUNCm5vdGlmaWNhdGlv biB0aGF0IGl0IGRpZCBub3Qgc2VuZCBpbiB0aGUgcmVxdWVzdC4NCkkgdGhpbmsgdGhlcmUgaXMg YW1iaWd1aXR5IGhlcmUuIFdoZW4gdGhlIGluaXRpYXRvciBzZW5kcyB0aGUgQ1JFQVRFX0NISUxE X1NBIGV4Y2hhbmdlIHJlcXVlc3QgY29udGFpbmluZyBib3RoIGEgQ1BVX1FVRVVFX0lORk8gYW5k IGEgQ1BVX1FVRVVFUyBub3RpZmljYXRpb24sIGFuZCB0aGUgcmVzcG9uZGVyIGFsc28gYWRkcyBD UFVfUVVFVUVfSU5GTyBhbmQgQ1BVX1FVRVVFUyBub3RpZmljYXRpb25zIGluIHRoZSByZXBseSwg dGhlIGluaXRpYXRvciBkb2VzbqGvdCBrbm93IGhvdyB0byBwcm9jZXNzIHdpdGggdGhpcyBzaXR1 YXRpb24sIHNob3VsZCB0aGUgaW5pdGlhdG9yIGlnbm9yZSB0aGUgQ1BVX1FVRVVFX0lORk8gcGF5 bG9hZCBvciBub3RpZnkgYW4gZXJyb3IgdG8gdGhlIHJlc3BvbmRlcj8NCg0KDQpSZWdhcmRzICYg VGhhbmtzIQ0KV2VpIFBhbiAoxcvOsCkNCg0K --_000_cc0b5528e7c047e0a9073f637218f013huaweicom_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi authors,

 

I=A1=AFve read the recent version. This is an interesting so= lution. I think it should be adopted. Below are some comments.

 

1.

The CPU_QUEUES notifica= tion value refers to the number of additional

resource-specific Child= SAs that may be installed for this particular

TSi/TSr combination exc= luding the Fallback Child SA.

Is it necessary to limit the amount of additional SAs at the= beginning while TS_MAX_QUEUE can be used to reject the request of creating= additional SA at any time? In the virtualization scenario, the new VMs can be launched on-demand, in other words, it may be= seen as the number of CPUs isn=A1=AFt fixed, so maybe limiting the additio= n SAs at the beginning will damage the flexibility.

 

2.

The CPU_QUEUES notifica= tion payload is sent in the IKE_AUTH or

CREATE_CHILD_SA Exchang= e indicating the negotiated Child SA is a

Fallback SA.=

Before additional SAs are created, is there any difference b= etween using this first/Fallback SA and using other normal SA? I think ther= e is no difference. So maybe we don=A1=AFt need to add this notification payload when creating the first SA. When the initiat= or wants to create an additional SA, it can directly send the request with = CPU_QUEUE_INFO notification payload. There are 3 ways that the responder ma= y reply: 1) The responder doesn=A1=AFt support/recognize this notification, it will ignore this notification and = reply as usual. 2) It supports this function and is willing to create the a= dditional SA, so it will reply with CPU_QUEUE_INFO notification too. 3) It = supports this function, but it isn=A1=AFt willing to create more additional SAs, so it will reply with TS_MAX_QUEUE.= Therefore, it seems like that CPU_QUEUE_INFO and TS_MAX_QUEUE these 2 noti= fications are enough to use, and the draft can be simplified to only use th= ese 2 notifications.

 

3.

Both pee= rs send

the pref= erred minimum number of additional Child SAs to install.<= /p>

First, I think sending the number of additional Child SAs is= unnecessary. Second, when using =A1=B0minimum=A1=B1 here my first impressi= on is that it means 0, so in order to remove ambiguity I suggest just saying =A1=B0the preferred number=A1=B1 (if you think sending= the number is necessary).

 

4.

If a CRE= ATE_CHILD_SA exchange request containing both a
CPU_QUEUE_INFO and a CPU_QUEUES notification is received, the
responder MUST ignore the CPU_QUEUE_INFO payload. If a
CREATE_CHILD_SA exchange reply is received with both CPU_QUEUE_INFO
and CPU_QUEUES notifications, the initiator MUST ignore the
notification that it did not send in the request.

I think there is ambiguity here. When the initiator sends th= e CREATE_CHILD_SA exchange request containing both a CPU_QUEUE_INFO and a C= PU_QUEUES notification, and the responder also adds CPU_QUEUE_INFO and CPU_QUEUES notifications in the reply, the initiat= or doesn=A1=AFt know how to process with this situation, should the initiat= or ignore the CPU_QUEUE_INFO payload or notify an error to the responder?

 

 

Regards & Thanks!

Wei Pan (=C5=CB=CE=B0)

<= o:p> 

--_000_cc0b5528e7c047e0a9073f637218f013huaweicom_-- From nobody Thu Oct 28 20:57:47 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFB453A089C for ; Thu, 28 Oct 2021 20:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.62 X-Spam-Level: X-Spam-Status: No, score=-9.62 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-p4a41wCIU5 for ; Thu, 28 Oct 2021 20:57:40 -0700 (PDT) Received: from smtp-fw-9103.amazon.com (smtp-fw-9103.amazon.com [207.171.188.200]) (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 9DF1E3A08A9 for ; Thu, 28 Oct 2021 20:57:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1635479860; x=1667015860; h=from:to:cc:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=B3h4VJziqHyur+mWZq+EN38qAHGST4zoOMsuijzEVAI=; b=ONfMCuEpKeqrHJVggMkmTxuF55b5GUkvaXP7t5j39MxOcye7S3ksKa98 iQsAnXYYvrI/OmeiT9fpiZIRMQyDdoXKTMd1Ggp/9+P26l/HHIVRRW5uF /HDTANJUGPQeq3Avon5HkwXqMWV/SSYmZ1/q+D+7GVfkLN5/m/pI4+YU4 g=; X-IronPort-AV: E=Sophos;i="5.87,191,1631577600"; d="scan'208";a="968120728" Thread-Topic: [UNVERIFIED SENDER] RE: [IPsec] Cost-efficient quantum-resistant DoS protection Received: from pdx4-co-svc-p1-lb2-vlan2.amazon.com (HELO email-inbound-relay-iad-1a-4ba5c7da.us-east-1.amazon.com) ([10.25.36.210]) by smtp-border-fw-9103.sea19.amazon.com with ESMTP; 29 Oct 2021 03:57:30 +0000 Received: from EX13MTAUWB001.ant.amazon.com (iad12-ws-svc-p26-lb9-vlan2.iad.amazon.com [10.40.163.34]) by email-inbound-relay-iad-1a-4ba5c7da.us-east-1.amazon.com (Postfix) with ESMTPS id 45A9C91AD2; Fri, 29 Oct 2021 03:57:28 +0000 (UTC) Received: from EX13D01ANC002.ant.amazon.com (10.43.157.162) by EX13MTAUWB001.ant.amazon.com (10.43.161.249) with Microsoft SMTP Server (TLS) id 15.0.1497.24; Fri, 29 Oct 2021 03:57:28 +0000 Received: from EX13D01ANC003.ant.amazon.com (10.43.157.68) by EX13D01ANC002.ant.amazon.com (10.43.157.162) with Microsoft SMTP Server (TLS) id 15.0.1497.24; Fri, 29 Oct 2021 03:57:27 +0000 Received: from EX13D01ANC003.ant.amazon.com ([10.43.157.68]) by EX13D01ANC003.ant.amazon.com ([10.43.157.68]) with mapi id 15.00.1497.024; Fri, 29 Oct 2021 03:57:27 +0000 From: "Kampanakis, Panos" To: "Scott Fluhrer (sfluhrer)" , "Daniel Herzinger" CC: "ipsec@ietf.org" , Valery Smyslov , "ietf@gazdag.de" Thread-Index: AQHXzBEK4fxsVPHysEeVXeXRJKEt66vpWHVw Date: Fri, 29 Oct 2021 03:57:27 +0000 Message-ID: References: <70b270f5ed3842f28f18dbe1488399e7@EX13D01ANC003.ant.amazon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.157.220] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] [UNVERIFIED SENDER] RE: Cost-efficient quantum-resistant DoS protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2021 03:57:46 -0000 Hey Scott,=20 > Sorry if I ask such an obvious question, but would McEliece perform bette= r against packet loss if we introduce a more intelligent ack/retry method? = For each, the ack would list which segments of the packet have been receiv= ed (e.g. bytes 0-3240 and bytes 6780-9800), so that on a retransmit, we onl= y need to resend the segments that were dropped? And, of course, we'd rese= nd the ack multiple times, in case that is dropped. I think that would help. It would not solve the issue of higher loss probab= ility but it would enable better recovery from it similar to TCP's.=20 > Of course, the complexity of all this wouldn't be warranted in the origin= al envisioned use cases of IKE fragmentation (where it was never expected t= hat there would be that many fragments) - given that the use case has chang= ed, would it make sense to revisit this? Imo, I am not sure it is worth the complexity. Personally, I expect leaner = PQ KEMs to be picked for standardization in common protocols, not McEliece.= =20 -----Original Message----- From: Scott Fluhrer (sfluhrer) =20 Sent: Thursday, October 28, 2021 11:25 AM To: Kampanakis, Panos ; Daniel Herzinger Cc: ipsec@ietf.org; Valery Smyslov ; ietf@gazdag.de Subject: [EXTERNAL] [UNVERIFIED SENDER] RE: [IPsec] Cost-efficient quantum-= resistant DoS protection CAUTION: This email originated from outside of the organization. Do not cli= ck links or open attachments unless you can confirm the sender and know the= content is safe. Sorry if I ask such an obvious question, but would McEliece perform better = against packet loss if we introduce a more intelligent ack/retry method? F= or each, the ack would list which segments of the packet have been received= (e.g. bytes 0-3240 and bytes 6780-9800), so that on a retransmit, we only = need to resend the segments that were dropped? And, of course, we'd resend= the ack multiple times, in case that is dropped. Of course, the complexity of all this wouldn't be warranted in the original= envisioned use cases of IKE fragmentation (where it was never expected tha= t there would be that many fragments) - given that the use case has changed= , would it make sense to revisit this? -----Original Message----- From: IPsec On Behalf Of Kampanakis, Panos Sent: Tuesday, October 26, 2021 1:37 PM To: Daniel Herzinger Cc: ipsec@ietf.org; Valery Smyslov ; ietf@gazdag.de Subject: Re: [IPsec] Cost-efficient quantum-resistant DoS protection Hi Daniel, > To give more insight about these measurements, we implemented all three d= rafts and tested the performance of a medium-sized McEliece key exchange un= der different networking conditions (variable latency, packet loss, and thr= oughput). Especially when packet loss or throughput surpass specific thresh= holds (~ above 1% packet loss and below 3Mbit of throughput), the overall p= erformance suffers significantly. Yet, we deem those values acceptable, as = long as we don't use cellular or similarly unreliable networks. Furthermore= , we expect a gateway communicating with many peers to have higher requirem= ents to its network uplink. Yet, as this will most likely be positioned in = a data center, this challenge should also be doable. Altogether, this left = us with a surprisingly positive view on the possibility of adopting McEliec= e-sized key exchanges at least for some use-cases. > The introduction of new Transform-IDs like SNTRUP761X25519 is a good shor= t-term solution, as it addresses the problem without requiring much effort = in terms of standardization or implementation. Understood. I am curious to see the measurements published btw. Are the pub= lic somewhere? A couple counter arguments: Cloudflare's tests (https://blog.cloudflare.com/the-tls-post-quantum-experi= ment/ ) showed a bunch of variability for way more compact KEMs than McElie= ce (SIKE, NTRU-HRSS) at the 95% and 99% percentile. https://www.ndss-sympos= ium.org/wp-content/uploads/2020/02/24203-paper.pdf tested similar things, b= ut the tails (9x% percentiles) looked better because it was a controller wi= red environment. Similarly, the datacenter using jumbo frames would not swe= at at all, but the issues arise at >90% percentile and affect folks in infr= astructures that are not as developed as in the western world. Also think a= bout congestion control and how that could impact infrastructures. These ar= e important challenges that McEliece would bring. Also think of the loss probability. https://eprint.iacr.org/2019/1447 talks= about it. If you are sending 2-3 packets for a few KB public key or cipher= text then the total loss probability is 1-(1-p)^3 where p is the link loss = probability. Let's say p=3D1%, that becomes ~3% which is not too bad. Now w= ith 64KB and assuming 1400B packets, the probability becomes 1-(1-p)^45 whi= ch is ~36% with p=3D1%. 36% loss would slow down handshakes significantly, = especially UDP-based ones. BSI may be endorsing the algorithm. It is indeed very mature and trusted. I= am sure many others would endorse it too. But it is impractical to say we = will standardize McEliece for the environments that can afford it and the r= est will pick something else. Migrating algorithms is painful and cumbersom= e as we have seen in hash and other algorithm migrations. Integrating two n= ew PQ KEMs depending on usecase is not straightforward. History has shown t= hat new algorithms that make sense get deployed in TLS, IKEv2, SSH etc. Imo McEliece is not viable for the internet, unless there were significant = redesigns and no other options. As a great cryptographer told me one time, if we are to use McEliece what i= s the point of all this work taking place to come up with better and more e= fficient PQ KEMs? Rgs, Panos -----Original Message----- From: Daniel Herzinger Sent: Tuesday, October 26, 2021 8:26 AM To: CJ Tjhai ; Kampanakis, Panos Cc: Valery Smyslov ; ipsec@ietf.org; ietf@gazdag.de Subject: [EXTERNAL] [UNVERIFIED SENDER] AW: [IPsec] Cost-efficient quantum-= resistant DoS protection Hi, the fact is that accepting a significantly increased amount of data from an= unauthenticated peer also significantly increases the surface to DoS attac= ks. Even without surpassing the 64KB limit, this must be a concern. IKEv2's= cookie mechanism and puzzles try to increase the cost of the attacker per = each connection. Now, an attacker must still accept these costs but can use= one connection to trigger several key exchanges, all significantly larger = than what we had with DH, making the trade-off way better for them compared= to non-pqc IKEv2. So, the attacker could, e.g., negotiate several FrodoKEM= s (all with different parameters to circumvent the rule that all key exchan= ge methods must be different). Compared to classical non-hybrid (EC)DH, suc= h a DoS attack requires significantly less cost to have the same effect. The introduction of MB-sized key exchanges just amplifies this problem even= further (also allowing several McEliece KEMs with different parameters cir= cumventing this constraint). Thus, while we should already thoroughly asses= and mitigate the risk of this possible weakness for https://datatracker.ie= tf.org/doc/draft-ietf-ipsecme-ikev2-multiple-ke/, we definitely must do it = for https://datatracker.ietf.org/doc/draft-tjhai-ikev2-beyond-64k-limit/. Currently, there is no place defined where a McEliece-sized key exchange ca= n take place. So, at least one of the two drafts (probably beyond-64k or mu= ltiple-ke) or better both should make this clear. At the moment, beyond-64k= defines how the transmission of such key exchanges could look like but the= question of where these ideas could be put into action are left to the rea= der, leading to inevitable confusion. The fact that there are several draft= s aiming at the same problem, without really defining their contact points = or interactions, further exacerbates this. The most obvious way to prevent an attacker from exploiting the new attack = surface is to accept the larger key exchanges only from an already authenti= cated peer. As mentioned before, we think childless IKEv2 with immediate re= keying would be a good compromise to achieve that. > Imo, McEliece is not practical for live protocols like TLS or IKEv2. McEliece is more trusted than its pqc alternatives which also makes it the = favored choice of some agencies like the German BSI. Obviously, they all kn= ow the challenges of integrating such large key exchanges, still they would= surely appreciate any effort which goes into this direction. This justifie= s pursuing the idea further, especially since first measurements look bette= r than one would probably expect. To give more insight about these measurements, we implemented all three dra= fts and tested the performance of a medium-sized McEliece key exchange unde= r different networking conditions (variable latency, packet loss, and throu= ghput). Especially when packet loss or throughput surpass specific threshho= lds (~ above 1% packet loss and below 3Mbit of throughput), the overall per= formance suffers significantly. Yet, we deem those values acceptable, as lo= ng as we don't use cellular or similarly unreliable networks. Furthermore, = we expect a gateway communicating with many peers to have higher requiremen= ts to its network uplink. Yet, as this will most likely be positioned in a = data center, this challenge should also be doable. Altogether, this left us= with a surprisingly positive view on the possibility of adopting McEliece-= sized key exchanges at least for some use-cases. The introduction of new Transform-IDs like SNTRUP761X25519 is a good short-= term solution, as it addresses the problem without requiring much effort in= terms of standardization or implementation. This becomes even more importa= nt, as intermediate exchanges and their high complexity, due to their inter= connectedness with authentication, mean that especially the IKEv2 implement= ations of smaller projects will take their time for its integration. Thus, = having an easier short-term solution at hand means a real advantage. Also, the constrained size of such transforms mostly eliminates the aforeme= ntioned DoS risks. Finally, should the beyond-64k draft be adopted, then having a small set of= such additional Tranform-IDs is even more beneficial since it makes preven= ting the unlikely yet possible attack described in our initial mail easier. Regards, Stefan and Daniel ________________________________________ Von: CJ Tjhai Gesendet: Donnerstag, 21. Oktober 2021 18:39:16 An: Kampanakis, Panos Cc: Valery Smyslov; Daniel Herzinger; ipsec@ietf.org; ietf@gazdag.de Betreff: Re: [IPsec] Cost-efficient quantum-resistant DoS protection Hi Panos, There are two drafts involved here. a) the main draft, https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev= 2-multiple-ke/, cannot support any public-key larger than 64KB, so it can n= ever be used for KEMs like McEliece. So the option 3 is implied here. b) on the other hand, https://datatracker.ietf.org/doc/draft-tjhai-ikev2-be= yond-64k-limit/ is an attempt to address the issue with transferring payloa= d larger than 64KB. As you pointed out, transferring large blob of data in = a live protocol is challenging and therefore it deservers separate treatmen= ts and considerations. It was deliberate that we split the hybrid key excha= nge drafts into two, the second draft is there just in case there is any in= terest in the working group on supporting the use KEMs like McEliece. Cheers, CJ On Thu, 21 Oct 2021 at 16:49, Kampanakis, Panos > wrote: Hi Valery, Tero, > Not really. First, the situation with seven McEliece is not possible, sin= ce all negotiated Key Exchange methods MUST be different. Then, you seem to assume that the responder blindly accepts all the key exc= hanges at the initiator's will. This is not true. First peers negotiate which key exchanges they will perfo= rm (including additional key exchanges), and you can limit the types and th= e number additional key exchanges the responder will accept via its local p= olicy. I think the point is valid though if the responder supports McEliece. A mis= creant can that way make the responder put a lot of data on the wire like a= n amplification attack although the initiator has not been validated. QUIC = has a 3x amplification protection limits for that matter. Sure, the issue existed even in ECDH exchanges, but the impact is much high= er when we talk MB of public keys. Imo, McEliece is not practical for live protocols like TLS or IKEv2. Too ma= ny packets mean pretty high loss probability in unstable networks which mea= ns pretty bad performance unless everything happens in the datacenter or ro= bust end-to-end network paths. The PQ KEMs that will end up being standardi= zed are likely to have just a few KBs of public key and ciphertext which is= better for the general case. So, I would say option 3 (prohibit the use of very large KE payloads like M= cEliece's MB sized public keys) is more practical. Rgs, Panos -----Original Message----- From: IPsec > On Beha= lf Of Valery Smyslov Sent: Tuesday, October 19, 2021 11:46 AM To: 'Daniel Herzinger' >; ipsec@ietf.org Cc: ietf@gazdag.de Subject: RE: [EXTERNAL] [IPsec] Cost-efficient quantum-resistant DoS protec= tion CAUTION: This email originated from outside of the organization. Do not cli= ck links or open attachments unless you can confirm the sender and know the= content is safe. Hi Daniel and Stefan-Lukas, > Hi, > > in response to the new version of > draft-ietf-ipsecme-ikev2-multiple-ke-04.txt, we wanted to emphasize=20 > the issue of DoS attacks during intermediate exchanges. The new=20 > version does address it by mentioning the option of simply avoiding=20 > intermediate exchanges altogether but still require additional key=20 > exchanges. Yet, this protects only against record-and-harvest attacks=20 > but not against an attacker with a strong quantum computer at the time=20 > of the handshake, regardless of quantum-resistant authentication=20 > (since they can break the initial shared secret and therefore=20 > recalculate the MAC which authenticates the followup exchanges, fully=20 > establishing a man-in-the-middle). We doubt that an attacker, even with a= strong quantum computer, is able to break a key exchange in such a short t= ime period. Still, this assumption is too theoretical to rely on. This, tog= ether with the fact that Group-IKE is incompatible with key exchanges durin= g followup exchanges, makes the option seem inferior to just sticking to in= termediate exchanges during the handshake. However, we must also consider t= he draft-tjhai-ikev2-beyond-64k-limit-01.txt. > An attacker who exploits the large key exchanges, e.g., by requesting=20 > seven additional maximum size McEliece key exchanges, can force a gateway= to accept and process 1.4MB of data per McEliece KEM. Not really. First, the situation with seven McEliece is not possible, since= all negotiated Key Exchange methods MUST be different. Then, you seem to assume that the responder blindly accepts all the key exc= hanges at the initiator's will. This is not true. First peers negotiate which key exchanges they will perfo= rm (including additional key exchanges), and you can limit the types and th= e number additional key exchanges the responder will accept via its local p= olicy. > This leaves us at > a situation where we must pick one of the following options: > > 1. Accept the highly increased risk of DoS attacks. > 2. Prohibit the use of large KE payloads, hence the McEliece mechanism. > 3. Prohibit the use of intermediate exchanges, leaving the IKE SA=20 > initially unprotected and being vulnerable to an attacker with a quantum = computer during the handshake. > > To us, none of these options seems desirable. Thus, we propose another=20 > solution which sees one new transform type, e.g., SNTRUP761X25519,=20 > which then defines a combination of one classical algorithm (like I'm confused here - did you mean new transform type or new transform ID? Transform types define a kind of algorithms (or other features, like ESN), = while transform IDs define a particular algorithm of this type. Unless I'm missing something I presume you meant new transform ID which def= ines a new key exchange algorithm which is a combination of SNTRUP761 and X= 25519. Correct me if I'm wrong. > ECDH based on curve25519) and one pqc algorithm which fits into=20 > IKE_SA_INIT without fragmentation (like sntruprime761). The two=20 > secrets get concatinated and then fed to a hash function. The=20 > resulting hash is used as the shared secret for further key=20 > derivation. This mechanism is low effort in terms of implementation=20 > and does not affect the state machine at all, but already offers a=20 > high level of protection against all attacks as long as there is no major= break-through in cryptanalysis. Furthermore, it is the accepted approach f= or most of the applications of post-quantum key exchanges. For higher long-= term security, it can be combined with other, more conventional algorithms = which follow either in intermediate or followup exchanges. I think that this combined key exchange algorithm can also be implemented (= with more flexibility) by doing IKE_SA_INIT(X25519)+IKE_INTERMEDIATE(SNTRUP= 761). I don't think your approach has real advantages in terms of consuming= responder's resources. The responder still needs to perform both X25519 an= d SNTRUP761 before it authenticates the initiator. Yes, you save one round trip, but the amount of data sent on the wire and t= he amount of CPU cycles are roughly the same. I'd like also mention that wh= ile X25519 and SNTRUP761 public keys are fit into a single 1500 bytes IKE m= essage, they leave relatively little space for SA payload, so initiator may= be limited in expressing its proposals. > We then propose to restrict the use of large key exchanges to the=20 > context of option 3, which removes the risk of the described DoS=20 > attacks. Yet, to prevent the insecurities of plain option 3, we also prop= ose to make it mandatory to combine it with the new hybrid transform type, = i.e., SNTRUP761X25519. Are you proposing to stick with these two particular algorithms? I don't think it's a good idea, giving the algorithm agility requirements. I think that the same result can be achieved with the current draft: IKE_SA_INIT(X25519 or whatever else) IKE_INTERMEDIATE(SNTRUP761 or whatever else with small public key) IKE_AUTH= (Childless if you want) CREATE_CHILD_SA+IKE_FOLLOWUP_KE(McEliece or whateve= r else with long public key) This leaves much more flexibility in selecting particular algorithms. > The only downside of this approach is that G-IKE is then incompatible=20 > with the McEliece exchange. However, the fact that G-IKE exchanges=20 > sensitive information before authentication makes it impossible to be=20 > not vulnerable against the discussed DoS attack and, at the same time, su= pport the McEliece algorithm. Thus, we see that as a decision to be made in= the G-IKE standardization track, not in IKEv2. I agree that G-IKEv2 is very special, but I also agree with Tero's previous= message that protecting IKEv2 and (G-IKEv2 too) against DoS attacks leaves= in slightly different area. We have some mechanisms for this (not perfect, but that is that). Regards, Valery. > Regards, > > Stefan-Lukas Gazdag, Daniel Herzinger _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ________________________________ PQ Solutions Limited (trading as 'Post-Quantum') is a private limited compa= ny incorporated in England and Wales with registered number 06808505. This email is meant only for the intended recipient. If you have received t= his email in error, any review, use, dissemination, distribution, or copyin= g of this email is strictly prohibited. Please notify us immediately of the= error by return email and please delete this message from your system. Tha= nk you in advance for your cooperation. For more information about Post-Quantum, please visit www.post-quantum.com<= http://www.post-quantum.com>. In the course of our business relationship, we may collect, store and trans= fer information about you. Please see our privacy notice at www.post-quantu= m.com/privacy-notice to learn a= bout how we use this information. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Oct 29 00:59:31 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A02003A0D5A for ; Fri, 29 Oct 2021 00:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtvzqY0-6KVd for ; Fri, 29 Oct 2021 00:59:24 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EA4E3A0D64 for ; Fri, 29 Oct 2021 00:59:24 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id n7so15514162ljp.5 for ; Fri, 29 Oct 2021 00:59:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=rYQhFYYV7Z7xNh4zH5IHIbY3fAjf3iM4VtIY/2wsBW0=; b=hyJIHqwG6Pe24ksxHTnOPyPmJkjdxa2qAeD5yyoXKOQ1giROxgH1LY7v+tsZ6TtguY Ipvi32nD+x2DOfusF+DsYw+W702hLL8bR/Tqm+q4j0g4CX6+xP+G8lUc8A6gV3mstUim SziBXkIZR5J/dii9vL47sbbEuyjvWXEfbYy6UGny9lnFcHTSZG/Y4u4j73GlJVSi2s2E 0WiPkKJgGGFG8FzXTRlZSHY5o3KyY/B6hKtu0BxyhR9JMTOA3Hp3dAP68X2GxkLwDCp2 YQT+5H1h/qIZh9MKeNkxZhBvoz2VWfegg8EpYXd4rqBrztb/sV6PWaTlUFRskJHODsuG 5TdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:content-language :thread-index; bh=rYQhFYYV7Z7xNh4zH5IHIbY3fAjf3iM4VtIY/2wsBW0=; b=nAAR91s8vQ3V+zWU2DDyW1+3jlfxsJHb5SdnRhUX9Mv6+3zWlk9j94zTc37x/JsGrT lQGf3RUh4aKKjRph5jkjFI9wjb4Kqd+RchyzU3a+fs5hTFwjb3mRzUIJgqENT/LN0cwo tVoMStS5i4urhXpQxwPXOXtHSfVn02/DjL/IQV1BnK7ZxJEz0T7C8Zdx+R+IqISXi3P1 b2tWvfkRwFAlxKyK8iQCU5dqXXbIdG4qdtLpFaKN8i8JQ3yURTpmhA7685aLe73t9Hze vtEKP0GYKCDAePLi91FDYMCFbw4fSxq+G8O3Mqy4OgEBYmFMGmWpGtc6TVOu9dXZea3q ZdAA== X-Gm-Message-State: AOAM531WHy9wyJx+EIax2s1l04N37WRLooKJ9/gUGt75TTf7KY6xJCeh K6KNhxnfKPT6a30RzSufS98= X-Google-Smtp-Source: ABdhPJwdtnmFThmF/KSLjxCdnEaLbzyka0tKAvl3VDy2wDUgXG4pjhPZvmyHTgiZ5b0ih2lcVYHpyQ== X-Received: by 2002:a2e:9cc6:: with SMTP id g6mr7497666ljj.450.1635494360765; Fri, 29 Oct 2021 00:59:20 -0700 (PDT) Received: from buildpc ([93.188.44.204]) by smtp.gmail.com with ESMTPSA id k16sm57365lfm.168.2021.10.29.00.59.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Oct 2021 00:59:19 -0700 (PDT) From: "Valery Smyslov" To: "'Scott Fluhrer \(sfluhrer\)'" , "'Kampanakis, Panos'" , "'Daniel Herzinger'" Cc: , References: <70b270f5ed3842f28f18dbe1488399e7@EX13D01ANC003.ant.amazon.com> In-Reply-To: Date: Fri, 29 Oct 2021 10:59:22 +0300 Message-ID: <057801d7cc9a$e2d7c3a0$a8874ae0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: ru Thread-Index: AQFlfy44G4bqCGRN17kol25Ku0jQJwNLJuRPrLPBn6A= Archived-At: Subject: Re: [IPsec] Cost-efficient quantum-resistant DoS protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2021 07:59:30 -0000 HI Scott, > Sorry if I ask such an obvious question, but would McEliece perform better against packet loss if we introduce > a more intelligent ack/retry method? For each, the ack would list which segments of the packet have been > received (e.g. bytes 0-3240 and bytes 6780-9800), so that on a retransmit, we only need to resend the > segments that were dropped? And, of course, we'd resend the ack multiple times, in case that is dropped. In draft-tjhai-ikev2-beyond-64k-limit-01 we proposed so called mixed transport mode. With this mode IKE starts from UDP 4500, but switches to TCP immediately after IKE_SA_INIT and continues to use TCP for all subsequent exchanges. At the same time ESP is still sent directly over IP or over UDP. This mode allows to reliably transfer large public keys with no additional transport complexities, but at the same time avoids performance penalties of using TCP for ESP. The mode is negotiated, so backward compatibility is preserved. Since IKE starts from UDP 4500, it allows to check whether UDP path really works (so that we won't get black hole for ESP) and detect whether NAT is present on it. > Of course, the complexity of all this wouldn't be warranted in the original envisioned use cases of IKE > fragmentation (where it was never expected that there would be that many fragments) - given that the use > case has changed, would it make sense to revisit this? I think that mixed mode is the simplest solution for this case and the problem of transferring large public keys in lossy networks is not the main concern with this mode. Regards, Valery. > Hi Daniel, > > > To give more insight about these measurements, we implemented all three drafts and tested the > performance of a medium-sized McEliece key exchange under different networking conditions (variable > latency, packet loss, and throughput). Especially when packet loss or throughput surpass specific threshholds > (~ above 1% packet loss and below 3Mbit of throughput), the overall performance suffers significantly. Yet, > we deem those values acceptable, as long as we don't use cellular or similarly unreliable networks. > Furthermore, we expect a gateway communicating with many peers to have higher requirements to its > network uplink. Yet, as this will most likely be positioned in a data center, this challenge should also be doable. > Altogether, this left us with a surprisingly positive view on the possibility of adopting McEliece-sized key > exchanges at least for some use-cases. > > > The introduction of new Transform-IDs like SNTRUP761X25519 is a good short-term solution, as it > addresses the problem without requiring much effort in terms of standardization or implementation. > > Understood. I am curious to see the measurements published btw. Are the public somewhere? > > A couple counter arguments: > > Cloudflare's tests (https://blog.cloudflare.com/the-tls-post-quantum-experiment/ ) showed a bunch of > variability for way more compact KEMs than McEliece (SIKE, NTRU-HRSS) at the 95% and 99% percentile. > https://www.ndss-symposium.org/wp-content/uploads/2020/02/24203-paper.pdf tested similar things, but > the tails (9x% percentiles) looked better because it was a controller wired environment. Similarly, the > datacenter using jumbo frames would not sweat at all, but the issues arise at >90% percentile and affect folks > in infrastructures that are not as developed as in the western world. Also think about congestion control and > how that could impact infrastructures. These are important challenges that McEliece would bring. > > Also think of the loss probability. https://eprint.iacr.org/2019/1447 talks about it. If you are sending 2-3 > packets for a few KB public key or ciphertext then the total loss probability is 1-(1-p)^3 where p is the link loss > probability. Let's say p=1%, that becomes ~3% which is not too bad. Now with 64KB and assuming 1400B > packets, the probability becomes 1-(1-p)^45 which is ~36% with p=1%. 36% loss would slow down handshakes > significantly, especially UDP-based ones. > > BSI may be endorsing the algorithm. It is indeed very mature and trusted. I am sure many others would > endorse it too. But it is impractical to say we will standardize McEliece for the environments that can afford it > and the rest will pick something else. Migrating algorithms is painful and cumbersome as we have seen in hash > and other algorithm migrations. Integrating two new PQ KEMs depending on usecase is not straightforward. > History has shown that new algorithms that make sense get deployed in TLS, IKEv2, SSH etc. > > Imo McEliece is not viable for the internet, unless there were significant redesigns and no other options. > > As a great cryptographer told me one time, if we are to use McEliece what is the point of all this work taking > place to come up with better and more efficient PQ KEMs? > > Rgs, > Panos > > > > -----Original Message----- > From: Daniel Herzinger > Sent: Tuesday, October 26, 2021 8:26 AM > To: CJ Tjhai ; Kampanakis, Panos > Cc: Valery Smyslov ; ipsec@ietf.org; ietf@gazdag.de > Subject: [EXTERNAL] [UNVERIFIED SENDER] AW: [IPsec] Cost-efficient quantum-resistant DoS protection > > > Hi, > > the fact is that accepting a significantly increased amount of data from an unauthenticated peer also > significantly increases the surface to DoS attacks. Even without surpassing the 64KB limit, this must be a > concern. IKEv2's cookie mechanism and puzzles try to increase the cost of the attacker per each connection. > Now, an attacker must still accept these costs but can use one connection to trigger several key exchanges, all > significantly larger than what we had with DH, making the trade-off way better for them compared to non-pqc > IKEv2. So, the attacker could, e.g., negotiate several FrodoKEMs (all with different parameters to circumvent > the rule that all key exchange methods must be different). Compared to classical non-hybrid (EC)DH, such a > DoS attack requires significantly less cost to have the same effect. > The introduction of MB-sized key exchanges just amplifies this problem even further (also allowing several > McEliece KEMs with different parameters circumventing this constraint). Thus, while we should already > thoroughly asses and mitigate the risk of this possible weakness for https://datatracker.ietf.org/doc/draft- > ietf-ipsecme-ikev2-multiple-ke/, we definitely must do it for https://datatracker.ietf.org/doc/draft-tjhai-ikev2- > beyond-64k-limit/. > Currently, there is no place defined where a McEliece-sized key exchange can take place. So, at least one of > the two drafts (probably beyond-64k or multiple-ke) or better both should make this clear. At the moment, > beyond-64k defines how the transmission of such key exchanges could look like but the question of where > these ideas could be put into action are left to the reader, leading to inevitable confusion. The fact that there > are several drafts aiming at the same problem, without really defining their contact points or interactions, > further exacerbates this. > > The most obvious way to prevent an attacker from exploiting the new attack surface is to accept the larger > key exchanges only from an already authenticated peer. As mentioned before, we think childless IKEv2 with > immediate rekeying would be a good compromise to achieve that. > > > Imo, McEliece is not practical for live protocols like TLS or IKEv2. > McEliece is more trusted than its pqc alternatives which also makes it the favored choice of some agencies like > the German BSI. Obviously, they all know the challenges of integrating such large key exchanges, still they > would surely appreciate any effort which goes into this direction. This justifies pursuing the idea further, > especially since first measurements look better than one would probably expect. > To give more insight about these measurements, we implemented all three drafts and tested the performance > of a medium-sized McEliece key exchange under different networking conditions (variable latency, packet loss, > and throughput). Especially when packet loss or throughput surpass specific threshholds (~ above 1% packet > loss and below 3Mbit of throughput), the overall performance suffers significantly. Yet, we deem those values > acceptable, as long as we don't use cellular or similarly unreliable networks. Furthermore, we expect a > gateway communicating with many peers to have higher requirements to its network uplink. Yet, as this will > most likely be positioned in a data center, this challenge should also be doable. Altogether, this left us with a > surprisingly positive view on the possibility of adopting McEliece-sized key exchanges at least for some use- > cases. > > The introduction of new Transform-IDs like SNTRUP761X25519 is a good short-term solution, as it addresses > the problem without requiring much effort in terms of standardization or implementation. This becomes even > more important, as intermediate exchanges and their high complexity, due to their interconnectedness with > authentication, mean that especially the IKEv2 implementations of smaller projects will take their time for its > integration. Thus, having an easier short-term solution at hand means a real advantage. > Also, the constrained size of such transforms mostly eliminates the aforementioned DoS risks. > Finally, should the beyond-64k draft be adopted, then having a small set of such additional Tranform-IDs is > even more beneficial since it makes preventing the unlikely yet possible attack described in our initial mail > easier. > > > Regards, > Stefan and Daniel > ________________________________________ > Von: CJ Tjhai > Gesendet: Donnerstag, 21. Oktober 2021 18:39:16 > An: Kampanakis, Panos > Cc: Valery Smyslov; Daniel Herzinger; ipsec@ietf.org; ietf@gazdag.de > Betreff: Re: [IPsec] Cost-efficient quantum-resistant DoS protection > > Hi Panos, > > There are two drafts involved here. > > a) the main draft, https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-multiple-ke/, cannot support any > public-key larger than 64KB, so it can never be used for KEMs like McEliece. So the option 3 is implied here. > > b) on the other hand, https://datatracker.ietf.org/doc/draft-tjhai-ikev2-beyond-64k-limit/ is an attempt to > address the issue with transferring payload larger than 64KB. As you pointed out, transferring large blob of > data in a live protocol is challenging and therefore it deservers separate treatments and considerations. It was > deliberate that we split the hybrid key exchange drafts into two, the second draft is there just in case there is > any interest in the working group on supporting the use KEMs like McEliece. > > Cheers, > CJ > > > > > On Thu, 21 Oct 2021 at 16:49, Kampanakis, Panos > > wrote: > Hi Valery, Tero, > > > Not really. First, the situation with seven McEliece is not possible, since all negotiated Key Exchange > methods MUST be different. > Then, you seem to assume that the responder blindly accepts all the key exchanges at the initiator's will. > This is not true. First peers negotiate which key exchanges they will perform (including additional key > exchanges), and you can limit the types and the number additional key exchanges the responder will accept > via its local policy. > > I think the point is valid though if the responder supports McEliece. A miscreant can that way make the > responder put a lot of data on the wire like an amplification attack although the initiator has not been > validated. QUIC has a 3x amplification protection limits for that matter. > > Sure, the issue existed even in ECDH exchanges, but the impact is much higher when we talk MB of public > keys. > > Imo, McEliece is not practical for live protocols like TLS or IKEv2. Too many packets mean pretty high loss > probability in unstable networks which means pretty bad performance unless everything happens in the > datacenter or robust end-to-end network paths. The PQ KEMs that will end up being standardized are likely to > have just a few KBs of public key and ciphertext which is better for the general case. > > So, I would say option 3 (prohibit the use of very large KE payloads like McEliece's MB sized public keys) is > more practical. > > Rgs, > Panos > > > > > > -----Original Message----- > From: IPsec > On Behalf Of Valery Smyslov > Sent: Tuesday, October 19, 2021 11:46 AM > To: 'Daniel Herzinger' >; > ipsec@ietf.org > Cc: ietf@gazdag.de > Subject: RE: [EXTERNAL] [IPsec] Cost-efficient quantum-resistant DoS protection > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments > unless you can confirm the sender and know the content is safe. > > > > Hi Daniel and Stefan-Lukas, > > > Hi, > > > > in response to the new version of > > draft-ietf-ipsecme-ikev2-multiple-ke-04.txt, we wanted to emphasize > > the issue of DoS attacks during intermediate exchanges. The new > > version does address it by mentioning the option of simply avoiding > > intermediate exchanges altogether but still require additional key > > exchanges. Yet, this protects only against record-and-harvest attacks > > but not against an attacker with a strong quantum computer at the time > > of the handshake, regardless of quantum-resistant authentication > > (since they can break the initial shared secret and therefore > > recalculate the MAC which authenticates the followup exchanges, fully > > establishing a man-in-the-middle). We doubt that an attacker, even with a strong quantum computer, is > able to break a key exchange in such a short time period. Still, this assumption is too theoretical to rely on. > This, together with the fact that Group-IKE is incompatible with key exchanges during followup exchanges, > makes the option seem inferior to just sticking to intermediate exchanges during the handshake. However, we > must also consider the draft-tjhai-ikev2-beyond-64k-limit-01.txt. > > An attacker who exploits the large key exchanges, e.g., by requesting > > seven additional maximum size McEliece key exchanges, can force a gateway to accept and process 1.4MB > of data per McEliece KEM. > > Not really. First, the situation with seven McEliece is not possible, since all negotiated Key Exchange methods > MUST be different. > Then, you seem to assume that the responder blindly accepts all the key exchanges at the initiator's will. > This is not true. First peers negotiate which key exchanges they will perform (including additional key > exchanges), and you can limit the types and the number additional key exchanges the responder will accept > via its local policy. > > > This leaves us at > > a situation where we must pick one of the following options: > > > > 1. Accept the highly increased risk of DoS attacks. > > 2. Prohibit the use of large KE payloads, hence the McEliece mechanism. > > 3. Prohibit the use of intermediate exchanges, leaving the IKE SA > > initially unprotected and being vulnerable to an attacker with a quantum computer during the handshake. > > > > To us, none of these options seems desirable. Thus, we propose another > > solution which sees one new transform type, e.g., SNTRUP761X25519, > > which then defines a combination of one classical algorithm (like > > I'm confused here - did you mean new transform type or new transform ID? > Transform types define a kind of algorithms (or other features, like ESN), while transform IDs define a > particular algorithm of this type. > > Unless I'm missing something I presume you meant new transform ID which defines a new key exchange > algorithm which is a combination of SNTRUP761 and X25519. > Correct me if I'm wrong. > > > ECDH based on curve25519) and one pqc algorithm which fits into > > IKE_SA_INIT without fragmentation (like sntruprime761). The two > > secrets get concatinated and then fed to a hash function. The > > resulting hash is used as the shared secret for further key > > derivation. This mechanism is low effort in terms of implementation > > and does not affect the state machine at all, but already offers a > > high level of protection against all attacks as long as there is no major break-through in cryptanalysis. > Furthermore, it is the accepted approach for most of the applications of post-quantum key exchanges. For > higher long-term security, it can be combined with other, more conventional algorithms which follow either in > intermediate or followup exchanges. > > I think that this combined key exchange algorithm can also be implemented (with more flexibility) by doing > IKE_SA_INIT(X25519)+IKE_INTERMEDIATE(SNTRUP761). I don't think your approach has real advantages in > terms of consuming responder's resources. The responder still needs to perform both X25519 and > SNTRUP761 before it authenticates the initiator. > Yes, you save one round trip, but the amount of data sent on the wire and the amount of CPU cycles are > roughly the same. I'd like also mention that while X25519 and SNTRUP761 public keys are fit into a single > 1500 bytes IKE message, they leave relatively little space for SA payload, so initiator may be limited in > expressing its proposals. > > > We then propose to restrict the use of large key exchanges to the > > context of option 3, which removes the risk of the described DoS > > attacks. Yet, to prevent the insecurities of plain option 3, we also propose to make it mandatory to combine > it with the new hybrid transform type, i.e., SNTRUP761X25519. > > Are you proposing to stick with these two particular algorithms? > I don't think it's a good idea, giving the algorithm agility requirements. > I think that the same result can be achieved with the current draft: > > IKE_SA_INIT(X25519 or whatever else) > IKE_INTERMEDIATE(SNTRUP761 or whatever else with small public key) IKE_AUTH(Childless if you want) > CREATE_CHILD_SA+IKE_FOLLOWUP_KE(McEliece or whatever else with long public key) > > This leaves much more flexibility in selecting particular algorithms. > > > The only downside of this approach is that G-IKE is then incompatible > > with the McEliece exchange. However, the fact that G-IKE exchanges > > sensitive information before authentication makes it impossible to be > > not vulnerable against the discussed DoS attack and, at the same time, support the McEliece algorithm. > Thus, we see that as a decision to be made in the G-IKE standardization track, not in IKEv2. > > I agree that G-IKEv2 is very special, but I also agree with Tero's previous message that protecting IKEv2 and > (G-IKEv2 too) against DoS attacks leaves in slightly different area. > We have some mechanisms for this (not perfect, but that is that). > > Regards, > Valery. > > > Regards, > > > > Stefan-Lukas Gazdag, Daniel Herzinger > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > ________________________________ > PQ Solutions Limited (trading as 'Post-Quantum') is a private limited company incorporated in England and > Wales with registered number 06808505. > > This email is meant only for the intended recipient. If you have received this email in error, any review, use, > dissemination, distribution, or copying of this email is strictly prohibited. Please notify us immediately of the > error by return email and please delete this message from your system. Thank you in advance for your > cooperation. > > For more information about Post-Quantum, please visit www.post-quantum.com quantum.com>. > > In the course of our business relationship, we may collect, store and transfer information about you. Please > see our privacy notice at www.post-quantum.com/privacy-notice notice> to learn about how we use this information. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Oct 29 01:35:14 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF973A0DE6 for ; Fri, 29 Oct 2021 01:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pjn8oTJ3Cl87 for ; Fri, 29 Oct 2021 01:35:07 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 150C23A0DEB for ; Fri, 29 Oct 2021 01:35:07 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id u5so15637927ljo.8 for ; Fri, 29 Oct 2021 01:35:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=TcYyHH8fJWiVSRFLO1URLlYUpbEKQdz4rTibW66xNhg=; b=fmegdZKuAky5tgjPxZDUhBuuOX9sFQyGBzy17RySkRAbCMxMXcCuEn8xBTHoMgxG80 whrAk35u6oZqduTcVbUtOQuGcEobw+kZ+zwsY9xZPSLpPD8tJd8gXLG/rRA0HrO28yWw 8y2mKt62gwyUR0ifEmkDPjEU+DXu7ujvPqcDn4KtTpt5U58XfiG1QjZD9lPx5KS94ALL EB9yeY+VOLnIOgJqJxNscuhCwGG9/7T069bdaBMPvWP1kamrzTCEyEuQhj+n647Cofot fC9E8wE0upVh5AfD37894eUU5Px72iRNnSOCTkg0ddEoG/phkdAf4EJAIyy4iPrSP3zo c2nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:content-language :thread-index; bh=TcYyHH8fJWiVSRFLO1URLlYUpbEKQdz4rTibW66xNhg=; b=xCKJlhNjSjP+zkNlgrMMelvXcivJcPhCPfBlIZ3KyRoR+cA3lFdPiQqTuE+KZsVgZv L/5X2poeeoHkkL7WWcDI0A/eBrUb4UfZesrMoG9ggRd0IsH7yYNKemGICCY9DNQIjTYe jPp8YDTrLjg1YJ45TudMaN0X05oNgaU/5+BGQrZIB8KOEyaVlQEVHx6Yq3TeZqk9b7gE kDc5MkveLlZ9dgkKPoTaC0Z93ZxJhZ1JJMIHQkLfoGuvDv0RFHVOsp8BO5vQmSDEEX+h eNJtS9gvPfHglSuRTTfKrD5PDyZOLaif/2covoM1+EY44ah5C6913Z+2s3xmor/kl5DN Jdtg== X-Gm-Message-State: AOAM533zwGPcbRQASEzBIDP/lYDpHhb7GxcXoiBjO6/kSlDLs0omwoC3 snyPUqO5UGjjZ/pulc1wufo= X-Google-Smtp-Source: ABdhPJzf+pyE6+5AFZAAbpiWrVev5hirSPQIFnG3Q3TIs1n1Q9MA9RLJsxokpwMyKRnvq1MyNu0P8w== X-Received: by 2002:a2e:3e16:: with SMTP id l22mr10706800lja.210.1635496504247; Fri, 29 Oct 2021 01:35:04 -0700 (PDT) Received: from buildpc ([93.188.44.204]) by smtp.gmail.com with ESMTPSA id f8sm547123lfu.5.2021.10.29.01.35.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Oct 2021 01:35:03 -0700 (PDT) From: "Valery Smyslov" To: "'Daniel Herzinger'" , "'CJ Tjhai'" , "'Kampanakis, Panos'" Cc: , References: <935923623769463b80caf7b64bfe430a@genua.de> <07a701d7c500$5c3fdcc0$14bf9640$@gmail.com> <994547d5af7a47b2b4819136af4b29fd@EX13D01ANC003.ant.amazon.com>, <4d3d0181b23048bb9b57f1c97672c1ea@genua.de> In-Reply-To: <4d3d0181b23048bb9b57f1c97672c1ea@genua.de> Date: Fri, 29 Oct 2021 11:35:06 +0300 Message-ID: <057f01d7cc9f$e0c963c0$a25c2b40$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: ru Thread-Index: AQLlmXEscoeqGnTi+siCjM6VrsV64gGhG0EwAmmdx6wCK2jCQAElDJVwqZMqNDA= Archived-At: Subject: Re: [IPsec] Cost-efficient quantum-resistant DoS protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2021 08:35:13 -0000 Hi Stefan, Daniel, > Hi, > > the fact is that accepting a significantly increased amount of data from an unauthenticated peer also > significantly increases the surface to DoS attacks. Even without surpassing the 64KB limit, this must be a > concern. IKEv2's cookie mechanism and puzzles try to increase the cost of the attacker per each connection. > Now, an attacker must still accept these costs but can use one connection to trigger several key exchanges, all > significantly larger than what we had with DH, making the trade-off way better for them compared to non-pqc > IKEv2. So, the attacker could, e.g., negotiate several FrodoKEMs (all with different parameters to circumvent > the rule that all key exchange methods must be different). Compared to classical non-hybrid (EC)DH, such a > DoS attack requires significantly less cost to have the same effect. > The introduction of MB-sized key exchanges just amplifies this problem even further (also allowing several > McEliece KEMs with different parameters circumventing this constraint). As I've already said, the responder is free to limit the types and the number of key exchanges it is willing to accept from unauthenticated initiator. > Thus, while we should already > thoroughly asses and mitigate the risk of this possible weakness for https://datatracker.ietf.org/doc/draft- > ietf-ipsecme-ikev2-multiple-ke/, we definitely must do it for https://datatracker.ietf.org/doc/draft-tjhai-ikev2- > beyond-64k-limit/. > Currently, there is no place defined where a McEliece-sized key exchange can take place. So, at least one of > the two drafts (probably beyond-64k or multiple-ke) or better both should make this clear. At the moment, > beyond-64k defines how the transmission of such key exchanges could look like but the question of where > these ideas could be put into action are left to the reader, leading to inevitable confusion. The fact that there > are several drafts aiming at the same problem, without really defining their contact points or interactions, > further exacerbates this. Sorry, I failed to understand why you think there is no contact points or interactions. Actually, beyond-64k is using multiple-ke and only defines how we can overcome 64KB payload size limit. > The most obvious way to prevent an attacker from exploiting the new attack surface is to accept the larger > key exchanges only from an already authenticated peer. As mentioned before, we think childless IKEv2 with > immediate rekeying would be a good compromise to achieve that. This is one possible solution. I don't think we should make it the only one. And I think this scenario is already described in multiple-ke. > > Imo, McEliece is not practical for live protocols like TLS or IKEv2. > McEliece is more trusted than its pqc alternatives which also makes it the favored choice of some agencies like > the German BSI. Obviously, they all know the challenges of integrating such large key exchanges, still they > would surely appreciate any effort which goes into this direction. This justifies pursuing the idea further, > especially since first measurements look better than one would probably expect. > To give more insight about these measurements, we implemented all three drafts and tested the performance > of a medium-sized McEliece key exchange under different networking conditions (variable latency, packet loss, > and throughput). Especially when packet loss or throughput surpass specific threshholds (~ above 1% packet > loss and below 3Mbit of throughput), the overall performance suffers significantly. Yet, we deem those values > acceptable, as long as we don't use cellular or similarly unreliable networks. Furthermore, we expect a > gateway communicating with many peers to have higher requirements to its network uplink. Yet, as this will > most likely be positioned in a data center, this challenge should also be doable. Altogether, this left us with a > surprisingly positive view on the possibility of adopting McEliece-sized key exchanges at least for some use- > cases. In cases when the packet loss is high it is possible to use mixed transport mode, defined in beyond-64K. > The introduction of new Transform-IDs like SNTRUP761X25519 is a good short-term solution, as it addresses > the problem without requiring much effort in terms of standardization or implementation. This becomes even > more important, as intermediate exchanges and their high complexity, due to their interconnectedness with > authentication, mean that especially the IKEv2 implementations of smaller projects will take their time for its > integration. Thus, having an easier short-term solution at hand means a real advantage. I think that defining new Transform-IDs like SNTRUP761X25519 is orthogonal to multiple-ke and beyond-64K. There are some advantages in using this combined key exchange mode, there are some disadvantages too. For example, the agility property is degraded, since you cannot negotiate which hash function to use when shared secrets are combined (well, this can be solved if you simply concatenate them, but it is a question for cryptographers how to do it right). > Also, the constrained size of such transforms mostly eliminates the aforementioned DoS risks. > Finally, should the beyond-64k draft be adopted, then having a small set of such additional Tranform-IDs is > even more beneficial since it makes preventing the unlikely yet possible attack described in our initial mail > easier. In my opinion you can also get most of the advantages by using IKE_SA_INIT(X25519)+IKE_INTERMEDIATE(SNTRUP761) instead. Well, in this case you have to implement IKE_INTERMEDITE (which you seem to think is too complex) and you have to do additional round trip. On the other hand, you are more flexible in choosing which classic and PQ KE methods to combine and how (e.g. you can also do IKE_SA_INIT(SNTRUP761)+IKE_INTERMEDIATE(X25519)). Regards, Valery. > > > Regards, > Stefan and Daniel > ________________________________________ > Von: CJ Tjhai > Gesendet: Donnerstag, 21. Oktober 2021 18:39:16 > An: Kampanakis, Panos > Cc: Valery Smyslov; Daniel Herzinger; ipsec@ietf.org; ietf@gazdag.de > Betreff: Re: [IPsec] Cost-efficient quantum-resistant DoS protection > > Hi Panos, > > There are two drafts involved here. > > a) the main draft, https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-multiple-ke/, cannot support any > public-key larger than 64KB, so it can never be used for KEMs like McEliece. So the option 3 is implied here. > > b) on the other hand, https://datatracker.ietf.org/doc/draft-tjhai-ikev2-beyond-64k-limit/ is an attempt to > address the issue with transferring payload larger than 64KB. As you pointed out, transferring large blob of > data in a live protocol is challenging and therefore it deservers separate treatments and considerations. It was > deliberate that we split the hybrid key exchange drafts into two, the second draft is there just in case there is > any interest in the working group on supporting the use KEMs like McEliece. > > Cheers, > CJ > > > > > On Thu, 21 Oct 2021 at 16:49, Kampanakis, Panos > > wrote: > Hi Valery, Tero, > > > Not really. First, the situation with seven McEliece is not possible, since all negotiated Key Exchange > methods MUST be different. > Then, you seem to assume that the responder blindly accepts all the key exchanges at the initiator's will. > This is not true. First peers negotiate which key exchanges they will perform (including additional key > exchanges), and you can limit the types and the number additional key exchanges the responder will accept > via its local policy. > > I think the point is valid though if the responder supports McEliece. A miscreant can that way make the > responder put a lot of data on the wire like an amplification attack although the initiator has not been > validated. QUIC has a 3x amplification protection limits for that matter. > > Sure, the issue existed even in ECDH exchanges, but the impact is much higher when we talk MB of public > keys. > > Imo, McEliece is not practical for live protocols like TLS or IKEv2. Too many packets mean pretty high loss > probability in unstable networks which means pretty bad performance unless everything happens in the > datacenter or robust end-to-end network paths. The PQ KEMs that will end up being standardized are likely to > have just a few KBs of public key and ciphertext which is better for the general case. > > So, I would say option 3 (prohibit the use of very large KE payloads like McEliece's MB sized public keys) is > more practical. > > Rgs, > Panos > > > > > > -----Original Message----- > From: IPsec > On Behalf Of Valery Smyslov > Sent: Tuesday, October 19, 2021 11:46 AM > To: 'Daniel Herzinger' >; > ipsec@ietf.org > Cc: ietf@gazdag.de > Subject: RE: [EXTERNAL] [IPsec] Cost-efficient quantum-resistant DoS protection > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments > unless you can confirm the sender and know the content is safe. > > > > Hi Daniel and Stefan-Lukas, > > > Hi, > > > > in response to the new version of > > draft-ietf-ipsecme-ikev2-multiple-ke-04.txt, we wanted to emphasize > > the issue of DoS attacks during intermediate exchanges. The new > > version does address it by mentioning the option of simply avoiding > > intermediate exchanges altogether but still require additional key > > exchanges. Yet, this protects only against record-and-harvest attacks > > but not against an attacker with a strong quantum computer at the time > > of the handshake, regardless of quantum-resistant authentication > > (since they can break the initial shared secret and therefore > > recalculate the MAC which authenticates the followup exchanges, fully > > establishing a man-in-the-middle). We doubt that an attacker, even with a strong quantum computer, is > able to break a key exchange in such a short time period. Still, this assumption is too theoretical to rely on. > This, together with the fact that Group-IKE is incompatible with key exchanges during followup exchanges, > makes the option seem inferior to just sticking to intermediate exchanges during the handshake. However, we > must also consider the draft-tjhai-ikev2-beyond-64k-limit-01.txt. > > An attacker who exploits the large key exchanges, e.g., by requesting > > seven additional maximum size McEliece key exchanges, can force a gateway to accept and process 1.4MB > of data per McEliece KEM. > > Not really. First, the situation with seven McEliece is not possible, since all negotiated Key Exchange methods > MUST be different. > Then, you seem to assume that the responder blindly accepts all the key exchanges at the initiator's will. > This is not true. First peers negotiate which key exchanges they will perform (including additional key > exchanges), and you can limit the types and the number additional key exchanges the responder will accept > via its local policy. > > > This leaves us at > > a situation where we must pick one of the following options: > > > > 1. Accept the highly increased risk of DoS attacks. > > 2. Prohibit the use of large KE payloads, hence the McEliece mechanism. > > 3. Prohibit the use of intermediate exchanges, leaving the IKE SA > > initially unprotected and being vulnerable to an attacker with a quantum computer during the handshake. > > > > To us, none of these options seems desirable. Thus, we propose another > > solution which sees one new transform type, e.g., SNTRUP761X25519, > > which then defines a combination of one classical algorithm (like > > I'm confused here - did you mean new transform type or new transform ID? > Transform types define a kind of algorithms (or other features, like ESN), while transform IDs define a > particular algorithm of this type. > > Unless I'm missing something I presume you meant new transform ID which defines a new key exchange > algorithm which is a combination of SNTRUP761 and X25519. > Correct me if I'm wrong. > > > ECDH based on curve25519) and one pqc algorithm which fits into > > IKE_SA_INIT without fragmentation (like sntruprime761). The two > > secrets get concatinated and then fed to a hash function. The > > resulting hash is used as the shared secret for further key > > derivation. This mechanism is low effort in terms of implementation > > and does not affect the state machine at all, but already offers a > > high level of protection against all attacks as long as there is no major break-through in cryptanalysis. > Furthermore, it is the accepted approach for most of the applications of post-quantum key exchanges. For > higher long-term security, it can be combined with other, more conventional algorithms which follow either in > intermediate or followup exchanges. > > I think that this combined key exchange algorithm can also be implemented (with more flexibility) by doing > IKE_SA_INIT(X25519)+IKE_INTERMEDIATE(SNTRUP761). I don't think your approach has real advantages in > terms of consuming responder's resources. The responder still needs to perform both X25519 and > SNTRUP761 before it authenticates the initiator. > Yes, you save one round trip, but the amount of data sent on the wire and the amount of CPU cycles are > roughly the same. I'd like also mention that while X25519 and SNTRUP761 public keys are fit into a single > 1500 bytes IKE message, they leave relatively little space for SA payload, so initiator may be limited in > expressing its proposals. > > > We then propose to restrict the use of large key exchanges to the > > context of option 3, which removes the risk of the described DoS > > attacks. Yet, to prevent the insecurities of plain option 3, we also propose to make it mandatory to combine > it with the new hybrid transform type, i.e., SNTRUP761X25519. > > Are you proposing to stick with these two particular algorithms? > I don't think it's a good idea, giving the algorithm agility requirements. > I think that the same result can be achieved with the current draft: > > IKE_SA_INIT(X25519 or whatever else) > IKE_INTERMEDIATE(SNTRUP761 or whatever else with small public key) IKE_AUTH(Childless if you want) > CREATE_CHILD_SA+IKE_FOLLOWUP_KE(McEliece or whatever else with long public key) > > This leaves much more flexibility in selecting particular algorithms. > > > The only downside of this approach is that G-IKE is then incompatible > > with the McEliece exchange. However, the fact that G-IKE exchanges > > sensitive information before authentication makes it impossible to be > > not vulnerable against the discussed DoS attack and, at the same time, support the McEliece algorithm. > Thus, we see that as a decision to be made in the G-IKE standardization track, not in IKEv2. > > I agree that G-IKEv2 is very special, but I also agree with Tero's previous message that protecting IKEv2 and > (G-IKEv2 too) against DoS attacks leaves in slightly different area. > We have some mechanisms for this (not perfect, but that is that). > > Regards, > Valery. > > > Regards, > > > > Stefan-Lukas Gazdag, Daniel Herzinger > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > ________________________________ > PQ Solutions Limited (trading as 'Post-Quantum') is a private limited company incorporated in England and > Wales with registered number 06808505. > > This email is meant only for the intended recipient. If you have received this email in error, any review, use, > dissemination, distribution, or copying of this email is strictly prohibited. Please notify us immediately of the > error by return email and please delete this message from your system. Thank you in advance for your > cooperation. > > For more information about Post-Quantum, please visit www.post-quantum.com quantum.com>. > > In the course of our business relationship, we may collect, store and transfer information about you. Please > see our privacy notice at www.post-quantum.com/privacy-notice notice> to learn about how we use this information. From nobody Fri Oct 29 12:37:56 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4C2D3A1639 for ; Fri, 29 Oct 2021 12:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.429 X-Spam-Level: X-Spam-Status: No, score=-5.429 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, NICE_REPLY_A=-3.33, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXZFuNLhIo-6 for ; Fri, 29 Oct 2021 12:37:50 -0700 (PDT) Received: from meesny.iki.fi (meesny.iki.fi [195.140.195.201]) (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 23A9E3A1638 for ; Fri, 29 Oct 2021 12:37:50 -0700 (PDT) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (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) (Authenticated sender: kivinen@iki.fi) by meesny.iki.fi (Postfix) with ESMTPSA id 2836A202DB; Fri, 29 Oct 2021 22:37:40 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1635536260; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=S8/VYs+Xe23r1DMrEm4Wc82HLtT0rN3ds+1Dxk2ZJRY=; b=pVQvPvZEtOtpHfnilKzHLLJuVd92//4Knlun2oQaXQoKNPM6I/qvIB2bNCZvxAkzF2hAn7 1LFFHNfSIKdYHA6ZfOT2IpwV1IMHBf9BHHE4GLoODYX7WQcElVs6Ize0Mrg49ncRbIe6+s m5K0kOvZbmitYXGD7FTdVBF54kiKKIg= Received: by fireball.acr.fi (Postfix, from userid 15204) id 7963A25C12DC; Fri, 29 Oct 2021 22:37:39 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24956.19843.441109.862288@fireball.acr.fi> Date: Fri, 29 Oct 2021 22:37:39 +0300 From: Tero Kivinen To: Daniel Herzinger Cc: CJ Tjhai , "Kampanakis\, Panos" , "ipsec\@ietf.org" , Valery Smyslov , "ietf\@gazdag.de" In-Reply-To: <4d3d0181b23048bb9b57f1c97672c1ea@genua.de> References: <935923623769463b80caf7b64bfe430a@genua.de> <07a701d7c500$5c3fdcc0$14bf9640$@gmail.com> <994547d5af7a47b2b4819136af4b29fd@EX13D01ANC003.ant.amazon.com> <4d3d0181b23048bb9b57f1c97672c1ea@genua.de> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 31 min X-Total-Time: 31 min ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen@iki.fi smtp.mailfrom=kivinen@iki.fi ARC-Seal: i=1; s=meesny; d=iki.fi; t=1635536260; a=rsa-sha256; cv=none; b=utu6MEascFpX+pnthmBwEnSA2HEo3MRwO2dogZhJfUQVqzHsmIZs6B6UvfdcZqbLA6hKm2 sRgF7X7HutdpXPHTbksCnmx1i5OsRHHz5bKIoTPqpzNHlwDVE4pzCQi+3pF/r+1Dtxabyf Rkp9gOZ0EJ1oo1EgzjxAauYSVrZUS6g= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1635536260; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=S8/VYs+Xe23r1DMrEm4Wc82HLtT0rN3ds+1Dxk2ZJRY=; b=Xlq/ZHUlRuagHKoayTJBshUA0ayt1uONY0FcA8dJCnfXPUJdvn/l9R9JfhUAMo/+UWC21q J0Xo1P7f+jva5RIXrutBL9YrR3UEHDZymhcSOvqbN1XuM8I8Gtbrxwm8+WsD9h0RJd+z64 kZWQQ1ps8pR9Ot0qzGzUuMLMtcRVlBc= Archived-At: Subject: Re: [IPsec] Cost-efficient quantum-resistant DoS protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2021 19:37:55 -0000 Daniel Herzinger writes: > the fact is that accepting a significantly increased amount of data > from an unauthenticated peer also significantly increases the > surface to DoS attacks. Accepting data is not a DoS attack problem. If the other end sends you lots of packets, you will have to cope with that, there is nothing you can do to limit it sending you data. Sending data back is where we might get DoS amplification factor, but what the amplification factor is depends on the size of packets initiator sends you and what is size of packets you send back. With normal Diffie-Hellman those both are same, so there is no amplification factor. Also amplification factor is really important only when you can do it as (D)DoS attack against third party. I.e., you use source attack of the intended victim on your message and send the message to some real server on the network who will send bigger reply back to the victim, not to the attacker. If the attacker can send small packet and get much bigger packet back then he gains amplification and he is better of using this kind of reflected attack instead of sending packets to victim himself. Of course if he can use lots of reflectors on the network he can do even better, i.e., make a DDoS attack... In IKEv2 this is only possible with the IKE_SA_INIT, because all later packets do require you to be on the path to see the response packets from the server to victim to be able to continue exchange. In the IKEv2 we do have protection against that, so the responders IKE_SA_INIT response is usually smaller than the request from the initiator. The SA payload will be either same or smaller, nonce payloads can be bit different lengths, but they are limited to 64 bytes, KE payloads are of same size, optional CERTREQ from the server is usually only few hashes thus few tens of bytes. Also the initiator usually adds several notify payloads and responder only reflects back those it supports. And if responder decideds to send back cookie request, to verify the source address of the initiator, then the response packet is much smaller. > Even without surpassing the 64KB limit, this must be a concern. > IKEv2's cookie mechanism and puzzles try to increase the cost of the > attacker per each connection. Now, an attacker must still accept > these costs but can use one connection to trigger several key > exchanges, all significantly larger than what we had with DH, making > the trade-off way better for them compared to non-pqc IKEv2. No it cannot. Attacker can use cookie only once, and will only get one exchange created by each cookie exchange, thus it needs to do puzzles and cookies again for every single attack packet it wants to send. Immediately when he sends the packet after the IKE_SA_INIT (i.e., IKE_AUTH or IKE_INTERMEDIATE) the SPIi is consumed, thus if he tries to send another IKE_AUTH/IKE_INTERMEDIATE with same SPIi the responder will assume it is just retransmission of the previous IKE_AUTH/IKE_INTERMEDIATE (if it is identical than last time) and then it will retransmit its response from last time. If the attacker modifies the IKE_AUTH/IKE_INTERMEDIATE request it sends, the initiator will ignore it as it is not retransmission and it is not valid message to the existing IKE SA. And to be able to send valid IKE_AUTH/IKE_INTERMEDIATE that will cause any action on the initiator will again require the attacker to be on path i.e., be somewhere where it can see the IKE_SA_INIT response the initiator sent, thus attacker in a position where it can do much more harm than simple DoS using reflection attack. So I do not think DoS attack properties of the IKEv2 is at all modified with addition to the multiple ke, or beyond 64k limit drafts. > So, the attacker could, e.g., negotiate several FrodoKEMs (all with > different parameters to circumvent the rule that all key exchange > methods must be different). Compared to classical non-hybrid (EC)DH, > such a DoS attack requires significantly less cost to have the same > effect. Why should the responder accept such proposal? What benefits is there to do multiple FrodoKEMs with different parameters in normal case? I would assume responder would simply pick one of the FrodoKEMs with the parameters that match its security requirements, and only use that, and if initiator does not offer a way to pick only one, the initiator will rejecte the whole proposal. The SAi and SAr exchange in the IKE_SA_INIT is a agreement protocol where initiator proposes list of algorithms, and responder picks suitable (sub)set of algorithms. Initiator of course only proposes algorithms that are acceptable for him based on his security policy, and responder will only pick algorithm sets which are acceptable for his security policy. > The introduction of MB-sized key exchanges just amplifies this > problem even further (also allowing several McEliece KEMs with > different parameters circumventing this constraint). I would assume most implementors do consider the constraint that each KEM must be different in a such way that parameters are not considered at all. I.e., even if you propose McEliece with multiple parameter sets, implementation will check its policy whether McEliece is acceptable, and if so then pick one of the parameter sets that match their security needs, and do not consider McEliece anymore for later rounds, i.e., it would not allow multiple McEliece with different parameter sets, because draft says you do not do same KEM multiple times. > Thus, while we > should already thoroughly asses and mitigate the risk of this > possible weakness for > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-multiple-ke/, > we definitely must do it for > https://datatracker.ietf.org/doc/draft-tjhai-ikev2-beyond-64k-limit/. Actually I do not think it belongs to them, it belongs to whatever draft that defines McEliece to be used with those two. Tha draft should note that there are issues using large keys in IKEv2, and most likely it should say SHOULD NOT do that using IKE_INTERMEDIATE, and only use the large keys after the IKE SA has been authenticated. > Currently, there is no place defined where a McEliece-sized key > exchange can take place. So, at least one of the two drafts > (probably beyond-64k or multiple-ke) or better both should make this > clear. At the moment, beyond-64k defines how the transmission of > such key exchanges could look like but the question of where these > ideas could be put into action are left to the reader, leading to > inevitable confusion. The fact that there are several drafts aiming > at the same problem, without really defining their contact points or > interactions, further exacerbates this. We do not have draft at all for McEliece where this kind of discussion belongs. > The most obvious way to prevent an attacker from exploiting the new > attack surface is to accept the larger key exchanges only from an > already authenticated peer. As mentioned before, we think childless > IKEv2 with immediate rekeying would be a good compromise to achieve > that. McEliece draft should most likely have strong recommendation to do just that. > The introduction of new Transform-IDs like SNTRUP761X25519 is a good > short-term solution, as it addresses the problem without requiring > much effort in terms of standardization or implementation. I think IKE_INTERMEDIATE is better solution, and you doing normal X25519 in IKE_SA_INIT and then SNTRUP761 in IKE_INTERMEDIATE will solve the issue with just one extra round trip, and still keep the IKE_SA_INIT packet small enough that it does not get fragmented (i.e., less than 1280). > This becomes even more important, as intermediate exchanges and > their high complexity, due to their interconnectedness with > authentication, mean that especially the IKEv2 implementations of > smaller projects will take their time for its integration. Thus, > having an easier short-term solution at hand means a real advantage. I do not think implementing IKE_INTERMEDIATE is that hard, especially if you limit yourself to just very limited subset of algorithms you support. > Also, the constrained size of such transforms mostly eliminates the > aforementioned DoS risks. I do not think there are any new DoS risks, so there is no need to eliminate them.... -- kivinen@iki.fi From nobody Sun Oct 31 11:36:49 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3124A3A1168 for ; Sun, 31 Oct 2021 11:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.43 X-Spam-Level: X-Spam-Status: No, score=-5.43 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, NICE_REPLY_A=-3.33, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2tI82jjYob3 for ; Sun, 31 Oct 2021 11:36:45 -0700 (PDT) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [IPv6:2a0b:5c81:1c1::37]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD8EF3A1167 for ; Sun, 31 Oct 2021 11:36:45 -0700 (PDT) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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) (Authenticated sender: kivinen@iki.fi) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id AB4DC1B0007F; Sun, 31 Oct 2021 20:36:39 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1635705399; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4mAIqFyBLIV7fzhbcbfPtJ4cLrceympgU15IlgzznRM=; b=kU8nEZ3PBQH5RYFu5LYBMiiKeLseXbCgbL5hEel91RMsxnuikBgqlBEbRM+bT3Px2urE9N ODYm3MqtjZ+jSJgYg/ub9zERScfh8lsYDhG/tZ0upSbHUPLo1JiHI1d/Y9JrF2jUuWXEih s42Gwm7AxGqBFOe7/Nmin8V+uJYfBpRC1NkbQQBhGtDBFjC4/WjPoO9a1qu+bcu2fsCKF0 FU9kZTmN676b9NUg81g//4rJwxP41eI5O7Pju/sLUU9wU7BWCtoBsy0RSLCaVf7Wdzej5h W2x/CZjm98DieEywflwWGQM1xWzVQLv9SW90kCGV999OttCCuznplY8uHIt7PA== Received: by fireball.acr.fi (Postfix, from userid 15204) id 46A5A25C12C9; Sun, 31 Oct 2021 20:36:39 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24958.57911.229841.127408@fireball.acr.fi> Date: Sun, 31 Oct 2021 20:36:39 +0200 From: Tero Kivinen To: Christian Hopps Cc: Paul Wouters , "Koning\, Paul" , touch@strayalpha.com, ipsec@ietf.org In-Reply-To: References: <41C188CD-9B34-4FD9-A9B9-632C335253A4@chopps.org> <24858.42061.118149.546106@fireball.acr.fi> <24858.54291.205079.485517@fireball.acr.fi> <04158312-E6F2-4467-B435-58D77ED7435E@dell.com> <509B58FB-03A1-4C28-BE47-1E4A47478512@chopps.org> <24859.37908.612701.587580@fireball.acr.fi> <9BD66C9D-9E6C-4BEC-A71F-D74B667EA503@chopps.org> <8B9B2CB1-D470-45AD-9C9A-218FB3DBE811@chopps.org> <24859.55228.954532.765168@fireball.acr.fi> <24886.26315.915608.856404@fireball.acr.fi> <24886.30488.12451.378363@fireball.acr.fi> <3171E295-4AA1-49C2-9F27-1DD2BAC4D19A@chopps.org> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 23 min ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1635705399; a=rsa-sha256; cv=none; b=XsaYnNs46gWslEEubISfLYrNNQus47i+iX0LSZvxRTam/vDV5ceY6uAW+6hPb9Bjizc77j 1WjSCnaq6QwxzYFr9uiC9EHUPRSJeKPFMSTnq2NwUv8a9Rl3ARslvR0XD4XrG6+3WeZfq5 eC6qxmFdYre8O3hp2jdjowe0KZJf5etJ4pOEsN9koa71Um7zujfKvA3kp9VhUKCdVwgkU2 Tm11Dlnyg6XuUTnTFxAHm0obau71cDtFYN2t1hh206jRdI/3Vkbnw/BLq+dy1PGHJiSRDS hxxrbjm770kLo70zPZQHPAEjnTc5eVvM700zro1klKx8bxZMGIEMvoSz5vcVvg== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen@iki.fi smtp.mailfrom=kivinen@iki.fi ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1635705399; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4mAIqFyBLIV7fzhbcbfPtJ4cLrceympgU15IlgzznRM=; b=uC+6k38Lmq4/Sg5pvN2b5EROuM2F1V7xfAbe/PH8xQiLfMAGciHGkWymGnbL8jo3OXcnBT GPuaqymWcu3bzRMXpq61hfzIoxE9SQo/30qFXkQpXhH3HLE8+AVN9atg2bHl7A1aWJh77G qfa1rvmcEjXyywnB1npijHeUcYnLArky7bdRMWiIa7l7oSXzG5C16RSvCRhUXqZgljsO4h kqJ7CjGY+bxbyzArToFWaaydCkmuU3qsh6cavnaOvo1nxFTEPme9b+7er7yLHLVx5A+TJW QTpy2tQZ1eIY6oUgUe9d5eqeY84F6qUdt7o7so5L54gCZgSJbjIp0YmEJdjwTw== Archived-At: Subject: Re: [IPsec] iptfs publication request X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2021 18:36:48 -0000 Christian Hopps writes: > Will you be able to provide the text changes that would cover the > issue you have? Would really like to get this submitted to IESG > before another IETF cycle completes. How about following: ---------------------------------------------------------------------- 2.5. Summary of Receiver Processing An AGGFRAG enabled SA receiver has a few tasks to perform. The receiver SHOULD process incoming AGGFRAG_PAYLOAD payloads as soon as they arrive as much as it can. I.e., if the incoming AGGFRAG_PAYLOAD packet contains complete inner packet(s), receiver should extract them and forward them immediately. For partial packets the receiver needs to keep the partial packets in the memory until the they fall out from the reordering window, or until the missing parts of the packets is received, in which case it will reassemble them and send them out. If AGGFRAG_PAYLOAD payload contains multiple packets they SHOULD be sent out in the order they are in the AGGFRAG_PAYLOAD (i.e., keep the original order they were received on the other end). Instead of the method described in the previous paragraph the receiver MAY reorder out-of-order AGGFRAG_PAYLOAD payloads received into in-sequence-order AGGFRAG_PAYLOAD payloads (Section 2.2.3), and only after it has in-order AGGFRAG_PAYLOAD payload stream, receiver extracts the inner-packets. In this case the receiver considers a packet lost when it's sequence number is abandoned (e.g., pushed out of the re-ordering window, or timed-out) by the reordering algorithm. Using this methold will make sure the packets are sent in-order, i.e., there is no reordering possible, but the cost is that any lost packet will cause delay of full reorder window, and there will be extra burstiness in the output stream (when lost packet is dropped out from the re-order window, all outer packets received after that are then immediately processed, and sent out back to back). Additionally, if congestion control is enabled, the receiver sends congestion control data (Section 6.1.2) back to the sender as described in Section 2.4.2 and Section 3. ---------------------------------------------------------------------- I think that captured what I proposed long time ago to you in several emails, but now this is full section so it should be easier to incorporate than the earlier proposed separate sentences. -- kivinen@iki.fi From nobody Sun Oct 31 11:39:18 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA13B3A117A for ; Sun, 31 Oct 2021 11:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWBB1OHpP5dt for ; Sun, 31 Oct 2021 11:39:13 -0700 (PDT) Received: from meesny.iki.fi (meesny.iki.fi [IPv6:2001:67c:2b0:1c1::201]) (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 0686F3A1179 for ; Sun, 31 Oct 2021 11:39:13 -0700 (PDT) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (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) (Authenticated sender: kivinen@iki.fi) by meesny.iki.fi (Postfix) with ESMTPSA id E3564200CE for ; Sun, 31 Oct 2021 20:39:05 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1635705545; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=e3hs4GR2x16O+4PdsYqS8+cdTaKwI9nXwoom1EZAE6Q=; b=UizU83YZ5JwaXLevUJcCefxd7S7ls2o6z2myaZA/a60AOCILkgpyGCT2+3s9+dw6i7FDY+ ecGXmA/vcDWJAAEvgY/EblsCYtGWqVaVpgOa8/d+e49/WKSARyKksJ7+LhJyarSjcQdjO+ c0j2rR2atfxvJ6YbsYyasgYvnnQ7rNA= Received: by fireball.acr.fi (Postfix, from userid 15204) id 795C225C12C9; Sun, 31 Oct 2021 20:39:05 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24958.58057.463060.855475@fireball.acr.fi> Date: Sun, 31 Oct 2021 20:39:05 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 2 min X-Total-Time: 2 min ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen@iki.fi smtp.mailfrom=kivinen@iki.fi ARC-Seal: i=1; s=meesny; d=iki.fi; t=1635705545; a=rsa-sha256; cv=none; b=tD5BoIaBZTuBqodRbsPgGfqxgviOXJewL4PnPB5KrySV4Z/ii+HPBqYLcB3RY4/2E5xSW/ UMoCu59VcLGkurjG5ikzBFRt7mRXzPXqGrcSxTTYKKcFpMq60pJ6Ru3lX2elv4MGyTLU7Q hc+CqW1AKrmeWWBYOaAFgq8P3Whanps= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1635705545; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=e3hs4GR2x16O+4PdsYqS8+cdTaKwI9nXwoom1EZAE6Q=; b=Sinaa89uUx7OP+eKMM+16iEG/V5JmwRGVfQF96xhxfpq2tRwG81Q9SbeEW9u2fAp+9x5cy eADBYDFNOKylD4K9KQrQ3MPph34V0IeiMz/bo3SuDhzsX686H8IDX1qDRnJuL9tB6FIbdk CItiEj3j/jeVx3WO48yQfzwTIboRORk= Archived-At: Subject: [IPsec] IPsecME WG agenda requests for IETF 112 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2021 18:39:16 -0000 We will be meeting on Monday November 8th 12:00-14:00 UTC, so send me agenda request as soon as possible so we get the agenda ready soon. -- kivinen@iki.fi From nobody Sun Oct 31 12:05:07 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8763A11F5 for ; Sun, 31 Oct 2021 12:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id og8uzoa-x0j3 for ; Sun, 31 Oct 2021 12:05:00 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FEF23A11F2 for ; Sun, 31 Oct 2021 12:04:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id C0467181FB for ; Sun, 31 Oct 2021 15:06:20 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CKRDSXjaFG-b for ; Sun, 31 Oct 2021 15:06:19 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6E08718042 for ; Sun, 31 Oct 2021 15:06:19 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1905288 for ; Sun, 31 Oct 2021 15:04:57 -0400 (EDT) From: Michael Richardson To: "ipsec\@ietf.org" In-Reply-To: <24956.19843.441109.862288@fireball.acr.fi> References: <935923623769463b80caf7b64bfe430a@genua.de> <07a701d7c500$5c3fdcc0$14bf9640$@gmail.com> <994547d5af7a47b2b4819136af4b29fd@EX13D01ANC003.ant.amazon.com> <4d3d0181b23048bb9b57f1c97672c1ea@genua.de> <24956.19843.441109.862288@fireball.acr.fi> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] Cost-efficient quantum-resistant DoS protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2021 19:05:05 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Tero Kivinen wrote: >> Even without surpassing the 64KB limit, this must be a concern. >> IKEv2's cookie mechanism and puzzles try to increase the cost of the >> attacker per each connection. Now, an attacker must still accept >> these costs but can use one connection to trigger several key >> exchanges, all significantly larger than what we had with DH, making >> the trade-off way better for them compared to non-pqc IKEv2. > No it cannot. Attacker can use cookie only once, and will only get one > exchange created by each cookie exchange, thus it needs to do puzzles > and cookies again for every single attack packet it wants to send. I wonder if anyone has any stats on how often cookie challenge is used, how often puzzles are invoked. > So I do not think DoS attack properties of the IKEv2 is at all > modified with addition to the multiple ke, or beyond 64k limit drafts. I agree. IKEv2 is not SSLv3. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmF+6NgACgkQgItw+93Q 3WWzBgf/Rg3baarTEP0o8HUqUbPxf7K5RjTd3wdiZ6FYw/qJWgB/yXglIjOBsP9z XXeDaXEynUOYs/zJe9t5RYMmPDBMt4dZvj1P9aMfCt1W644z1JJ5M/zGZyyDvqNf aQAe9acuyqphGaRivg8AIX9d5MVx5ATUuemGIFfEiYzzvRgYKrTzIGOhesM61Jtd t7bRQAUTFl8nWWTOEQkOMbaqhcVzRXK7gOfq0RlptgyecMYRwjxHxCFClmGaihEm iMAVIqokwceikZbv8SeBKmG4RhFtxtdc8Ie2lzjwNcGy9WCEaRvAOZ4M6OyUJw40 uQr+fLqsyArJsaqKjxtT7HNl+YTL5g== =5mWt -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Oct 31 12:53:23 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF7053A13D2 for ; Sun, 31 Oct 2021 12:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5SYJLs3Zgit for ; Sun, 31 Oct 2021 12:53:12 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 421343A13C5 for ; Sun, 31 Oct 2021 12:53:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id CD44A18202; Sun, 31 Oct 2021 15:54:30 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mDS2Z2mhrAiX; Sun, 31 Oct 2021 15:54:29 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B2E0418028; Sun, 31 Oct 2021 15:54:29 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 547C388; Sun, 31 Oct 2021 15:53:07 -0400 (EDT) From: Michael Richardson To: Tero Kivinen cc: Christian Hopps , "Koning, Paul" , Paul Wouters , touch@strayalpha.com, ipsec@ietf.org In-Reply-To: <24958.57911.229841.127408@fireball.acr.fi> References: <41C188CD-9B34-4FD9-A9B9-632C335253A4@chopps.org> <24858.42061.118149.546106@fireball.acr.fi> <24858.54291.205079.485517@fireball.acr.fi> <04158312-E6F2-4467-B435-58D77ED7435E@dell.com> <509B58FB-03A1-4C28-BE47-1E4A47478512@chopps.org> <24859.37908.612701.587580@fireball.acr.fi> <9BD66C9D-9E6C-4BEC-A71F-D74B667EA503@chopps.org> <8B9B2CB1-D470-45AD-9C9A-218FB3DBE811@chopps.org> <24859.55228.954532.765168@fireball.acr.fi> <24886.26315.915608.856404@fireball.acr.fi> <24886.30488.12451.378363@fireball.acr.fi> <3171E295-4AA1-49C2-9F27-1DD2BAC4D19A@chopps.org> <24958.57911.229841.127408@fireball.acr.fi> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Date: Sun, 31 Oct 2021 15:53:07 -0400 Message-ID: <8181.1635709987@localhost> Archived-At: Subject: Re: [IPsec] iptfs publication request X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2021 19:53:22 -0000 Tero Kivinen wrote: > Christian Hopps writes: >> Will you be able to provide the text changes that would cover the >> issue you have? Would really like to get this submitted to IESG >> before another IETF cycle completes. > How about following: works for me. From nobody Sun Oct 31 14:38:29 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEFD3A09E8 for ; Sun, 31 Oct 2021 14:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwlA_rI6qnkC for ; Sun, 31 Oct 2021 14:38:22 -0700 (PDT) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D1F93A09E7 for ; Sun, 31 Oct 2021 14:38:22 -0700 (PDT) Received: by mail-ua1-x92e.google.com with SMTP id i6so14315202uae.6 for ; Sun, 31 Oct 2021 14:38:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gbvNChv9adUfe54RSw7nTMyVqtkQE+gNqE7WuCT5Oio=; b=Ljq5MZ9j6sI9A2Jcl90Lj1rXiLEVloaFAwylnPS5uhPSBKNBc0QxSMWFl7HdzRjKWQ vXAl1xYdWR6zgWNk4D834bIBi7hbLiUXa1nRrbyn2PCbCtLoBLjj5XZWMIkaxBhAdKyf LM2+w3nYmtJZ7y+ZR5EqZAKJnJFS57ysF+Q+sNby0BG3CZd2EqqVmxZuRxFrEG+QDdYA qFLN5CLBdRPZ2cNJvbr0Wqf6BERZXhlRM+dckWbP3FWw1ClkUFhD2WRQhU+n6KspRQ+q tSNMQ1+0OSZmy7CNM2XrENpCup2RRMd5WGurGBMvXRLl5tVr1MRH1b2qL6jYlYx7mVaw 5zFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gbvNChv9adUfe54RSw7nTMyVqtkQE+gNqE7WuCT5Oio=; b=2suT2i2zDQYtBVSbB9GacV49hX3WW26ge69GDN5er3AAWvQ2WbJ5TthDgurNVEwBzo Q1Ye5uIHWBZtbDt+TvaU0CfoBVx/7ig5D+5FYgBPo0Wra7RQDfkbzF04fW8MrHCc69wv OofL52eJlz3oZzBQ4DZAR75DCqRThGNwP72IRLf4GPk0/vCmRxB6sp/cCv215G8GtwTa f3CJCwBn9veguCcWiM7LychsbkY8qcdKi7tLY++nIEY2LSMZ9lymd24o8cpO3kPZrrN4 fhT+Ir283WVyUXq+fe78ukM8EQglGJSRfd4sh7dxzkbCDqg/yEmA9tosDbnpw6YAvpOR sMjA== X-Gm-Message-State: AOAM531XeNDjfmGIOb5yxGDEQVWuMPqIY+qzTmvMJOgntuxZ6kaX15/3 XIf56VNVzyoy99/efcRE3u9vZvJNj6cejpzjn41dhxCW X-Google-Smtp-Source: ABdhPJwiJbiwBodBbcrcIMKfmU06BeKzj9LLcU1vpkrradDDVadS421Jdj0lI3Fqf9e8TNwLldbXW5tappVylZwSN9o= X-Received: by 2002:ab0:14a7:: with SMTP id d36mr24845015uae.96.1635716298678; Sun, 31 Oct 2021 14:38:18 -0700 (PDT) MIME-Version: 1.0 References: <935923623769463b80caf7b64bfe430a@genua.de> <07a701d7c500$5c3fdcc0$14bf9640$@gmail.com> <994547d5af7a47b2b4819136af4b29fd@EX13D01ANC003.ant.amazon.com> <4d3d0181b23048bb9b57f1c97672c1ea@genua.de> <24956.19843.441109.862288@fireball.acr.fi> <27139.1635707097@localhost> In-Reply-To: <27139.1635707097@localhost> From: Graham Bartlett Date: Sun, 31 Oct 2021 21:38:07 +0000 Message-ID: To: Michael Richardson Cc: "ipsec@ietf.org" Content-Type: multipart/alternative; boundary="000000000000efa64a05cface096" Archived-At: Subject: Re: [IPsec] Cost-efficient quantum-resistant DoS protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2021 21:38:27 -0000 --000000000000efa64a05cface096 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi I'm not aware of any IKEv2 implementations that use puzzles. I probably see cookies enabled in maybe 5% to 10% of deployments. On Cisco, the cookie can be enabled if X number of 1/2 open sessions are seen, hence it might not be active unless there is either some anomaly in the network (GW reboot and all clients connecting at the same time), or DoS attack (never seen in real life). cheers On Sun, Oct 31, 2021 at 7:05 PM Michael Richardson wrote: > > Tero Kivinen wrote: > >> Even without surpassing the 64KB limit, this must be a concern. > >> IKEv2's cookie mechanism and puzzles try to increase the cost of t= he > >> attacker per each connection. Now, an attacker must still accept > >> these costs but can use one connection to trigger several key > >> exchanges, all significantly larger than what we had with DH, maki= ng > >> the trade-off way better for them compared to non-pqc IKEv2. > > > No it cannot. Attacker can use cookie only once, and will only get > one > > exchange created by each cookie exchange, thus it needs to do puzzl= es > > and cookies again for every single attack packet it wants to send. > > I wonder if anyone has any stats on how often cookie challenge is used, h= ow > often puzzles are invoked. > > > So I do not think DoS attack properties of the IKEv2 is at all > > modified with addition to the multiple ke, or beyond 64k limit > drafts. > > I agree. > > IKEv2 is not SSLv3. > > -- > Michael Richardson . o O ( IPv6 I=C3=B8T consul= ting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --000000000000efa64a05cface096 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

I'm not aware of any = IKEv2 implementations that use puzzles.

I probably= see cookies enabled in maybe 5% to 10% of deployments. On Cisco, the cooki= e can be enabled if X number of 1/2 open sessions are seen, hence it might = not be active unless there is either some anomaly in the network (GW reboot= and all clients connecting at the same time), or DoS attack (never seen in= real life).

cheers

On Sun, Oct 31, 2021 at 7:0= 5 PM Michael Richardson <mcr+= ietf@sandelman.ca> wrote:

Tero Kivinen <kivine= n@iki.fi> wrote:
=C2=A0 =C2=A0 >> Even without surpassing the 64KB limit, this must be= a concern.
=C2=A0 =C2=A0 >> IKEv2's cookie mechanism and puzzles try to incr= ease the cost of the
=C2=A0 =C2=A0 >> attacker per each connection. Now, an attacker must = still accept
=C2=A0 =C2=A0 >> these costs but can use one connection to trigger se= veral key
=C2=A0 =C2=A0 >> exchanges, all significantly larger than what we had= with DH, making
=C2=A0 =C2=A0 >> the trade-off way better for them compared to non-pq= c IKEv2.

=C2=A0 =C2=A0 > No it cannot. Attacker can use cookie only once, and wil= l only get one
=C2=A0 =C2=A0 > exchange created by each cookie exchange, thus it needs = to do puzzles
=C2=A0 =C2=A0 > and cookies again for every single attack packet it want= s to send.

I wonder if anyone has any stats on how often cookie challenge is used, how=
often puzzles are invoked.

=C2=A0 =C2=A0 > So I do not think DoS attack properties of the IKEv2 is = at all
=C2=A0 =C2=A0 > modified with addition to the multiple ke, or beyond 64k= limit drafts.

I agree.

IKEv2 is not SSLv3.

--
Michael Richardson <mcr+IETF@sandelman.ca>=C2=A0 =C2=A0. o O ( IPv6 I=C3=B8T co= nsulting )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sandelman Software Works Inc, Otta= wa and Worldwide




_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--000000000000efa64a05cface096--