Re: [OAUTH-WG] We appear to still be litigating OAuth, oops

Bron Gondwana <brong@fastmailteam.com> Wed, 24 February 2021 11:39 UTC

Return-Path: <brong@fastmailteam.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F09A3A1446; Wed, 24 Feb 2021 03:39:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=bdABPhpu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cwGjBewA
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 3aNBwz7CTccJ; Wed, 24 Feb 2021 03:39:55 -0800 (PST)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8804B3A1448; Wed, 24 Feb 2021 03:39:35 -0800 (PST)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 80CE3B47; Wed, 24 Feb 2021 06:39:34 -0500 (EST)
Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Wed, 24 Feb 2021 06:39:34 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm2; bh=yUvd npoJwPRzXPxDZkv1rG4dmLCfYIfChuY8x0ZL3OE=; b=bdABPhpu35BVXcEfUO4w dnvwYrHFvrK3ui283ludaN0yUNpWF4aFvT1GAHbjGpBQwkp4lZ2Tq1u8cCB0tTet 9GT4IS9fs4eGtXGkTl5aDprtI+MnZgF12G513yh3Ny9LlJU8Xg5u6s+ExZdLcQDA AHPye2AXnU0zsL9nmcQy0jGsv/lxkNZY19j6btIN1bLLvki0VYjUYSjfy/pMZZ2k nqmFKPIDRMfVqgJHJPkCh1o/sJU0OIvmfYA6OpY9lT4O9CHd00UXBoG4we938Hxm KlskEFK8ucO1j1iCgA6j2W1fJMeMskELMDhKPohyvbxlaJyWbkczc0Bv7G5pr19J 5w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=yUvdnp oJwPRzXPxDZkv1rG4dmLCfYIfChuY8x0ZL3OE=; b=cwGjBewAXsa46JeIV4OIRV WXU2t1eAPKvQWSMckYY2BEgVnbcIcKdEyieTy3CzAJhTiNiySCUQXfttYrlQjYnF mtfV0C1HHPFUM4MotCK8Szovl6LRCKfsxj4T6IpVpe6RWC9TbmTbYYEPu7sFs9yS b6rJwoPxomp7VHnDWVQBURSpJ8c5P7vPDI1CDCpRU4xeHhwcBnAjbVL6YyNVcQgp ZKIVRF1cZII5ooMst9E1cg4E3YNeBy2GH2qLUcV17ALargrKvsW+zhipCCkFNwme HS2EsZOPEOOUEfEgfdCZduigH0sNxE4T8v2y478D9fTJT4F8mmgmelBitsZl7vww ==
X-ME-Sender: <xms:9Do2YJdi7DlEGnlrZmcGCMiIOH_L0WgayKnptEFwgzncADzWqLpeNg> <xme:9Do2YHPAYycwTM-Oem_0N5TxDIwUmbqepR29rSwB6eJLiO10KoT753dKvQzKLHeF0 1PlaXi65qQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrkeejgdeftdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfuehrohhn ucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucggtffrrghtthgvrhhnpedugefhlefghfeigeegueekhfekjeeludevuedvfeehvdeg tdejueetffeufefgtdenucffohhmrghinhepfhgrshhtmhgrihhlrdhhvghlphenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomh
X-ME-Proxy: <xmx:9Do2YCibxH97IkkWx6iH2y-oZPpf8s8pMfhVtMDPEKsvq1YJnYFhyg> <xmx:9Do2YC9s3wf6XKNI0KRFKZEIU9jOirna3KEBj0AaPOpqtPqX-eaRcg> <xmx:9Do2YFsO687J56t76Ru_nOsASadqPY8J3uuGFNZwL8lVCxRgJs57mw> <xmx:9jo2YO5rKf9TGd3Zur0FbuUcEITkU5MHFPWrldASH7rXatUABwqx6A>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id E7CF23605A5; Wed, 24 Feb 2021 06:39:32 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-179-g81f7aba968-fm-20210222.002-g81f7aba9
Mime-Version: 1.0
Message-Id: <66be0ffe-a638-45a0-ba05-1585ea02e6bf@www.fastmail.com>
In-Reply-To: <CAJot-L1e8GegjXjADRQ87tGqnSREoO4bEKLX+kPkZFsQpevGQA@mail.gmail.com>
References: <CAMm+LwgbK3HYDjSHnTN3f6hWSQCQrEjHLNn6z0JpfY7hdxaQpg@mail.gmail.com> <A8128346-B557-472F-B94F-8F624F955FCE@manicode.com> <eb2eaaa7-7f7e-4170-ab87-1cc1fdd3359b@www.fastmail.com> <CAJot-L0PS_3LxEkC-jd1aqXDdYF+z8BajSs4Rhx3LgRPn6wkdQ@mail.gmail.com> <DAB127D7-809F-4EC2-A043-9B15E2DB8E07@tzi.org> <CAJot-L1e8GegjXjADRQ87tGqnSREoO4bEKLX+kPkZFsQpevGQA@mail.gmail.com>
Date: Wed, 24 Feb 2021 22:39:11 +1100
From: "Bron Gondwana" <brong@fastmailteam.com>
To: "Warren Parad" <wparad@rhosys.ch>, "Carsten Bormann" <cabo@tzi.org>
Cc: "Phillip Hallam-Baker" <phill@hallambaker.com>, "oauth@ietf.org" <oauth@ietf.org>, ietf@ietf.org
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
Content-Type: multipart/alternative; boundary=6413e81e2f034588a4c333892e4c5dd8
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/hH5OEZ3u0MVifd1ZmQ-shak9EEE>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Feb 2021 11:39:57 -0000

