IETF Logo Mail Archive

Re: [kitten] complementary OPAQUE SASL mechanism draft

Simon Josefsson <simon@josefsson.org> Sun, 16 October 2022 09:15 UTC

Return-Path: <simon@josefsson.org>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2577FC1522D2 for <kitten@ietfa.amsl.com>; Sun, 16 Oct 2022 02:15:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.108
X-Spam-Level:
X-Spam-Status: No, score=-7.108 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=josefsson.org header.b=aWIY+U2v; dkim=pass (2736-bit key) header.d=josefsson.org header.b=Y0dqK09A
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 qaOjbyFGe8my for <kitten@ietfa.amsl.com>; Sun, 16 Oct 2022 02:14:57 -0700 (PDT)
Received: from uggla.sjd.se (uggla.sjd.se [IPv6:2001:9b1:8633::107]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB97BC1522A3 for <kitten@ietf.org>; Sun, 16 Oct 2022 02:14:56 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=josefsson.org; s=ed2110; h=Content-Type:MIME-Version:Message-ID:In-Reply-To :Date:References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding :Content-ID:Content-Description; bh=ipjzjpW4zFGmMcph9tJ9MrHEqKeZryoXRchGN8DH0qw=; t=1665911696; x=1667121296; b=aWIY+U2vDbP6KQVC75/yhb4K3+0jX9VkaF2IzzqKSilA/g+DpA0BhhyNLzzltABRqaq17rRE0Pd KdiWzVsYjCQ==;
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=josefsson.org; s=rsa2110; h=Content-Type:MIME-Version:Message-ID: In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=ipjzjpW4zFGmMcph9tJ9MrHEqKeZryoXRchGN8DH0qw=; t=1665911696; x=1667121296; b=Y0dqK09Aep1VPBu39JGaYYkL/UVWglCrW6byNZqv1Hvxtj613AROCYz56hcW4erkkEMcGDrVHk+ nhI5zdVZUbxYmxIuDaRLOPsLM2mtgANkwr26ALSTj9MLyjzZGrUA2yCCu7DmiKsznCd0yf4ciNNen VVUKhqe/rX2x2K8AQi9Id34xQvyxuwAbka05h7nkg376thi9eQ20t+jctVCxRItCEr5gX40hsaB3e L8tkQIMCUGWZ4vKgdIFRonFOM02Q4vEdUgJG1tgm8ig9dPAmU5gqMXwP61AZFVEMJm4HiBofVZsES ftZMQ5QCS+9cs2s6SaLM7XFvnZ2+gRVvIe8mdnIhGBO9l+H/TE1LPA50qSi+B1OvH8Y691im/wLr1 JJ8C3HxoGERIXCUtI2vQWRKEo1FW3/V5qsDhoatjpwWdKC4Ht63qd4U19AAnFkGWtFfJneNt/;
Received: from [2001:9b1:41ac:ff00:e3b1:ebc9:51f3:1eaf] (port=52242 helo=latte) by uggla.sjd.se with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <simon@josefsson.org>) id 1ojzjO-008jSX-Sb; Sun, 16 Oct 2022 11:14:50 +0200
From: Simon Josefsson <simon@josefsson.org>
To: Dave Cridland <dave@cridland.net>
Cc: Simo Sorce <simo@redhat.com>, kitten@ietf.org
References: <Y0mWXEZYl2d6/32Z@localhost> <878rlinswv.fsf@latte.josefsson.org> <05d5c01177a294cc21960ec5395fb00630d87f89.camel@redhat.com> <CAKHUCzw6GW8-EWMSnb2q=sj-X4AKwbFAevKXOhS2t4ObtOSNig@mail.gmail.com>
OpenPGP: id=B1D2BD1375BECB784CF4F8C4D73CF638C53C06BE; url=https://josefsson.org/key-20190320.txt
X-Hashcash: 1:22:221016:dave@cridland.net::17Kbv+KIGty++vJ3:1VWG
X-Hashcash: 1:22:221016:kitten@ietf.org::4K7qXNhp0HYe7auB:EZwC
X-Hashcash: 1:22:221016:simo@redhat.com::odlH1ip6a6tv+sEw:WsEu
X-Hashcash: 1:22:221016:simon=40josefsson.org@dmarc.ietf.org::GAy9GEthwig3Q9D4:eq5S
Date: Sun, 16 Oct 2022 11:14:47 +0200
In-Reply-To: <CAKHUCzw6GW8-EWMSnb2q=sj-X4AKwbFAevKXOhS2t4ObtOSNig@mail.gmail.com> (Dave Cridland's message of "Sat, 15 Oct 2022 15:21:28 +0100")
Message-ID: <87fsfob054.fsf@latte.josefsson.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/mj4EMJkdT4gky6wZjo5gdiRhOCQ>
Subject: Re: [kitten] complementary OPAQUE SASL mechanism draft
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Oct 2022 09:15:03 -0000

Dave Cridland <dave@cridland.net> writes:

> On Fri, 14 Oct 2022 at 20:29, Simo Sorce <simo@redhat.com> wrote:
>
>> On Fri, 2022-10-14 at 20:48 +0200, Simon Josefsson wrote:
>> be possible by simply supporting multiple OPAQUE-xyz mechanisms.
>
> Simply??
>
> That continues a long tradition of using the word "simple" ironically in
> the IETF.

Relative simplicity -- it is much easier to migrate between SASL
mechanisms than to migrate between sub-parameters within SASL
mechanisms.

> The XMPP community is throwing around protocol designs for how to "simply"
> transition from one SCRAM hash to another. (Ironically, all the examples
> are just moving to SHA-256).

This reinforces my opinion, right?  That is the kind of migration that I
think is really hard and the cost of introducing the hash agility within
SCRAM cost much more than it was worth.  SASL already has good mechanism
agility, let's use it for algorithm parameters too.

> I really think authentication agility is a hard problem to solve.

Complexity kills it.  We should try to reduce complexity rather than to
add more.  This is much harder and less satisfactory than inventing a
new protocol, so it only happens when the results of adding a new
protocol has added up and people realize that was not a good path to
walk on and start from scratch again.  Eventually we'll get simpler
solutions though, so all is not lost.  Maybe that is an argument to
introduce LOTS of complexity now, so we can fail faster...

/Simon

>
> That said, Simon's assertion that having multiple mechanisms does not
> contribute to this much. It has two effects:
>
> - It makes it look tantalisingly like it's a solved problem, when it's not.
> - When one realises the above, it becomes a more desirable problem to solve
> because there's "more transitions to do".
>
> There's a new SASL profile for XMPP that has a proposal to include a
> generalised mechanism upgrade; I'm not actually sure it belongs there but
> the mechanisms by which OPAQUE (and SCRAM to some extent) can have
> authentication data entries provided by the client without providing actual
> credentials shows some possibility of a way to address this generically.

v2.23.0 | Report a Bug | By Email