Re: [IPsec] AD review of draft-ietf-ipsecme-qr-ikev2-08

"Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com> Wed, 06 November 2019 16:42 UTC

Return-Path: <sfluhrer@cisco.com>
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 4BB87120089; Wed, 6 Nov 2019 08:42:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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=W+0wtzUl; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=qR+H7Nv1
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 Os8iGPmkclvC; Wed, 6 Nov 2019 08:42:31 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23BB8120071; Wed, 6 Nov 2019 08:42:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4850; q=dns/txt; s=iport; t=1573058551; x=1574268151; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=78N1WwIyOwPjrXMdn+cELaAQN1WfGnTJ2kZo6yyYhkI=; b=W+0wtzUln9v79LCRf17/p7SA6Q2p8q6rJr/fvSMeDJ4pE80xPZLxjG0T PQeGcsTHMTvB9SwP4Cvz4/DtN5+3CT9NFonQSuGrekBbUjEZ3KJQ+7zI0 rLHlMneLRfmgTZsA/zW9U87gMIBlaEC+yyzw3p7rY2RUJuiwSTPo8WgLM 0=;
IronPort-PHdr: 9a23:CTJ0mxTP1xqznb2r3th6aTuFqdpsv++ubAcI9poqja5Pea2//pPkeVbS/uhpkESXBNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH15g640NmhA4RsuMCEn1NvnvOjc0GNlCTlJ/13q6KkNSXs35Yg6arw==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AYAABf98Jd/4sNJK1lDg0BAQEBAQEBBQEBAREBAQMDAQEBgWoGAQEBCwGBSlAFgUQgBAsqh28DhFqGJIJel36BLhSBEANUCQEBAQwBAS0CAQGEQAKEDiQ0CQ4CAwsBAQQBAQECAQUEbYU3DIVRAQEBAQMSKAYBATcBCwQCAQgOAwQBAR8QMh0IAgQBDQUIEAqFRwMuAQKmXQKBOIhggieCfgEBBYUFGIIXCYE2AYlKdoFTGIFAP4ERRoFOfj6ELRqDQIIsrgQKgiSVV4I8h12PU45DmWQCBAIEBQIOAQEFgVI5N4EhcBWDJ1ARFIMGg3OKGDt0gSiQYgEB
X-IronPort-AV: E=Sophos;i="5.68,275,1569283200"; d="scan'208";a="365186525"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Nov 2019 16:42:30 +0000
Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id xA6GgUEJ030939 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Nov 2019 16:42:30 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 6 Nov 2019 10:42:29 -0600
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 6 Nov 2019 11:42:29 -0500
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 6 Nov 2019 10:42:28 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ImyIEnPMbAzIch90N1qHR7tqITqa7Ba/WYNO7XtbyP4FBA5gCz8grPqR6BG6LPAThOSxa72OGWvHPdvw1OTnGn14pJbS/8QKyZoRkLEXaIeezmqJ4U9iDQGCxP4BbO+jwWlExJZ10BfFDlC0nYhCCZbm51RcHeWYRxb1XVkk2dNVKSFAOasDXk0Xahlm/esAPRhKOhquroJaq8kxGfZGYV3d/653/GMc6hEBDQqp361bYbznFCF/AwQWijYicYPsptyBlGRIRFfvRcZD9xrjTfz3iESDV+8RVyvqTgaDQzOnIaa+L5v5pxqWyyz+/yj2ZE0vLHltrbX4+D7Fcr5WUA==
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-SenderADCheck; bh=VM907wVLO0mtQq7uWxVdDDwbyavaSYFVnzsEhr4L9Tw=; b=mJl7l22qeMUb4eM93cdwZoAK/Qn+ue6IL9jWxm18gmBXyYx+ImwPfldOpWaOm453SkhJvcUh4fTAmEm9CBqG0bhxEGJdBrvpiFHfmSPUhGskZZm0AHKGlxK6vmbyryfDBADjNb/zoLI8gUteZTCnDLT4yY69nwPv9WHrQU7v4d2rBJyDTO7XG69X3nSNdQLq1Snqa9GJF7Eb75EEbRU/BCaoZBkvsohVIb0FpOp5rxjoSV7IiJeAyvHlH9NwihLCx0spWw4FqD3FLoKO8fmbFM9LaEsh5mSSaTDRl8QWM5CuG61rJI2wQr1XOOl3FDUtQ8G8VoZTXmxQHUVzskH16g==
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=VM907wVLO0mtQq7uWxVdDDwbyavaSYFVnzsEhr4L9Tw=; b=qR+H7Nv1quRHLA7Fzw2+JleH56+4K03snV9cBDfq/sjhAvSAHjmteAYcbT+nQDL0EDtCP7NELy9Iec9LGalYY0VsXdl5LKbJf/iaFqiPdfL/uasGpH71cmdnl1zzQHpCwDXCspD4se0o4JEF4q6MhEQtq+1ktW8qtOyHKO4qRos=
Received: from BN8PR11MB3666.namprd11.prod.outlook.com (20.178.221.19) by BN8PR11MB3681.namprd11.prod.outlook.com (20.178.219.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.20; Wed, 6 Nov 2019 16:42:27 +0000
Received: from BN8PR11MB3666.namprd11.prod.outlook.com ([fe80::815c:974a:5eab:868b]) by BN8PR11MB3666.namprd11.prod.outlook.com ([fe80::815c:974a:5eab:868b%7]) with mapi id 15.20.2408.024; Wed, 6 Nov 2019 16:42:27 +0000
From: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>
To: Valery Smyslov <svan@elvis.ru>, 'Benjamin Kaduk' <kaduk@mit.edu>
CC: "draft-ietf-ipsecme-qr-ikev2.all@ietf.org" <draft-ietf-ipsecme-qr-ikev2.all@ietf.org>, "ipsec@ietf.org" <ipsec@ietf.org>
Thread-Topic: AD review of draft-ietf-ipsecme-qr-ikev2-08
Thread-Index: AQHVk4InqawYRzoDUUa9kWZivMLdT6d8oxOAgABdBYCAAMZgAIAAkWJw
Date: Wed, 06 Nov 2019 16:42:27 +0000
Message-ID: <BN8PR11MB3666417EBA2DDA0378D56D37C1790@BN8PR11MB3666.namprd11.prod.outlook.com>
References: <20191105023831.GH55993@kduck.mit.edu> <058d01d593e5$0be7eb80$23b7c280$@elvis.ru> <20191105195939.GH61969@kduck.mit.edu> <06dd01d59476$befb9c30$3cf2d490$@elvis.ru>
In-Reply-To: <06dd01d59476$befb9c30$3cf2d490$@elvis.ru>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=sfluhrer@cisco.com;
x-originating-ip: [2001:420:c0c8:1004::762]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0b29431c-20a2-4efa-73a6-08d762d84f18
x-ms-traffictypediagnostic: BN8PR11MB3681:
x-microsoft-antispam-prvs: <BN8PR11MB36814E69261DB56AC95410F7C1790@BN8PR11MB3681.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 02135EB356
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(396003)(39860400002)(366004)(376002)(136003)(13464003)(199004)(189003)(40154002)(66556008)(66946007)(5660300002)(6246003)(66476007)(305945005)(71190400001)(71200400001)(66446008)(64756008)(76116006)(54906003)(478600001)(99286004)(14444005)(316002)(256004)(52536014)(110136005)(14454004)(7736002)(25786009)(2906002)(446003)(6116002)(102836004)(8936002)(6436002)(46003)(81156014)(81166006)(7696005)(6506007)(53546011)(76176011)(33656002)(486006)(8676002)(476003)(55016002)(4326008)(11346002)(2171002)(74316002)(229853002)(86362001)(186003)(9686003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR11MB3681; H:BN8PR11MB3666.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: eIG7EmCGPJ0Qdfr85iNf7bL2TUwhXkUw8AnCVFk/xICBr98x33fSeUifSY6hX+hP4SPiZAQjYIyzJOb0bV/MRZfAQ/eVHXIUO+Q3Sv9XelvcZb1v7bA0cpecw4RlNoF0VLs2YAOGGKRnWRNaVhnPNL2+RLj2iVkfkTQ1oFz1D6Hqeka1j8zqmMI+Iat4omIvrrBizDldm49Pq53AYWmSK9iDaYMDywDsTThqT2HzSIv4cf0CKds1fJsn/MT2WcMjo9/Q+fAHMuZvP2wePVAvLVEN5fauh0RHPe1LEnN83SYDmHxu7FoigFii7LZhRz8G2zCxbKlSUqWBABy19J8JT2nLXI/es5kwk3jHWO8U9Jxf0wYufF3tWqx37Msz/HpPqHFeFMFWsbuS8HiyxnLZVv75mZXLyYyyvS4IuWsGtM5z9s6PWaYYkaA+BbaZXjqc
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 0b29431c-20a2-4efa-73a6-08d762d84f18
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2019 16:42:27.3666 (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: bxxoTW9jW1OLsXfQcx1IMlPG2D5FUbRdAN6HgyeEM80lRjrG10VoQuNLMW79jIlrXf90w0eG2aPHHIWCnrczIw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3681
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.27, xch-aln-017.cisco.com
X-Outbound-Node: alln-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/8AEgzGjqsDMTUy1X0IB4JWv_zlE>
Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-qr-ikev2-08
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Nov 2019 16:42:33 -0000

> -----Original Message-----
> From: Valery Smyslov <svan@elvis.ru>
> Sent: Wednesday, November 06, 2019 2:50 AM
> To: 'Benjamin Kaduk' <kaduk@mit.edu>
> Cc: draft-ietf-ipsecme-qr-ikev2.all@ietf.org; ipsec@ietf.org
> Subject: RE: AD review of draft-ietf-ipsecme-qr-ikev2-08
> 
> Hi Ben,
> 
> please see inline (I removed those parts of the message that seem to be
> resolved).
> 
> > > >    It is an open question whether or not it is feasible to build a
> > > >    Quantum Computer (and if so, when one might be implemented),
> > > > but if
> > > >
> > > > Feasibility of some quantum computer is becoming much less of an
> > > > open question; perhaps we want some qualifiers about efficiency,
> > > > scale, and/or general-purpose-nature.
> > >
> > > Do you have any data or pointers?
> >
> > I'm mostly just thinking about press releases from D-WAVE and Google
> > that get turned into articles in the technology press.  We see
> > headlines about
> > 60+ q-bit machines, that more likely than not are doing *something*.
> > 60+ So in
> > my mind it becomes a question of whether what these machines (that
> > exist and are being sold) are doing is useful for the problems
> > relevant to a given technology, rather than whether a quantum computer
> > exists.  (I'm not even sure that there's a generally accepted
> > definition for what "quantum computer" means -- some people seem to
> > use it for just annealing-based
> > stuff.)
> 
> Probably, if we add a qualifier "full-scale Quantum Computer" then the text
> will become less questionable? Something like this:
> 
>      It is an open question whether or not it is feasible to build a large-scale
> Quantum Computer
>       (and if so, when one might be implemented), but if it is, many of the
> cryptographic algorithms
>       and protocols currently in use would be insecure.
> 
> Or are you suggesting to rephrase the sentence completely? E.g.:
> 
>     Recent achievements in developing Quantum Computers (QC)
> demonstrate that
>     it is probably feasible to build a large scale QC. If such a QC is implemented,
>     many of the cryptographic algorithms and protocols currently in use would
> be insecure.

I'd suggest using the phrase "cryptographically significant Quantum Computer".  The problems that you find in cryptography do need more qubits than current Quantum Computers possess; however they also need to perform millions of operations without significant error, and that would appear to be a more serious hurdle.

> 
> > > >    would be compromised.  IKEv1 [RFC2409], when used with strong
> > > >    preshared keys, is not vulnerable to quantum attacks, because those
> > > >    keys are one of the inputs to the key derivation function.  If the
> > > >    preshared key has sufficient entropy and the PRF, encryption and
> > > >    authentication transforms are postquantum secure, then the resulting
> > > >    system is believed to be quantum resistant, that is, invulnerable to
> > > >    an attacker with a Quantum Computer.
> > > >
> > > > Do we have a reference for this "it is believed", or is it just
> > > > the outcome of the WG discussions?
> > >
> > > I'll let my co-authors comment on this, but I think it is meant that
> > > according to our best current knowledge nothing better than Grover's
> > > algorithm can be used to break symmetric key cryptosystem with QC.
> > > And Grover's algorithm only halves an effective key length, so if
> > > longer PSK is used, we're safe (we believe we are).
> >
> > To be clear: I share this belief! :)
> > I am just asking if it is sufficiently well-known/widespread that no
> > reference is needed; that may well be the case.
> 
> I believe it is, but I again prefer someone more knowledgeable in QC than
> myself to comment.

Breaking it down, we come up with four propositions:
- Grover's attack would require a huge number of operations against a sufficiently long secret.
- This huge number of operations is infeasible against any plausible operation.
- Any attack better than Grovers would require attacking the function at a lower level than a black box
- No such insight is known.

The first can easily be cited (e.g. the original Grover paper).  The second one is generally believed, but the exact length of the secret would depend on the eventual speed/scale of a quantum computer, which is somewhat unknown.
The third is also citable (again, the original Grover paper).  The fourth is problematic, because it is essentially an argument from a lack of knowledge.

Personally, I believe that this sort of argument is well known enough (at least, to the people who know postquantum cryptography) that it would not be required.