Re: [CFRG] IRSG review draft-irtf-cfrg-spake2-20

Watson Ladd <watsonbladd@gmail.com> Sat, 18 September 2021 15:33 UTC

Return-Path: <watsonbladd@gmail.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 4CFD63A1209 for <cfrg@ietfa.amsl.com>; Sat, 18 Sep 2021 08:33:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 XdpFeJi6n6wy for <cfrg@ietfa.amsl.com>; Sat, 18 Sep 2021 08:33:37 -0700 (PDT)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DD873A1207 for <cfrg@ietf.org>; Sat, 18 Sep 2021 08:33:37 -0700 (PDT)
Received: by mail-ed1-x52c.google.com with SMTP id n10so41109310eda.10 for <cfrg@ietf.org>; Sat, 18 Sep 2021 08:33:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=d6olGUMoMZ78b0313JOX0xO4t/fP1Mtzv1wVUg+EviA=; b=Z10l+Sm/nEM3QS2ZCjlUba5mnfEfKlyyR/5t/1EYswR4z91uWbmS5kKkh2lrTjGWgV MNBMXJKTnduiZwOILphaFm8CYMzBAnj3MY1IyLowvCXQrGaY9HIhCTf81a+GDoraPZ1d q/0jd+qqnTW4xGk8y+fBJ1azz1F4ai5MnwzcXB0g82lDW6j9McoMnbNQlx/rhoXV1lT8 uoz8NoM4Pf/2yqVQxnAfuyc3eoEc7vut07HzpYJ4++4VjqYtzIwZdYrxeAYom/C31adD /I3kHtE4bfcFsAR6P8E2aKNJ62XpaTzoj87HLmC+jZXcmPm1WxcQyVsxdxgC+l9GgM+E FAGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=d6olGUMoMZ78b0313JOX0xO4t/fP1Mtzv1wVUg+EviA=; b=mLVVSquQ3vXkdobgqQEuCOfZZPnjIWtXou2kDGA7mL/ccA1AuCjfNajSMU2dPDXm9g SmcY2YoRwFLZgFL5Q+TYMFCT2n6EsK0NNTc8yfiwg64gbGfzaENH8oP3DsKxrj9knTJA jaL9nOBGxW6ANZEv6MIf8zsS8p5KZAw5M/fxb5rcGOO2NLrhutxzwOxNFYIT5HuSqvoy raGqj0W3knng+P9xwjRyUG+yuZdxnxgkB6dbJuupLy6/3KaB8vt5H/njwfRioitO++wy 2+/ExFQ9iyIs980VTom6WpSgDi8PRwDJjQ5Ve0Um7nB5Q6PLAjATOXKB9N+Zo2dLMoZG ykGQ==
X-Gm-Message-State: AOAM532GHKLcXYabwKe2m6OGSfur71ZqX8w7WFCY2c9K65yAvj6we0aV 70e/Xfidgz8471/PZKbSwyFibgUi5YD22Fkj7Cs=
X-Google-Smtp-Source: ABdhPJwwcSOcTmmc13fS00ohW/xqLhPrdsYSz6XJxQHcWsJWYNQR7wmyZIvmKB6lbaY3EHTo4wbJysMQCmyfhJh76ek=
X-Received: by 2002:a17:906:7d42:: with SMTP id l2mr18817568ejp.467.1631979213449; Sat, 18 Sep 2021 08:33:33 -0700 (PDT)
MIME-Version: 1.0
References: <aad93bd3-3dd2-bd53-ca21-d6f2632a3cb5@gmail.com> <CACsn0cmQgrYHhWm533R2ybQ7rTMg_sVxqO5qN5TLrs1C4uir+Q@mail.gmail.com> <172dcce4-017f-f9dd-2ee3-b57652bcdd41@gmail.com> <CACsn0c=YARB=YjjGSe8G4V2ybdErvzYZGCp2Q5TQoae5cmR6Bg@mail.gmail.com> <08ec7619-f7d4-81d8-f73d-a3ab86164bbb@gmail.com>
In-Reply-To: <08ec7619-f7d4-81d8-f73d-a3ab86164bbb@gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Sat, 18 Sep 2021 08:33:21 -0700
Message-ID: <CACsn0c=awROmo5oY4cqnmWiR6_oTdsF+PK6tjjpPZ3ZgeymBpA@mail.gmail.com>
To: Julia Hesse <juliahesse2@gmail.com>
Cc: crypto-panel@irtf.org, Benjamin Kaduk <kaduk@mit.edu>, "<cfrg@ietf.org>" <cfrg@ietf.org>, Colin Perkins <csp@csperkins.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/SeS_rEeqZ05Du_cOa_p2ry6M6r4>
Subject: Re: [CFRG] IRSG review draft-irtf-cfrg-spake2-20
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, 18 Sep 2021 15:33:41 -0000

