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 --
- Re: deprecating Postel's principle - considered h… Keith Moore
- Re: deprecating Postel's principle - considered h… Doug Royer
- Re: deprecating Postel's principle - considered h… Eric Rescorla
- Re: deprecating Postel's principle - considered h… Doug Royer
- Re: deprecating Postel's principle - considered h… Ted Lemon
- Re: deprecating Postel's principle - considered h… Eliot Lear
- Re: deprecating Postel's principle - considered h… Ted Lemon
- Re: deprecating Postel's principle - considered h… Doug Royer
- Re: deprecating Postel's principle - considered h… Eric Rescorla
- Re: deprecating Postel's principle - considered h… Ted Hardie
- Re: deprecating Postel's principle - considered h… Phillip Hallam-Baker
- Re: deprecating Postel's principle - considered h… Nico Williams
- Re: deprecating Postel's principle - considered h… Phillip Hallam-Baker
- Re: deprecating Postel's principle - considered h… Nico Williams
- Re: deprecating Postel's principle - considered h… Keith Moore
- Re: deprecating Postel's principle - considered h… Bron Gondwana
- Re: deprecating Postel's principle - considered h… Keith Moore
- Re: deprecating Postel's principle - considered h… Nico Williams
- Re: deprecating Postel's principle - considered h… ned+ietf
- Re: deprecating Postel's principle - considered h… Ted Lemon
- Re: deprecating Postel's principle - considered h… Michael Richardson
- Re: deprecating Postel's principle - considered h… Michael Richardson
- Re: deprecating Postel's principle - considered h… Joel M. Halpern
- Re: deprecating Postel's principle - considered h… Eric Rescorla
- Re: deprecating Postel's principle - considered h… Joel M. Halpern
- Re: deprecating Postel's principle - considered h… Keith Moore
- Re: deprecating Postel's principle - considered h… Eliot Lear
- Re: deprecating Postel's principle - considered h… Martin Thomson
- Re: deprecating Postel's principle - considered h… Eliot Lear
- Re: deprecating Postel's principle - considered h… ned+ietf