[CFRG] comments on opaque-06 and voprf-07 drafts

"Gajcowski, Nicholas H" <nhgajco@nsa.gov> Wed, 25 August 2021 14:06 UTC

Return-Path: <nhgajco@nsa.gov>
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 5CFC53A0D8C for <cfrg@ietfa.amsl.com>; Wed, 25 Aug 2021 07:06:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.164
X-Spam-Level:
X-Spam-Status: No, score=-3.164 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, FROM_GOV_DKIM_AU=-0.612, RCVD_IN_MSPIKE_H2=-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=nsa.gov
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 gV3qFzOJO2Ws for <cfrg@ietfa.amsl.com>; Wed, 25 Aug 2021 07:06:13 -0700 (PDT)
Received: from UPDC19PA24.eemsg.mail.mil (UPDC19PA24.eemsg.mail.mil [214.24.27.199]) (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 365213A0E29 for <cfrg@ietf.org>; Wed, 25 Aug 2021 07:06:03 -0700 (PDT)
X-EEMSG-check-017: 257704894|UPDC19PA24_ESA_OUT06.csd.disa.mil
X-IronPort-AV: E=Sophos;i="5.84,350,1620691200"; d="scan'208";a="257704894"
Received: from emsm-gh1-uea10.ncsc.mil ([214.29.60.2]) by UPDC19PA24.eemsg.mail.mil with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Aug 2021 14:05:57 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nsa.gov; i=@nsa.gov; q=dns/txt; s=nsa.gov; t=1629900358; x=1661436358; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=2qVjJvPZi7g3GI4jwuIfMaBm/kCvpPds3mcfgNBLVw8=; b=lMEGYJb93GZcX9xXELuCKXgwBYiOeoFmUznh8nOCNfk6Zz7E2DGhCcjh xGM3WzwbYP958xRl1dp6GF7ZIc3t9rYJa4XYqkoYPG87ETgNHo1YpqV4o h2ke0adSiKMUpzDKyU+aqVjbffPFf/Ac4EL9PamQw4Di4MOb0ICVhnNal se6NagqKibBEdbxuiSYfU+whgjazZyvVIKZ21HD8wuV+4r4bdwEa3o8e+ B5xM6Q+JEgIccxFi1OQ9fTlP3CEeAzKVUnO42K7GzB5xhExc4o+4CJHya Y9yxsVOZEEe6JYT3IGxDauq5y2iXTGFGgDv1WgF9D8sCZyMKI5zDBHTQm Q==;
X-IronPort-AV: E=Sophos;i="5.84,350,1620691200"; d="scan'208";a="54299599"
IronPort-PHdr: A9a23:yv6+YxTWgDvGudmerAvEYIm5itpsokCfAWYlg6HPa5pwe6iut67vIFbYra00ygOTBcOCs6MP1bCempujcFRI2YyGvnEGfc4EfD4+ouJSoTYdBtWYA1bwNv/gYn9yNs1DUFh44yPzahANS47xaFLIv3K98yMZFAnhOgppPOT1HZPZg9iq2+yo9JDffRlEiCCgbb9uKBi6ogTcutcLioZ+N6g9zQfErGFVcOpM32NoIlyTnxf45siu+ZNo7jpdtfE8+cNeSKv2Z6s3Q6BWAzQgKGA1+dbktQLfQguV53sTSXsZnxxVCAXY9h76X5Pxsizntuph3SSRIMP7QawoVTmk8qxkRgXoiCMaPDAn9m/ZhNF7gKZCrB6/uxBzxojZa5yXOvVjZKPQZdMUS3RcUMZNWSJPAYK8YJcAAeUOJutYs5D9p1kSoReiGQWgGuXiwSJIiH/s2q061vwsHQ/H0gM6HdIBrHPUrdvuNKcRUOC51LTDwy3Cb/xK2Tf974zIfQo6ofqRX7x8f9faxE4pFwPFgVWfs47lMC+S1ukWtWib9PBvWfigi24gtQF8uz6izdojhYfVnIwa0EzE9Tlnz4YvI921UEB2bcKrHpZOtyyXK5Z6Tt8tTWxnpSs0xKALtIKlcSUIxpoqyADTZfObf4aI/B/vSfqcLClmiX9ldryymgu+/Eemx+bhVce0yE5HojdKn9TDrHwA1wHf5tKaRvZy4kutwzWC2x3L5u1ZPUw4j7TXJ4Muz7IqiJYesF7PEjL4lUj0lKOaa0op9+ey5+nnf7nqvIKQOoBohg3kMakjmcqyCvkiPAcURWiU4+G82aXm/U3+XbpFkOU7krLcsJDGPcQbobO5AxNN3oYj9Rm/CzCm3cwfk3caLlxLZguLgYnrNV3TOfz3A/ixjkisnTt23fzJIrrhAo/VLnTZlrfhZqxy51RTyAo009BT/5NUCrcfL/LvQkL9qdPVAxAjPwG03urrEshx24wCVW6VAaKVLbvesVqS6eIuJ+mMapUVuDH4K/U94f7ujXA5lkUffaa12psac3a4Hu98LEmDbnrshckBHX8QvgUiVOzqlEGCUTlLanmuUaI8/D47BZmnDYjdWoCtjqaN3CChHp1ZNSh6DQXGGnnyeK2FVusCLiWILYUpxjcKT7eJSoI921eprgCsmJR9Ke+BsAIRt5nky8N25qmbsxA59TtwBt/V8yvFG2d0kWoKTDge2rt250N61AHQguBDn/VEGIkLtLtyWQAgOMuZlbQSNg==
IronPort-HdrOrdr: A9a23:0ebGGa4Rl+8yWsuTSwPXwPfXdLJyesId70hD6qm+c20tTiX4rbHXoB1/73XJYVkqKRQdcLy7Scu9qDbnhP1ICOoqXItKPjOW3FdARbsKheDfKn/bexEWndQtspuIHZIObuEYzmIXsS852mSF+hobr+VvOZrHudvj
X-IPAS-Result: A2DmBACoTSZh/1GMM5BagQkJgVCBfIF/dJVGgRSaY4F8CwEBAQEBAQEBAQgBQQQBAYcYASU2Bw4BAgQVAQEBBQEBAQEBBgMBAYEjhWkMgjUphCVRARUjBkImAQQbgh4Mg0eqYYEzGmeEaIUOCQGBMIl7gk+BbAaCDYEVgnKFIWeFLASFVoEzgT9XBw5iGL1TCoMqnkgsEoNlkg4DF5BslhaCHqMDAgQCBAUCFoFoAYIMKwpBDzuCak8XApx/Q2kCBgsBAQMJjUKBEIESAQ
Received: from unknown (HELO MSHT-GH1-UEA51.corp.nsa.gov) ([144.51.140.81]) by EMSM-GH1-UEA10.NCSC.MIL with ESMTP; 25 Aug 2021 14:05:56 +0000
Received: from MSMS-GH1-UEA11.corp.nsa.gov (144.51.140.82) by MSHT-GH1-UEA51.corp.nsa.gov (144.51.140.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Wed, 25 Aug 2021 10:05:56 -0400
Received: from MSMS-GH1-UEA17.corp.nsa.gov (144.51.140.88) by MSMS-GH1-UEA11.corp.nsa.gov (144.51.140.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.14; Wed, 25 Aug 2021 10:05:56 -0400
Received: from MSMS-GH1-UEA17.corp.nsa.gov ([144.51.140.88]) by MSMS-GH1-UEA17.corp.nsa.gov ([144.51.140.88]) with mapi id 15.01.2242.010; Wed, 25 Aug 2021 10:05:56 -0400
From: "Gajcowski, Nicholas H" <nhgajco@nsa.gov>
To: "cfrg@ietf.org" <cfrg@ietf.org>
Thread-Topic: comments on opaque-06 and voprf-07 drafts
Thread-Index: AdeZubQeoiBMPIhQQZu0cYWPnlj1AA==
Date: Wed, 25 Aug 2021 14:05:56 +0000
Message-ID: <b66fe153a58b43649caef04651e872d9@nsa.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.214.26.137]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/bDUbzG8A_o7WQEY7SFrdjW-FmcE>
Subject: [CFRG] comments on opaque-06 and voprf-07 drafts
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: Wed, 25 Aug 2021 14:06:19 -0000

Hi Folks,

I've read through the opaque-06 and voprf-07 drafts and noticed a few minor typos/errors.

First, a question for opaque-06:  Does the client authenticate the server based on the server_public_key provided to it in the ke2 portion of the AKE exchange? This seems to undermine the KCI protection afforded to the client by the AKE in the event the client's password is compromised.  With knowledge of the password, an attacker can essentially act as both the server and client in a faux registration phase.  Moreover, he can pick his own OPRF key, create his own server_public_key, and use the password to create a valid record with the appropriate auth_tag, etc.  When the client sends his ke1 message, the attacker can include his constructed record in the ke2 response which then would be accepted by the client.  If this correct, perhaps consider making a note of this feature as it may partially undermines an expected property of the AKE.

Below are a list of some minor errors/typos:

opaque-06:

pg 18 1st paragraph:  ... "The private-public keys (client_private_key, client_public_key) may be randomly generated." 
  Should read "The client_private_key may be randomly generated" as the client_public_key is a function of the client_private_key.

pg 27 step 7 of RecoverCredentials function:  "Output (client_private_key, response.server_public_key, export_key)."
  Should read "Output (client_private_key, server_public_key, export_key)."  While the server_public_key is a member of RegistrationRespone
  (section 5.1), it is not a member of CredentialResponse (6.1.1).  However, server_public_key is derived in step 5.

pg 32 outputs of ClientInit function: "ke1, blind, client_secret"
   The function does not return blind or client_secret as an output per se.  Rather, it updates the value for state.blind and the
   value state.client_secret is updated by the start function.  

pg 33 outputs of Start function:  "ke1 client_secret".
   Return of client-secret is unnecessary as the state is updated in step 4.  Further, the start function is only invoked by ClientInit
   which only expects the output of ke1.

pg 34 step 2 of ClientFinalize
   Preamble has an input of state.ke1 which was never updated by either ClientInit or Start functions.  Should the ClientInit function also 
   update the value for state.ke1, rather than return ke1, to be consistent with how it handles blind and client_secret?  

pg 36 step 9 of Response:  "Populate state with ServerState(expected_client_mac, session_key)"
   Syntax is a little confusing as expected_client_mac and session_key can be mistaken as inputs to the function ServerState.

pg 41 second to last paragraph of section 10.1:  "...Then, the client can verify that the client_identity and server_identity contained in its envelope..."
   The client_identity and server_identity are contained in CleartextCredentials which is not included as part of the envelope.  However, the auth_tag
   is computed over the nonce, innner_env, and CleartextCredentials in step 7 of the CreateEnvelope function. 

voprf-07:

pg 2 first paragraph of the introduction:  "...K(_) = F(K, _)"
   The secound K should be lowecase, i.e., "K(_) = F(k, _ )".

pg 12 VerifyFinalize function:  "issuedElement = Evaluate(skS, [element])"
   Unclear why square braces appear.  Should it be just "issuedElement = Evaluate( sks, element )"?

pg 12 VerifyFinalize function:  "E = GG.SerializeElement(issuedElement)"
   The function Evaluate in the previous step returns issuedElement as a SerializeElement so this step should result in error.


Best,

Nick Gajcowski