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

Watson Ladd <watsonbladd@gmail.com> Mon, 27 May 2024 20:49 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 54843C14CE52 for <cfrg@ietfa.amsl.com>; Mon, 27 May 2024 13:49:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jib6nO1mzYqk for <cfrg@ietfa.amsl.com>; Mon, 27 May 2024 13:49:30 -0700 (PDT)
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 97749C14F6B9 for <cfrg@irtf.org>; Mon, 27 May 2024 13:49:30 -0700 (PDT)
Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-421124a04d6so914335e9.3 for <cfrg@irtf.org>; Mon, 27 May 2024 13:49:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716842969; x=1717447769; darn=irtf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=6cmOGo5D/OnU5sINVfszLWQmX6jKbkI5RFUzZPQZYWk=; b=l5Ic2Uc+FAGvDhpXF+nhTIwNflZu7McVfLFczqBcSf+2Tw78U5Irx47FsIKeoKnDep uC8J7ld4BuIrlGM4HsQn9wVF7Y9vVE2yLj+DJ0dNZgMdf7T2lNWQfC7ciAYAIC7kEmYc cDdHx8t5pnQZjkFk6KL2E6ENzS+UED/TXpTx4reTxjMKghThI0HhU2jVq+O+AawCA8Z4 mv07QS/xAPwLgjLlHGqD+xz3OlrntMiCC5FYBSMcRDDHTk1PQXz/UiVQD12uRKFAWWnc JnovewyeXF7mKqCxtkIgOy+tU7mjTyJAouQhK4qRDSE85PyyfY8vvWwmvC++2xBuusN2 bRwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716842969; x=1717447769; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=6cmOGo5D/OnU5sINVfszLWQmX6jKbkI5RFUzZPQZYWk=; b=fTIlCfYXA0TAMpRdyk2r9CvAUxroqLPdK7sZLUIb07tvtjLmnTf0Fb54yHiDt7TULM dzv0kGM3HVEt5LDitRl/BdGB3Q00BcvJnmJrXh/U3dYfS7f9oN1dseFMe1IgjaecUmsk g8SZVNYd1Q8PaGkC/8lL00ZVsXbBtNwHMX7pjaICbVi70DHL2QsdWnIJc7N/BDR+qHfB vQMn8scUjeRgIxG0LbB/ra0nlWE+0I62OGaQdjwxhHnJlV3eq2wojaDRmn8BJk9WQSXa KeovtaKeoLCTSK1KAsceNjd1MuZfYqdVE1dbmfHsi6dKoj43JJhUg1WNAPyArjenTvQx fmcw==
X-Forwarded-Encrypted: i=1; AJvYcCWPTBI+RRB1wg0cyPD0Si/q0U7yg6JMRXShEoeRE7Afh7AxwGmuJ5d3wWYJcKBlqI15/lMmEn0Mracr0j8F
X-Gm-Message-State: AOJu0YwRJu1gVIwR2g3n3xaO4MqsVkqmjieJlsZ8We+SKfakCzs2+Enz 8S1wupVRCzdMHkbr09l3ERXFuIfDHjzqcEJ6ETm7n4tiUhlg6rPCD2rq2wgH2t8FD2ytj0jWCkx nHnAAIZGWG/Xto7CQtLpYSpNxCNk=
X-Google-Smtp-Source: AGHT+IHlSTbuaHRakSopPkY8CJJcf5NSJGOpgmvXcF5LIhCvbFMY+bajdHGaIU9vL8F70YALKH3nOcfEyJI+u/+mkmc=
X-Received: by 2002:a05:600c:4f88:b0:41c:97e:2100 with SMTP id 5b1f17b1804b1-421089d3accmr83561345e9.3.1716842968576; Mon, 27 May 2024 13:49:28 -0700 (PDT)
MIME-Version: 1.0
References: <CADi0yUNbiVTe9BaoCFgDaTC06Z1LMAx6q2hJDiWydpy6xFqtRQ@mail.gmail.com> <GV1PR01MB8436B6B6B75DEBC9F1FB30A9D6EA2@GV1PR01MB8436.eurprd01.prod.exchangelabs.com> <CADi0yUNCkk8Y5dQJH6DjR33cP7KXXrQsmHfA0UDRxjGuoXCaLA@mail.gmail.com> <GV1PR01MB8436DBCC8F5B167B0B44490AD6EA2@GV1PR01MB8436.eurprd01.prod.exchangelabs.com> <CADi0yUPcyc9oSM4NqWynkWuTPStnD9yqt4XwmAg7c=XjCtik4A@mail.gmail.com> <GV1PR01MB84364908B61E293E46012214D6EB2@GV1PR01MB8436.eurprd01.prod.exchangelabs.com> <CADi0yUOtSBmCnQMP-MoyzzxF6LZQcrKfo03sN2cNuO6MS74NAg@mail.gmail.com> <GV1PR01MB84361129416DC8B621CAAEDFD6F42@GV1PR01MB8436.eurprd01.prod.exchangelabs.com> <y5y4iquyvrao7jtpyc2ycjtz4sg5dbzhrhddz5j6rv3eydyd2o@zy65yreteuoh> <GV1PR01MB8436B919FE24E2E022639155D6F52@GV1PR01MB8436.eurprd01.prod.exchangelabs.com> <2dhbnlfzwgllzqc7farahxqkct3zqcoi7wdj7vybivlzzwxrei@e7phsvy5i6ae> <GV1PR01MB843618C88187FE124B1F142ED6F02@GV1PR01MB8436.eurprd01.prod.exchangelabs.com>
In-Reply-To: <GV1PR01MB843618C88187FE124B1F142ED6F02@GV1PR01MB8436.eurprd01.prod.exchangelabs.com>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Mon, 27 May 2024 16:49:17 -0400
Message-ID: <CACsn0c=M5OofNyG8YhO4vYOWwFvZW9yLpwMGMXkkDrXZ=Ty1jw@mail.gmail.com>
To: "Hao, Feng" <Feng.Hao=40warwick.ac.uk@dmarc.ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: IOCMSIXZNJ2J4LABYIW4MDK2YFL5N7KF
X-Message-ID-Hash: IOCMSIXZNJ2J4LABYIW4MDK2YFL5N7KF
X-MailFrom: watsonbladd@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-cfrg.irtf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "Riad S. Wahby" <riad@cmu.edu>, IRTF CFRG <cfrg@irtf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [CFRG] Re: RGLC on draft-irtf-cfrg-opaque-13
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/ykV6Gdq09x9wq79f9JXZRYDHpTk>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Owner: <mailto:cfrg-owner@irtf.org>
List-Post: <mailto:cfrg@irtf.org>
List-Subscribe: <mailto:cfrg-join@irtf.org>
List-Unsubscribe: <mailto:cfrg-leave@irtf.org>

On Mon, May 27, 2024 at 6:13 AM Hao, Feng
<Feng.Hao=40warwick.ac.uk@dmarc.ietf.org> wrote:
>
> Hi Riad,
>
>
>
> The factual difference between OPAQUE and SRP-6a is that in OPAQUE, the server is authenticated first, whilst in SRP-6a, the client is authenticated first. The order of authentication has a profound implication in security here. For the case of OPAQUE, the server leaks password verification information via the key confirmation string in the 2nd pass before the client is authenticated. If the client drops out, the server can’t distinguish legitimate drop-outs from online guessing attacks. This means that the server has to deal with false positives (denying legitimate users hence causing the DoS attack to its own users) and false negatives (letting an attacker guess the password without being detected or logged). Managing the false positive and false negative can be complicated in practice.

Huh? An attacker can always carry out the full protocol to guess to
lock someone out. That a query amounts to a guess doesn't really
change this.

-- 
Astra mortemque praestare gradatim