Re: [Secdispatch] I-D on dealing with the 3xx XOR 401 problem

Nico Williams <nico@cryptonector.com> Tue, 31 March 2020 05:00 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D689E3A1B01 for <secdispatch@ietfa.amsl.com>; Mon, 30 Mar 2020 22:00:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level:
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 tzDHwLxr_brR for <secdispatch@ietfa.amsl.com>; Mon, 30 Mar 2020 22:00:08 -0700 (PDT)
Received: from dragonfly.birch.relay.mailchannels.net (dragonfly.birch.relay.mailchannels.net [23.83.209.51]) (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 5DC463A0C75 for <secdispatch@ietf.org>; Mon, 30 Mar 2020 22:00:02 -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 A21B5100D13; Tue, 31 Mar 2020 05:00:01 +0000 (UTC)
Received: from pdx1-sub0-mail-a18.g.dreamhost.com (100-96-9-10.trex.outbound.svc.cluster.local [100.96.9.10]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 1581E100880; Tue, 31 Mar 2020 05:00:01 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a18.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.18.6); Tue, 31 Mar 2020 05:00:01 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Tasty-Descriptive: 00ee9aeb2ef1f99c_1585630801490_1776198837
X-MC-Loop-Signature: 1585630801490:1937684565
X-MC-Ingress-Time: 1585630801489
Received: from pdx1-sub0-mail-a18.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a18.g.dreamhost.com (Postfix) with ESMTP id A534AB26A8; Mon, 30 Mar 2020 22:00:00 -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; s=cryptonector.com; bh=HaDnLC1lgnBScE FtrjjXypZY9aw=; b=nBAzay9qPq8b4WrmWNM18HQ3nZZTVWiVGtTyu745t4wkT3 JXKwwcF/EkC13E1CNR1JOIIcQ5Ke1ICGGqq3mKOm00c8r0VU75qMvbu5LKvAOtrc q8GJw1T+tn/B5/dnf/XGd0Ml7emWTta6Np9xtzi1/z1cRGhJWTOqrkMWinoN8=
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-a18.g.dreamhost.com (Postfix) with ESMTPSA id 6FD91B26A2; Mon, 30 Mar 2020 21:59:57 -0700 (PDT)
Date: Mon, 30 Mar 2020 23:59:54 -0500
X-DH-BACKEND: pdx1-sub0-mail-a18
From: Nico Williams <nico@cryptonector.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: ietf-http-wg@w3.org, secdispatch@ietf.org
Message-ID: <20200331045953.GP18021@localhost>
References: <20200329043333.GO18021@localhost> <20200331020629.GD50174@kduck.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200331020629.GD50174@kduck.mit.edu>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: -100
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedrudeiiedgkeekucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/k38JPI9Q4JgMlwBOsImriKAkxVY>
Subject: Re: [Secdispatch] I-D on dealing with the 3xx XOR 401 problem
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Mar 2020 05:00:13 -0000

On Mon, Mar 30, 2020 at 07:06:29PM -0700, Benjamin Kaduk wrote:
> On Sat, Mar 28, 2020 at 11:37:48PM -0500, Nico Williams wrote:
> > This I-D then adds an Accept-Auth request header, and an HTTP
> 
> Interestingly, I was just thinking about whether such an Accept-Auth
> header would be useful in the context of Rick's SASL proposal that was
> presented at SECDISPATCH last week.  Perhaps along with a way for the
> server to annotate that various (e.g., linked) resources will require
> a given authentication mechanism, there might be a route to improving

The server isn't going to want to authenticate the user differently for
different resources -- authorize differently, yes, but probably still
with the same scheme.

> the UX in this space ... though there's a long way for it to go, so I
> don't know that these in and of themselves will make a huge
> difference.

I don't quite follow.  There's lots more work to do about UX?  Sure.
But I know this header will make a huge difference for sites where
there's a mix of Negotiate and Bearer -- it's absolutely essential for
the server to know which (if either, possibly both) are supported.  So
I'd very much like to move forward with registering the header by
requesting Expert Review for it.

What about the Redirect scheme?  Have I missed something important?
That will require IETF Review.  I've added security considerations text
in my GH repo for this, nicowilliams/accept-auth-and-redirect, FYI.

Nico
--