[Cfrg] On terminology (and essence): peer-to-peer or client-server

Hugo Krawczyk <hugokraw@gmail.com> Wed, 29 May 2019 03:58 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 693A2120104 for <cfrg@ietfa.amsl.com>; Tue, 28 May 2019 20:58:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 3Hotg03D4jps for <cfrg@ietfa.amsl.com>; Tue, 28 May 2019 20:58:37 -0700 (PDT)
Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 AB803120075 for <cfrg@irtf.org>; Tue, 28 May 2019 20:58:37 -0700 (PDT)
Received: by mail-it1-x12d.google.com with SMTP id a186so1433002itg.0 for <cfrg@irtf.org>; Tue, 28 May 2019 20:58:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=mmr8wsmpPSRNkjRPgf/IGCambF9a7erukVE1XhXxMWU=; b=KmMRKfleBaDHfONdBbAROkBk24a1aQPCazmFFrqmRBXKgcwnr6ap69w2XfMPEnaRoL B/aiWWi6YPo2wBGXsYYJZCr/Ul+9XYvaNkBgHRaSfZgKfsrw2yUWHv7+QSBlSCRPs6mU 4FiUZfKqM5p0x4gJy6Wyd93UMvNbpS6uSg2WQVWGBoktMLJvxeHgK0lI3lh+1w/5cDZy CoFgiaY4pQlNJqtgWmHpmMEE9VTjxNEmMdUAIMQEcwwoZVXymorme/1Vo8tZnOJ2+1nD zeSib2oIX9qMOQ0m96FFhcx6yKUXwu+mdZHNQ+X135H6xYbBDNOsy46QWhVEcf4tNXxj PMkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=mmr8wsmpPSRNkjRPgf/IGCambF9a7erukVE1XhXxMWU=; b=fwiJrcNEwAlY/RGyixIpEYJBX028FYkOnn9FeuHWW7LLAueFS5MAqMgLqmWmu5caA+ UQDFfNwrt4qWhhuTMfaEn7w11p7g9s6uv9Pi5HuKN1GiXCm2sqPOgQykp/fNcS4R3GJq F1775x2Zi1nelyKaQ99p8v7aefVXgj6myr0+MNU1Scf8ENZALgr1CJ8ZA9D4np8a1iFI bF/uL5k1e0i0xYStPl5hxTorPK+AStLaJMAh/9kRTnVP43OVRyW1OB1MmzdcS0BWIGi2 pHLA+rjGpxmU90GR0BkdQtHk3cOG6NkwtxJ3bz2rPTF6qVXtGRvLVJgqbt2Fh1gRicfG tFiA==
X-Gm-Message-State: APjAAAWMKaP/dH14vcYkhHqsPWE/OYWk9ND2veghlFUSLjr1AXAxfNjS pNnCeomw5K2ooCpR31jsl4osLbMkSxFqHYi2GcveAIw0QAw=
X-Google-Smtp-Source: APXvYqw0pai7tT5+fi3pdDvYedeH66vWpi4th8YI1lfw1vnjdFOmr4mbUTJf7jRyCXpgK0f8HFqgaweb4UlFowHBD6E=
X-Received: by 2002:a05:660c:7c3:: with SMTP id e3mr1082968itl.24.1559102316515; Tue, 28 May 2019 20:58:36 -0700 (PDT)
MIME-Version: 1.0
From: Hugo Krawczyk <hugokraw@gmail.com>
Date: Tue, 28 May 2019 23:58:12 -0400
Message-ID: <CADi0yUOECGWvXtFYaXPkb=kMkx2r7mXWJ5MDwD6rHspTcCDYsw@mail.gmail.com>
To: CFRG <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="000000000000be96cb0589fecbbb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/xSzmkALdyYVzK-FhzoFVqnXsRTg>
Subject: [Cfrg] On terminology (and essence): peer-to-peer or client-server
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:58:39 -0000

It is very important that when people propose or discuss specific PAKE
protocols and applications, that they distinguish between those intended
for "peer communication" (where both ends share the same password) and
those for the client-server case (where the server does not store the
password but only a one-way function of the password).

These are different types of protocols, for different settings, different
security goals and  definitions, and quite different designs. In
particular, they cover very different applications (the client-server
setting is where most uses of passwords are found while the peer case seems
of more  restricted applicability, at least in the past).

It would be very helpful if we developed some common terminology for
differentiating these two settings. Unfortunately, there are many different
names people have been using. I like to call them "symmetric" (for the peer
case) and "asymmetric" (for the client-server case), but we have also
balanced and unbalanced, plain PAKE for the peer case and augmented PAKE
for the client server and more (e.g. "Verifier-based" for the asymmetric
case).

It would be good to set some conventions here.

But regardless of names, the most important point is to make clear to what
setting one refers when discussing specific protocols and applications.

Hugo