On Wed, Feb 24, 2021, at 22:04, Warren Parad wrote:
> I would prefer Bron to answer that question, as they are the one who started this email thread.

You can also use he when talking about me, or she for that matter - I do enough group fitness classes where it's roughly assumed that the entire class is female, and I have an ambiguous enough name that I'm used to it.  Most people use "he" most of the time.

> However let's look at GNAP, I've honestly been struggling to understand at least one fully documented case that GNAP supports. It seems in every document the only thing that is clear is GNAP wants to allow "everything", doesn't actually talk about an example.

That's my biggest fear for GNAP - it too will try to be everything to everybody and wind up being nothing to nobody because the super flexible "everything protocol" is the same as no protocol at all, since you have to special-case everybody you talk to anyway.

> By NxM, I assume we mean that the end user or client is free to select whichever AS they want, in a way which the RS can verify the AS credential and the user identity, without the RS having to (and really without the ability to limit) which AS are allowed.

Let's get down to use cases then, rather than talking in abstracts.

I'm an end user with a copy of {The Bat email client} and I want to connect it to {Gmail} + {Yahoo} + {My ISP}.  It supports {POP3}, a widely popular open standard.  I want to be able to authenticate to each of those services without saving my plaintext passwords on my hard disk where the next {Windows ME} virus will exfiltrate them to {Noextraditionistan} and all my {Dogecoin} will then be exfiltrated from my {Paybuddy} account, leaving me destitute.

But, {The Bat} doesn't have a trusted client cert from my isp, because who does - so there's no good protocol for me - it's either plaintext auth, or it's some architecture astronaut multi-party nonsense that's massively over specified and doesn't work half the time.  So I write a plain text password on a post-it note which is lying in the dust under my monitor because the glue has gone bad, and I hope I never accidentally click "remember me" when I type it in.

That's been the reality of the end user experience for very many years.

NxM means that you can authenticate an arbitrary client against an arbitrary server so long as they are both speaking a known public protocol, without needing to build a trust relationship between the client vendor and the server vendor first.

Any "trust relationship" is made through a user both who trusts the client and trusts the server, and it's not transitive over to other users of the same client and the same server.  The client author doesn't need to get a signed "I trust you" from every single server, and the server author doesn't have to go identify every single client.

That's what NxM means to a user, the ability to use arbitrary clients with arbitrary servers so long as they both implement a documented protocol.  Interoperability.

OAuth has not given interoperability in the NxM sense outside some simple web use cases.  They're nice and all, but they don't tend to be useful with open protocols - OAuth gets used for accessing proprietary API endpoints after getting an access key for a single provider.  At least you get Nx1 or 1xM out of it depending who's the N and who's the M, and maybe some of your code can rhyme so you're not doing everything from scratch each time.

This is the sorry story of real open protocols.  The floor for true interoperability is still username + password over cleartext, over hopefully a TLS tunnel that's providing some level of protection.  Most so than a few years ago when Fastmail wrote our "starttls considered harmful"[1] objection to the IETF's habit at the time of putting a "STARTTLS" upgrade into an initially plaintext protocol, where an active intercepter could just strip the "I support STARTTLS" indicator from the protocol and convince the client to send the credentials in the clear.

We're a little better mostly these days, but it's still a tirefire, and in my heart I do hold the OAuth working group's squatting on this area of the landscape while failing to address this burning need partially responsible.  The result (as Phillip pointed out upthread) has been a consolidation towards a few big players - because NxM becomes tractable when you reduce the N and M to small enough numbers.

Bron.

[1] https://www.fastmail.help/hc/en-us/articles/360058753834-SSL-TLS-and-STARTTLS

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com