[Cfrg] Additional questions to consider for the PAKE Selection Process

"Hao, Feng" <Feng.Hao@warwick.ac.uk> Fri, 14 June 2019 11:07 UTC

Return-Path: <Feng.Hao@warwick.ac.uk>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745F4120267 for <cfrg@ietfa.amsl.com>; Fri, 14 Jun 2019 04:07:03 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 504gN3TSh6zH for <cfrg@ietfa.amsl.com>; Fri, 14 Jun 2019 04:07:00 -0700 (PDT)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03on062b.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe08::62b]) (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 3361012021F for <cfrg@irtf.org>; Fri, 14 Jun 2019 04:06:59 -0700 (PDT)
Received: from DB7PR01MB5435.eurprd01.prod.exchangelabs.com (20.178.106.208) by DB7PR01MB4362.eurprd01.prod.exchangelabs.com (52.135.135.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.12; Fri, 14 Jun 2019 11:06:57 +0000
Received: from DB7PR01MB5435.eurprd01.prod.exchangelabs.com ([fe80::e9b7:48cd:a654:1283]) by DB7PR01MB5435.eurprd01.prod.exchangelabs.com ([fe80::e9b7:48cd:a654:1283%6]) with mapi id 15.20.1987.012; Fri, 14 Jun 2019 11:06:57 +0000
From: "Hao, Feng" <Feng.Hao@warwick.ac.uk>
To: CFRG <cfrg@irtf.org>
Thread-Topic: Additional questions to consider for the PAKE Selection Process
Thread-Index: AQHVIqFH9SNJy7Rpxk+9Dl8eVq7Owg==
Date: Fri, 14 Jun 2019 11:06:56 +0000
Message-ID: <249D87DF-0448-4BD1-A3A6-E9E88B0A4E87@live.warwick.ac.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.b.190609
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Feng.Hao@warwick.ac.uk;
x-originating-ip: [137.205.238.4]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 968596b4-7ee5-4e75-d783-08d6f0b86a90
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DB7PR01MB4362;
x-ms-traffictypediagnostic: DB7PR01MB4362:
x-microsoft-antispam-prvs: <DB7PR01MB4362342ADAD5FD232DF2A108D6EE0@DB7PR01MB4362.eurprd01.prod.exchangelabs.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0068C7E410
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(396003)(136003)(346002)(376002)(189003)(199004)(68736007)(6436002)(54896002)(53936002)(6512007)(6306002)(2906002)(6486002)(25786009)(33656002)(8936002)(8676002)(7736002)(81156014)(6916009)(81166006)(73956011)(66946007)(66446008)(66556008)(66476007)(64756008)(91956017)(76116006)(6116002)(3846002)(5660300002)(102836004)(66066001)(256004)(14444005)(71190400001)(71200400001)(26005)(186003)(478600001)(72206003)(486006)(14454004)(476003)(413944005)(86362001)(58126008)(316002)(786003)(6506007)(74482002)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR01MB4362; H:DB7PR01MB5435.eurprd01.prod.exchangelabs.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: warwick.ac.uk does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: yagO1Hsm/PcqbpWAO+zPrVqbQRpwrAK7Xt7lU7rB+Udr64BgvN2Hnt8PlPPtrHutDo4Ibcsp2R6LY3NXyZalCbouehAXj16wMcIfJZCiKDLFlfk3UVD7zWZw0VTSUP7/p9jwA1+lDRy8co4lHF2plNp+hzAYQyvUxdOSFvIcjeeokVvxzo+UQrxhtMXvNWmqa6/EbUEhwePryXDV8Zz1MhCEKrpW+mtV+L+OaOaG/Ksp15KkfY2ESIBadn1+F+VsStmkyDfSbZpPNndpheL1m3hYXVxw9KRmM5BwlF3ZhubJX4rn0E8tG8iLVMAPocNeP+qlNVoCkgArulv7D29WKo0tns4lTnhT10fxXcAlfZZyCNUe6Au47N60T8QSkucFJSjUdxjr4B0/O+Zh+I/BPu9i6rzYtMKf9Uj5lG0zXeI=
Content-Type: multipart/alternative; boundary="_000_249D87DF04484BD1A3A6E9E88B0A4E87livewarwickacuk_"
MIME-Version: 1.0
X-OriginatorOrg: warwick.ac.uk
X-MS-Exchange-CrossTenant-Network-Message-Id: 968596b4-7ee5-4e75-d783-08d6f0b86a90
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2019 11:06:56.9901 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 09bacfbd-47ef-4465-9265-3546f2eaf6bc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: u1775114@live.warwick.ac.uk
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR01MB4362
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/gVx2DgpJ9ZNzM2B7yt-ycS-tXt8>
Subject: [Cfrg] Additional questions to consider for the PAKE Selection Process
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Jun 2019 11:07:08 -0000

Dear CFRG,

I would like to suggest the following additional questions to consider for the PAKE selection process.


  *   A PAKE scheme should define how the explicit key confirmation is performed and clearly state whether this procedure is optional or mandatory.
  *   The authors should state if the two communicating parties can initiate the key exchange process at the same time, or it must always be the case that only one party can initiate the process.
  *   (Related to above) The authors should clearly state the “round efficiency” of the PAKE protocol. In a standard two/multi-party secure computation setting, the “round” is defined as a step in which all parties can complete operations at the same time without depending on each other. In practice, a 2-round protocol could be implemented as 2 flows or 3 flows depending on the application context, but that’s more the implementation detail.
  *   If a PAKE scheme relies on the assumption of a trusted setup--more specifically, the discrete logarithm relationship between the two group elements in the system setup MUST be unknown--in anticipation of the worst but not impossible scenario, the authors should clearly state the security implications when the discrete logarithm relationship becomes known, and the subsequent mitigation measures.

Any comments are most welcome.

Cheers,
Feng