Re: deprecating Postel's principle - considered harmful

Nico Williams <nico@cryptonector.com> Sat, 11 May 2019 00:24 UTC

Return-Path: <nico@cryptonector.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 675EA12032C for <ietf@ietfa.amsl.com>; Fri, 10 May 2019 17:24:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 Urape0uU6Vg9 for <ietf@ietfa.amsl.com>; Fri, 10 May 2019 17:24:25 -0700 (PDT)
Received: from orchid.birch.relay.mailchannels.net (orchid.birch.relay.mailchannels.net [23.83.209.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBBD1120692 for <ietf@ietf.org>; Fri, 10 May 2019 16:34:36 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id BCAAB5C44C9; Fri, 10 May 2019 23:34:32 +0000 (UTC)
Received: from pdx1-sub0-mail-a19.g.dreamhost.com (unknown [100.96.16.23]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 6A4175C38F1; Fri, 10 May 2019 23:34:32 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a19.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Fri, 10 May 2019 23:34:32 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Whispering-Language: 7ad653364cb829bd_1557531272595_3572726229
X-MC-Loop-Signature: 1557531272595:40418024
X-MC-Ingress-Time: 1557531272594
Received: from pdx1-sub0-mail-a19.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a19.g.dreamhost.com (Postfix) with ESMTP id 0597C80A70; Fri, 10 May 2019 16:34:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=FURJvzd6TJpBKd9E+DQwuzoo0mU=; b=mz5MwkrmSzY 76Lppoqo/Z/5KIY8K6wQ3YuFXki4RuABaqY7F9nJ2aFxIoCbjsil8UkLlPSsksbL KJVVUVFqDpAKzlBkBVite9/Ve6XuTGyGLp75I2Pyfif2O/J3xWH+JqeH+XVumUqG 1cSs0FdyWzTBYXnSb6ORHLsx2I21AAxo=
Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a19.g.dreamhost.com (Postfix) with ESMTPSA id BA09C8076A; Fri, 10 May 2019 16:34:27 -0700 (PDT)
Date: Fri, 10 May 2019 18:34:24 -0500
X-DH-BACKEND: pdx1-sub0-mail-a19
From: Nico Williams <nico@cryptonector.com>
To: Keith Moore <moore@network-heretics.com>
Cc: ietf@ietf.org
Subject: Re: deprecating Postel's principle - considered harmful
Message-ID: <20190510233424.GA21049@localhost>
References: <4255f805-9d9e-10a0-e6be-309779a33d26@network-heretics.com> <CAMm+LwgrVQtjLuwCyeyFpEzNzLwnYhoMjc0POdZSE8MwtetioA@mail.gmail.com> <20190510214417.GY21049@localhost> <CAMm+LwgXPzF0K08jN2y4yY+Uv1879vU1PxJTOoa9y4Jhu5G_Cg@mail.gmail.com> <20190510224746.GZ21049@localhost> <5da942c1-8f51-4e56-ab24-365a69ec587f@network-heretics.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
In-Reply-To: <5da942c1-8f51-4e56-ab24-365a69ec587f@network-heretics.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: -100
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrkeelgddvgecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggugfgjfgesthekredttderudenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/RyXwJyZRdet9bCzbepldN2mVRZs>
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: Sat, 11 May 2019 00:24:28 -0000

On Fri, May 10, 2019 at 07:14:52PM -0400, Keith Moore wrote:
> On 5/10/19 6:47 PM, Nico Williams wrote:
> > This is also why 3xx redirect-based authentication methods are winning
> > over as-originally-intended 401 / WWW-Authenticate / Authorization
> > methods.  It's easier to implement redirect chasing than to implement a
> > pluggable authentication method framework.  (Also, it's easier on server
> > devs to use redirects.)  I just wish 3xx and 401 weren't mutually
> > exclusive.  I posted to art@ietf.org a few weeks ago about that got no
> > replies, sadly.
> 
> It has long seemed to me that the early available 401-based methods (by
> which I mean the ones available in browsers from mid to late 1990s) failed
> largely because of their inflexibility and relatively poor user experience
> provided by the browsers, and especially because avoiding 401 altogether and
> using redirects and cookies instead allowed each site to customize the login
> user experience.   Then the latter became widely held mindshare that
> redirects and cookies are how you do authentication.   [...]

There are lots of problems with HTTP authentication driving the move to
3xx redirects, no doubt.

The problem I have is that a server that can do both, 3xx- and 401-based
authentication has to pick one without knowing which (if any) the
user-agent can also do.

"Only do 3xx" is not a good answer: it has driven "API keys" into
existence because non-browser, non-interactive apps can't do what
browsers with a human user in front of them can, and API keys are not a
step up, especially not if you have a Kerberos infrastructure that works
like a well-oiled machine.  Kerberos has a lot of problems, and is not
an Internet-scale protocol, but as it happens GSS-API w/ Kerberos is
quite well supported outside HTTP apps (and even there), so 3xx ends up
driving a step-down into API keys, and in some cases too a need to have
multiple names for the same service.

I do not object to 3xx-based authentication.  I just want a better way
to support everything that works.

Nico
--