Re: [Cfrg] Proposed PAKE Selection Process

William Whyte <wwhyte@qti.qualcomm.com> Sat, 25 May 2019 11:29 UTC

Return-Path: <wwhyte@qti.qualcomm.com>
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 3E049120044 for <cfrg@ietfa.amsl.com>; Sat, 25 May 2019 04:29:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.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 ZnKRFRmZHrUo for <cfrg@ietfa.amsl.com>; Sat, 25 May 2019 04:29:14 -0700 (PDT)
Received: from alexa-out.qualcomm.com (alexa-out.qualcomm.com [129.46.98.28]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93117120075 for <cfrg@irtf.org>; Sat, 25 May 2019 04:29:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1558783755; x=1590319755; h=from:to:date:message-id:references:in-reply-to: mime-version:subject; bh=qTTtTDEs6cj4fZaCZFUfWOaiyEifA3iS+R7b1K7aBFM=; b=AE5nHxei4Pft10ljtyriEv1Ge4edPtpDUsnKq692m+a6qHyFxAOsbXye zgmiFlGjmwRaPK1aaEYFADX3E5X+ZM/OSe5CkdCr5jtRByUuvDlzyvM2M aaXniL8mwrDlxsa05lyXhLgZjSV8DChoqNqQfh0buFO5p61EKGyMz1Y3N U=;
Thread-Topic: [Cfrg] Proposed PAKE Selection Process
Received: from ironmsg09-lv.qualcomm.com ([10.47.202.153]) by alexa-out.qualcomm.com with ESMTP; 25 May 2019 04:29:14 -0700
X-IronPort-AV: E=McAfee;i="5900,7806,9267"; a="96148397"
Received: from nalasexr01b.na.qualcomm.com ([10.49.56.22]) by ironmsg09-lv.qualcomm.com with ESMTP/TLS/AES256-SHA; 25 May 2019 04:29:13 -0700
Received: from NALASEXR01H.na.qualcomm.com (10.49.56.54) by NALASEXR01B.na.qualcomm.com (10.49.56.22) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 25 May 2019 04:29:13 -0700
Received: from NALASEXR01H.na.qualcomm.com ([10.49.56.54]) by NALASEXR01H.na.qualcomm.com ([10.49.56.54]) with mapi id 15.00.1395.000; Sat, 25 May 2019 04:29:13 -0700
From: William Whyte <wwhyte@qti.qualcomm.com>
To: Nick Sullivan <nick=40cloudflare.com@dmarc.ietf.org>, "cfrg@irtf.org" <cfrg@irtf.org>
Thread-Index: AQHVEmAE7tgaK9xezUKlnKxPeyxWx6Z7tHeg
Date: Sat, 25 May 2019 11:29:12 +0000
Message-ID: <79c2765e29b246eb9ff3f3f7139ce52c@NALASEXR01H.na.qualcomm.com>
References: <CAFDDyk9RXZrBoQ0s0_cj_Q0PPYkaVjnx7voctz0TU8dL57B+1A@mail.gmail.com>
In-Reply-To: <CAFDDyk9RXZrBoQ0s0_cj_Q0PPYkaVjnx7voctz0TU8dL57B+1A@mail.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.49.16.6]
Content-Type: multipart/alternative; boundary="_000_79c2765e29b246eb9ff3f3f7139ce52cNALASEXR01Hnaqualcommco_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/6bzz0OlpmK-L1mjD5728iALxV-U>
Subject: Re: [Cfrg] Proposed 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: Sat, 25 May 2019 11:32:56 -0000

Hi Nick,

I’m involved in writing a standard, ISO 21177, which makes use of some IETF/IRTF building blocks and wanted to use a PAKE. We’re on a slightly tighter timeline than the one described below. Can you (or can CFRG) recommend an “interim” PAKE that could be referenced for the first version of this standard? We would intend to add the final CFRG selection as the recommended PAKE mechanism in a revision of 21177, but for now a stable reference that allows implementers to do interoperable proofs of concept would be great.