Draft 22 is now uploaded.

On Tue, Sep 14, 2021 at 2:11 PM Julia Hesse <juliahesse2@gmail.com> wrote:
>
> Hi Watson,
>
> looks good to me, thank you!
>
> Julia
>
> Am 9/14/2021 um 8:45 PM schrieb Watson Ladd:
> > I've opened https://github.com/kaduk/spake2/pull/24 which I think
> > addresses all the comments from this review.  If this is so, I can
> > merge it and upload a new copy tonight.
> >
> > On Fri, Sep 10, 2021 at 11:04 AM Julia Hesse <juliahesse2@gmail.com> wrote:
> >> Dear Watson,
> >>
> >>>> // - What does it mean to exchange messages symmetrically? (In the per-user M and N section)
> >>>>       * Resolved. I suggest to remove "to have a symmetric variant" - it is not needed and might cause confusion (variant of what?)
> >>> It is needed: Magic Wormhole uses this variant. And the concern about
> >>> who uses M and who uses N in cases where it isn't clear is best
> >>> addressed by using this variant.
> >> Ah, apparently I got confused here: the draft is referring to SPAKE2 as
> >> a symmetric PAKE, and to the case of M=N as its symmetric variant. So
> >> you are completely right, the sentence in question should stay, but I
> >> would recommend referring to the case of M=N as "parallel variant" (or
> >> something else) instead of assigning two different meanings to the word
> >> "symmetric".
> >>
> >>>> // - Beyond scalar multiplication being constant time, are there any other constant time considerations we should include?
> >>>>       * Resolved
> >>>>
> >>>> // - Why is Ke not included in the test vectors? It may be redundant, but it seems useful as an additional sanity check.
> >>>> // - There are currently no test vectors that include AAD -- should we add some?
> >>>>       * I have not verified these two.
> >>>>
> >>>> // - Why is len() a little-endian output?
> >>>>       * I agree with Watson to be consistent with Kerberos here
> >>>>
> >>>> // - Should we clarify that the transcript assumes a particular point encoding scheme, and that is to be defined by the calling application or implementation?
> >>>>       * Resolved
> >>>>
> >>>> Some more comments, not related to the IRSG review, below.
> >>>>
> >>>> I was missing a minimal list of data that A and B can start SPAKE2 from: ciphersuite, pw, A, B, M, N - did I forget something? What about the output key length? This can be easily included in 3.2, replacing "A and B are provisioned with information such as..."
> >>>>
> >>>> The document does not specify who uses M and who uses N. In the M\neq N variant of the protocol, which is mostly described in this draft, this is relevant, since no analysis was conducted in case A sends both xM and xN (a solution that implementors are not unlikely to come up with). I would include an instruction in the RFC, e.g., that the application must ensure that M and N are assigned to A and B, e.g., by having them apply some lexicographically-first-... rule.
> >>> I'm not sure I follow the issue. The sentence says 'A picks x randomly
> >>> and uniformly from the integers in [0,p), and calculates X=x*P and
> >>> S=w*M+X, then transmits pA=S to B.' Alice is hence the initiatior. If
> >>> it's impossible to do this easily then one of the M=N variants should
> >>> be used. Most protocols have an asymmetry here where one side is
> >>> initiating a request and the other receiving. Happy to add clarifying
> >>> text.
> >> Ack to all. It would actually be good to clarify this in the draft: the
> >> M != N variant is for an initiator-responder variant, the M=N for a
> >> parallel variant that MUST (?) be used whenever the applicatoin cannot
> >> assign initiator and responder role to the parties. My concern was from
> >> a security perspective, from which we should avoid situation such as the
> >> following: a user generates pA wrt M, but then receives pB also
> >> generated wrt M, suddenly realizes that it is the responder, and
> >> *additionally* sends pA wrt N. This voids the security proof, so we need
> >> to be pretty clear here.
> >>
> >> Best regards,
> >> Julia
> >>
> >>>> p.2
> >>>> The KDF has only 3 inputs, but a fourth (key length L) is described in the text
> >>>>
> >>>> p.3
> >>>> servers -> serves
> >>>> flow figure should include "verify cA" and "verify cB", since it is a MUST.
> >>>>
> >>>> p.4
> >>>> remove unnecessary variables T and S? E.g., directly set pB=w*N+Y.
> >>> These editorial comments seem worthwile to fix. Side note to Colin: is
> >>> there another set of reviews I should be waiting for at this stage? If
> >>> not I should be able to fix these all pretty promptly.
> >>>
> >>> Sincerely,
> >>> Watson Ladd
> >>>
> >>>
> >>> --
> >>> Astra mortemque praestare gradatim
> >
>


-- 
Astra mortemque praestare gradatim