Re: [CFRG] RGLC on draft-irtf-cfrg-opaque-13

Kevin Lewi <klewi@cs.stanford.edu> Tue, 05 March 2024 06:37 UTC

Return-Path: <klewi@cs.stanford.edu>
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 9905BC1516E1 for <cfrg@ietfa.amsl.com>; Mon, 4 Mar 2024 22:37:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Level:
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
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 SwO9aRjVcmts for <cfrg@ietfa.amsl.com>; Mon, 4 Mar 2024 22:37:01 -0800 (PST)
Received: from smtp1.cs.Stanford.EDU (smtp1.cs.stanford.edu [171.64.64.25]) (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 6DEB7C14F5F1 for <cfrg@irtf.org>; Mon, 4 Mar 2024 22:37:01 -0800 (PST)
Received: from mail-lj1-f173.google.com ([209.85.208.173]:55297) by smtp1.cs.Stanford.EDU with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <klewi@cs.stanford.edu>) id 1rhOQ7-0001Ew-Fa for cfrg@irtf.org; Mon, 04 Mar 2024 22:37:01 -0800
Received: by mail-lj1-f173.google.com with SMTP id 38308e7fff4ca-2d21cdbc85bso65283351fa.2 for <cfrg@irtf.org>; Mon, 04 Mar 2024 22:36:59 -0800 (PST)
X-Forwarded-Encrypted: i=1; AJvYcCVuphWqa/lkdjCoZ+/ypKvlsH84KzeSOo4wyeWk1cbCZJr635ChyPJu0qScHVTQuncwlnbuoEOJlF0otkZ7
X-Gm-Message-State: AOJu0Yyda0gVjYXMfWYfA4WSAG12shNsi3Rvm0ZGv19d5W/D0Lh4aJcT 81Zhc6FF3cEuRqj1+8XtUI2KBSS9G3IMfT+s+cKZ0f5zJeGDt6bWQauVtHT/rVAdUMrla3LYtH7 Qi7c98b5rVHhTLUpjp/7HcWcM3EE=
X-Google-Smtp-Source: AGHT+IEAC6pom6dlVNGi/Tkz5KtiSeEyNUzUgD9wU/UCt3sbvicrhUtZDcyL3KRc9hlFoLdPt2Ct8kjBYnAia3bs/wk=
X-Received: by 2002:a2e:a176:0:b0:2d3:f68e:ab51 with SMTP id u22-20020a2ea176000000b002d3f68eab51mr151189ljl.48.1709620618363; Mon, 04 Mar 2024 22:36:58 -0800 (PST)
MIME-Version: 1.0
References: <CAMr0u6kOrbwdHEDmmGsVYzqjsEbzBCCtGL39jckNbSWsEumOQg@mail.gmail.com> <994001115.165708.1706765982169@email.ionos.com> <CACitvs8zzoQVY4uo1zOtoBWrSVOLfzGFBCsMnevxnCMXg-CJGw@mail.gmail.com>
In-Reply-To: <CACitvs8zzoQVY4uo1zOtoBWrSVOLfzGFBCsMnevxnCMXg-CJGw@mail.gmail.com>
From: Kevin Lewi <klewi@cs.stanford.edu>
Date: Mon, 04 Mar 2024 22:36:47 -0800
X-Gmail-Original-Message-ID: <CACitvs_kEOgBC0eZNbHZ1EBy6v7kqL2-99-A1kRD_QqTaTuQKw@mail.gmail.com>
Message-ID: <CACitvs_kEOgBC0eZNbHZ1EBy6v7kqL2-99-A1kRD_QqTaTuQKw@mail.gmail.com>
To: steve@tobtu.com
Cc: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>, CFRG <cfrg@irtf.org>, cfrg-chairs@ietf.org, draft-irtf-cfrg-opaque@ietf.org
Content-Type: multipart/alternative; boundary="000000000000a88cec0612e411e4"
X-Scan-Signature: a35a0880a1b226e45b16c4003e03508d
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/6-grA70Ayo90uyoiA-1vGvZ1eHg>
Subject: Re: [CFRG] RGLC on draft-irtf-cfrg-opaque-13
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: Tue, 05 Mar 2024 06:37:05 -0000