William

From: Cfrg <cfrg-bounces@irtf.org> On Behalf Of Nick Sullivan
Sent: Friday, May 24, 2019 2:39 PM
To: cfrg@irtf.org
Subject: [EXT] [Cfrg] Proposed PAKE Selection Process

Dear CFRG,

We’re planning to start the main phase of PAKE selection process. This proposal was developed by Stanislav Smyshlyaev with the support of the CFRG chairs.

In addition to helping drive this PAKE selection process, Stanislav has been selected to the role of Secretary of the CFRG, a position that was previously vacant.

To be 100% sure that the process will be as transparent and effective as possible, we would like to announce the proposed plan of handling the process. If you have any concerns about the plan, please send them to the chairs before 27.05.2019.


Step 1, 01.06.2019-30.06.2019:

·        Call for candidate protocols. Note: the chairs especially encourage to nominate PAKEs that have been discussed in CFRG recently (the list can be found in the slides from IETF 104 CFRG session<https://www.ietf.org/proceedings/104/slides/slides-104-cfrg-pake-selection-01.pdf>df>, slide 9). Third Party nominations are encouraged.

·        Discussing the list of questions to be asked in addition to the ones that are present in RFC 8125. Starting point for such list of questions can be the questions gathered before IETF 104 (can be found in the slides from IETF 104 CFRG session<https://www.ietf.org/proceedings/104/slides/slides-104-cfrg-pake-selection-01.pdf>df>, slides 7-8).

Step 2, 01.07.2019-19.07.2019:

·        The designers of the protocols (or persons who volunteered to push them forward) prepare papers with:

a.      expanded answers for all positions of RFC 8125;

b.      their own opinions on additional questions selected at Step 1 (they could be incomplete in some sense – for example, a designer of a PAKE might not be an expert in TLS and might not be able to reply how his PAKE can be incorporated in TLS 1.3).
IETF 105 meeting:

·        The chairs give a review of the progress with the process and make corrections of plans.

·        The chairs enumerate questions (from the list that has been prepared during Step 1) which should be considered by independent reviewers before asking the Crypto Review Panel for reviews and analysis. For instance, it will be important that experts from other WGs consider how certain PAKEs fits into TLS 1.3, or into IoT devices.
Further steps (subject to corrections after IETF 105 meeting).
Step 3, 01.08..2019-15.08.2019:

·        Call for reviewers for the enumerated questions, which require additional consideration.

·        Crypto Review Panel members start the process of verification of security proofs of the candidates (Requirement 2 in RFC 8125).
Step 4, 16.08.2019-15.09.2019:

·        The reviewers who volunteered at step 3 prepare their analysis regarding the assigned questions.

·        Crypto Review Panel members are in the process of verification of security proofs of the candidates (Requirement 2 in RFC 8125).
Step 5, 16.09.2019-30.10.2019:

·        Crypto Review Panel members review all gathered materials on each of the protocols to prepare the final list of verified answers to the positions of RFC 8125 and all additional questions from the list that has been prepared during Step 1.

·        If additional explanations are needed, Crypto Review Panel members ask for them from the designers.

·        Crypto Review Panel members write overall reviews for all candidate PAKEs, based on the materials that have been gathered and verified..
Step 6, 01.11.2019-16.11.2019:

·        CFRG chairs discuss the obtained reviews and make their recommendations to CFRG (or convey to CFRG that they can’t make a recommendation yet).
 IETF 106 meeting:

·        The chairs give a review of the progress with the process and make corrections of plans.

·        If everything is clear:

o   one (or more) PAKEs are selected;

o   the process with CFRG document “Recommendations for password-based authenticated key establishment in IETF protocols” is initiated: all practically important recommendations (parameter selection, protecting implementations against side-channel attacks, handling of counters etc.) must be given there;

o   at this point documents on usage of selected PAKEs in TLS/IPsec/etc. can be developed.


Best regards,
Nick on behalf of Stanislav, Kenny, and Alexey