Re: [CFRG] Does OPRF/OPAQUE require full implementation of RFC 9380

Michael StJohns <msj@nthpermutation.com> Sat, 30 March 2024 18:48 UTC

Return-Path: <msj@nthpermutation.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 AA301C14F68D for <cfrg@ietfa.amsl.com>; Sat, 30 Mar 2024 11:48:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20230601.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Q_ApjyM-fa6 for <cfrg@ietfa.amsl.com>; Sat, 30 Mar 2024 11:48:40 -0700 (PDT)
Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0435C14F609 for <cfrg@irtf.org>; Sat, 30 Mar 2024 11:48:40 -0700 (PDT)
Received: by mail-qv1-xf32.google.com with SMTP id 6a1803df08f44-696a221c53aso33954846d6.0 for <cfrg@irtf.org>; Sat, 30 Mar 2024 11:48:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20230601.gappssmtp.com; s=20230601; t=1711824519; x=1712429319; darn=irtf.org; h=in-reply-to:from:references:to:content-language:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to; bh=RaVpdr/sq4c4HZwWcVBbIrEkafAl+UtWjinULQz14F8=; b=vEGvsSzaKiMql1KB7BBuRxl5fuaQmVHZtyDil5oY1BimY1AseaR1P04u8qg8GiTXZb Py9OgSM8hvySBL1LfBOMw6KEsJec1suFCAmwDwopy5+k+PwMlgoTVHITv+DnhwKuRnNV vLBl1jD0B9rSzrzmsfLW1L8yVp41RN4+HSLT6PTMY6UWdqDHubrUkuzeFtzPSI08wktx Oub+4SOOVA64DIozJmg7eu8WxqDclIJNwDn9JdrSTIFq1o7+rSwXC/6Bf8UdDhWiIH3V on+AuuzJTM+UieJM2/JdyVm+LhsYGBPHc6QknwZsWoEo3IJy91tvf82lhuZ+tVOMPGoQ aFKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711824519; x=1712429319; h=in-reply-to:from:references:to:content-language:subject:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=RaVpdr/sq4c4HZwWcVBbIrEkafAl+UtWjinULQz14F8=; b=oddNfSsU8raGYutV7LOWyuy4tUWuSfqRzuGiVdJfRwypKOgIogIhWV83FqGi5CIjIP k/dGWHL8gng/XyUyrzL81hXZKAvtVbD+iZlbfsSUzb2fXPEiHeWp69bhP0qyFMyZVKUs lCJCyDEVNmr1fBHFnjioSTdk9I2uUYVHlkdXB5y27L7xEVASJ+/G8Uiia3Yq6WifLOM/ NCMa2yaotDfzx9sMY9g3F3gaSKBPDQr5688GvWM+1RZeCYG9W66QP3wrLOMp2m9WXKOH WNR7dWhN6kI0fpWbLslpilkC7CG63tMC80pGGc+aZZjltwAkFtrzQ019+UTAO1rXLsXk aMFg==
X-Gm-Message-State: AOJu0Yx7SjdDlaaTbdsAj5iQMK9phQwBAPwghgiQB6ldUiTPl/gPW9ex McF7pFDuQdrf2YM+vlymVZQ168CG6bVLMOlJ1CBtkBgr8J+JR5N+9ul+LGYRvMe91cpg11Hpw7Z /
X-Google-Smtp-Source: AGHT+IEfzZgpy0Q49kEt5m/42NRZ41vov78w2o3OwrKuMUF9P4sGa6ef4bBNUT6/0Rn+t6Aj4N1YSw==
X-Received: by 2002:a05:6214:30b:b0:696:9f57:5485 with SMTP id i11-20020a056214030b00b006969f575485mr10240380qvu.11.1711824518728; Sat, 30 Mar 2024 11:48:38 -0700 (PDT)
Received: from [192.168.1.23] (pool-108-31-156-76.washdc.fios.verizon.net. [108.31.156.76]) by smtp.gmail.com with ESMTPSA id lx15-20020a0562145f0f00b00696b176ddd1sm2863816qvb.3.2024.03.30.11.48.37 for <cfrg@irtf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 30 Mar 2024 11:48:38 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------YMosGMtwILE2mtQeTz0293xw"
Message-ID: <bb4540d5-35ec-470f-93c3-14651d0b01b7@nthpermutation.com>
Date: Sat, 30 Mar 2024 14:48:37 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: cfrg@irtf.org
References: <410a0800-78ff-422f-8ca3-5a0211478cbd@aaa-sec.com> <ZggHSDs5bRweThW5@localhost>
From: Michael StJohns <msj@nthpermutation.com>
In-Reply-To: <ZggHSDs5bRweThW5@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/kM9W90O1nZ6CU3mlGc1TCRLnu64>
Subject: Re: [CFRG] Does OPRF/OPAQUE require full implementation of RFC 9380
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://mailman.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://mailman.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Mar 2024 18:48:41 -0000

On 3/30/2024 8:36 AM, stef wrote:
> On Sat, Mar 30, 2024 at 12:56:10PM +0100, Stefan Santesson wrote:
>> Note that there are not even a "MUST" expressed here. Just a "must" and
>> therefore not a requirement according to section 1.1.
> nothing really is a must, but if you don't implement the hashtogroup as per
> the rfc you will not be able to satisfy the test vectors, and if you don't
> satisfy the test vectors it is difficult to claim compliance with the rfc. and
> also compatibility with all the other implementations. if that is ok with you,
> you should be doing whatever you want.

With an apology here in that CFRG is not supposed to be doing standards, 
and as such mostly can ignore the normal requirements language of 
MUST/REQUIRED, SHOULD/RECOMMENDED, MAY/ALLOWED:

I can't tell from your reply whether or not you mean "MUST" or 
"SHOULD".  The "if you don't do this, you're not compliant with the RFC" 
is pretty much the definition of "MUST".

But "we recommend you do it this way, and if you don't you will not be 
able to satisfy the test vectors" is exactly the definition of "SHOULD" 
and you should include the above explanation for what happens if you 
don't implement hashtogroup as per the RFC.

Pick one.  I'd recommend "MUST" based on the "compliance to RFC" comment.

Later, Mike