Hi Steve!

Just wanted to check in and see if you had a chance to review my response
to your feedback above. Let me know if there is anything else that you
would like to see addressed explicitly, or if we are good to go.

Kevin

On Sun, Feb 11, 2024 at 8:59 PM Kevin Lewi <klewi@cs.stanford.edu> wrote:

> (Replying to:
> https://mailarchive.ietf.org/arch/msg/cfrg/Fxxdbe6sBae9yqTtZfwrGvtAKRQ/)
>
> Hi Steve,
>
> Appreciate the review and the feedback! Here are my thoughts:
>
> 1) "There should be a section mentioning that OPAQUE is doubly augmented
> and why that's better than augmented."
>
> I gave this some thought and I think I understand the distinction between
> an sdPAKE vs. aPAKE. But I am not entirely sure if we should get into this
> level of detail in the draft, mainly because I am struggling to figure out
> how to phrase this in a way that is generally understandable to most
> readers without causing confusion. However, if you do feel like this would
> be necessary to include in the draft text, can you perhaps write up a
> suggested paragraph under a new subsection of the "Security Considerations"
> section which covers this detail? Then we can discuss and iterate on the
> wording. You can also open a PR on
> https://github.com/cfrg/draft-irtf-cfrg-opaque/pulls and we can continue
> the discussion via comments over there.
>
> 2) Section 10.3. "Related Protocols" should probably be removed.
>
> I agree, good suggestion! I went ahead and put up a PR for this change.
> https://github.com/cfrg/draft-irtf-cfrg-opaque/pull/443
>
> 3) The mentions of "offline registration" should be changed to "online
> registration".
>
> Good point, this is confusing. Seems like we have a PR up (
> https://github.com/cfrg/draft-irtf-cfrg-opaque/pull/439) to address this,
> by changing "offline registration" to simply read as "registration" (no
> "online"). Let me know if that also sounds acceptable.
>
> 4) Now the good parts of OPAQUE that weren't mentioned. Stateless HSM
> implementation.
>
> I agree with this as well, but similar to point #1, do you think that this
> is something that we actually need to include explicitly in the draft text?
> And if so, do you have a suggested change or wording that would be suitable
> for adding to one of the sections?
>
> Let me know if I missed anything.
>
> Thanks,
> Kevin
>
>
> On Thu, Feb 1, 2024 at 12:39 AM <steve@tobtu.com> wrote:
>
>> I've been meaning to do a full review and just checked the status. So
>> this might be a little rushed. Anyway...
>>
>> ----
>>
>> "Asymmetric PAKE" is not a thing. aPAKE means "augmented PAKE" and some
>> time ago people saw "aPAKE" and thought it meant asymmetric because of it's
>> asymmetrical relation between the client and server. The first PAKE was a
>> balanced PAKE and it was then augmented so that a server doesn't hold a
>> password equivalent. There are currently four types of PAKEs: balanced,
>> augmented, doubly augmented, and identity. Abbreviated bPAKE, aPAKE, dPAKE,
>> iPAKE and if the non-balanced PAKE has an OPRF then it is "strong" and is
>> prefixed with an "s". Note that bPAKE ⊂ aPAKE ⊂ dPAKE ⊂ iPAKE. For info on
>> iPAKEs see https://eprint.iacr.org/2020/529.
>>
>> Doubly augmented PAKEs' best use case is WiFi: compromising a device
>> doesn't lead to being able to act as an AP. The first description of a
>> dPAKE: "SPAKE2 can even be doubly augmented, where Alice does the same
>> thing, but I'm not sure if there's any application to that." -Mike Hamburg (
>> https://moderncrypto.org/mail-archive/curves/2015/000424.html) I
>> actually couldn't think of a reason either until around the time the WiFi
>> Alliance picked a known to be broken bPAKE.
>>
>> Which brings us to OPAQUE is not an aPAKE, it's a sdPAKE. One way to
>> think of OPAQUE, as a sdPAKE, is that it's a cert delivery protocol. Once
>> the client has the cert they just store and use it. There should be a
>> section mentioning that OPAQUE is doubly augmented and why that's better
>> than augmented
>
>