Re: [Cfrg] Adoption call for draft-sullivan-cfrg-voprf

Hugo Krawczyk <hugo@ee.technion.ac.il> Wed, 29 May 2019 03:14 UTC

Return-Path: <hugokraw@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 19B901200FB for <cfrg@ietfa.amsl.com>; Tue, 28 May 2019 20:14:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 voDimEYWNNZj for <cfrg@ietfa.amsl.com>; Tue, 28 May 2019 20:14:53 -0700 (PDT)
Received: from mail-it1-f182.google.com (mail-it1-f182.google.com [209.85.166.182]) (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 710C9120105 for <cfrg@irtf.org>; Tue, 28 May 2019 20:14:49 -0700 (PDT)
Received: by mail-it1-f182.google.com with SMTP id i63so1247373ita.3 for <cfrg@irtf.org>; Tue, 28 May 2019 20:14:49 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4yhptblpJXRYFJgtaBylLQej3zz+jGbMO+DTUmmyneQ=; b=PPZDbrNsXj1whzl9j8kforK0GWqR5mnKDi/4353LRg4TkOJ5s0WQ7+WVuxdlih3W+Z tEaYoByH/jsYuouyEASsOjljq9t43FBaAlaexlEhoUi4cx2+7isKmUr0739Jo2GhjZOL Wlbt+ptGo1gDjqPH7RCigE05yHjMiKiqfC55pAq1beA8kCkTe+jPqxDYYZxN53fb1vY+ 8ERbcXd6TvTY53wIYQByo3qN11Muinu4t3T9byGXtkcvvilH8p95cPU7kOFj/yfTQ3X2 geEiXMEkSHiib15meg7SzYrqWiuEyQaf8Fz/jZmjEVvXCBhPp2unOsw8+tBuWZ6cS3U8 /ekg==
X-Gm-Message-State: APjAAAXiODXH2jO5k9Qu4C83j7joYCnWufhSotbI/xQ8YRH1hhiLaC1P deSxOJ4Zp8jraHfDxyhYwo1ugMsXIGUzKSwc9bI=
X-Google-Smtp-Source: APXvYqy+JUGAL3EwtUp2c5IMsZ9PLXPWLAXAXgBMEatlwn1LSjyqwTAdvS0QJb5SOwkJDKOVVKfp7fmIHRSSXZyAt7U=
X-Received: by 2002:a05:660c:7c3:: with SMTP id e3mr994152itl.24.1559099688579; Tue, 28 May 2019 20:14:48 -0700 (PDT)
MIME-Version: 1.0
References: <54235333-9FEA-4543-93B6-2D4B1C8FCC2D@inf.ethz.ch> <0a67411b-9a2d-9e08-ca06-08ea938c0c89@gmail.com> <B62E70D5-9BAE-4332-8CE4-4AB0E3B229C8@inf.ethz.ch> <553170C6-11B3-4287-A033-9C051401F4C1@cloudflare.com> <0E69ED80-2479-4048-BF18-8E1F16EF57CA@gmail.com> <CADi0yUPt8DFG9N+8CxznMcO7JZ78nsCdUTUr+eq6jmrB+Hp2Bw@mail.gmail.com> <B66B1F99-91B9-4234-811A-9A743D2DC89C@gmail.com>
In-Reply-To: <B66B1F99-91B9-4234-811A-9A743D2DC89C@gmail.com>
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
Date: Tue, 28 May 2019 23:14:24 -0400
Message-ID: <CADi0yUPRJGDihe9Fq6XtQV3W_2f81o_qoqum9dPx9kwayduSGA@mail.gmail.com>
To: David Wong <davidwong.crypto@gmail.com>
Cc: Alex Davidson <adavidson=40cloudflare.com@dmarc.ietf.org>, CFRG <cfrg@irtf.org>, "draft-sullivan-cfrg-voprf.authors@ietf.org" <draft-sullivan-cfrg-voprf.authors@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001b77c80589fe2f4c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/4n_b_L7jq1lyCqXbxctXHh2kt_Q>
Subject: Re: [Cfrg] Adoption call for draft-sullivan-cfrg-voprf
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, 29 May 2019 03:14:55 -0000

On Mon, May 27, 2019 at 7:15 PM David Wong <davidwong.crypto@gmail.com>
wrote:

>
>
> On May 20, 2019, at 1:54 PM, Hugo Krawczyk <hugo@ee.technion.ac.il> wrote:
>
> Hi David, to use a V-OPRF the client needs to store the public key Y=kG
> corresponding to the server's OPRF key k. In the OPAQUE setting we do not
> assume that the user carries any public key with her. The only information
> the user carries is the password (and account information where to login).
> This makes OPAQUE immune to PKI failures.
>
> Hugo
>
>
> Hey Hugo,
>
> thank you for providing an answer to my question! Why are we assuming that
> the user does not carry the server’s public key? For some mobile client
> code, the application should be able to pin the server’s public key. For
> web, I’m not sure how this can be done besides using a PKI indeed.
>

It is fine if the user, for a given application, needs to carry a public
key. What I was saying is that OPAQUE does not require to do so. Just
having the password and basic account information is sufficient for OPAQUE
to work securely.


Also, what are the consequences of not being able to verify the server’s
> operation? Intuitively it sounds like the server can target users and force
> them to use a weak key.
>

In OPAQUE, if the user connects to the wrong server (by mistake, by
misconfiguration, by attack, or whatever reason), the password is not at
risk. The server will learn *nothing* about the password and a channel will
not be established since the server will not be able to authenticate to the
user (OPAQUE creates a mutually authenticated channel that only the user
with the correct password and the server with whom the account and password
were initially established can pass authentication).

Hugo


> David
>