Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

Henrik Nordström <henrik@henriknordstrom.net> Wed, 29 February 2012 20:11 UTC

Return-Path: <henrik@henriknordstrom.net>
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 37B8521F85F9; Wed, 29 Feb 2012 12:11:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mo68nGQ93WoC; Wed, 29 Feb 2012 12:11:07 -0800 (PST)
Received: from vps1.henriknordstrom.net (vps1.henriknordstrom.net [IPv6:2a02:750:7::d0a]) by ietfa.amsl.com (Postfix) with ESMTP id 733A421E8032; Wed, 29 Feb 2012 12:11:07 -0800 (PST)
Received: from home.hno.se (home.hno.se [IPv6:2001:470:df90::1]) (authenticated bits=128) by vps1.henriknordstrom.net (8.14.2/8.14.2/Debian-2build1) with ESMTP id q1TKB2l2005434; Wed, 29 Feb 2012 20:11:03 GMT
Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by home.hno.se (8.14.5/8.14.5) with ESMTP id q1TKB0pK030112; Wed, 29 Feb 2012 21:11:00 +0100
Message-ID: <1330546260.24673.37.camel@home.hno.se>
Subject: Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)
From: Henrik Nordström <henrik@henriknordstrom.net>
To: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 29 Feb 2012 21:11:00 +0100
In-Reply-To: <4F49271C.5030509@gmx.de>
References: <CB6A507F.13D92%ietfdbh@comcast.net> <DDD5CAD5-AB39-4DEE-BD4B-46AB4138AF05@vpnc.org> <4F452842.3050905@stpeter.im> <F4187EC0-40EA-4DAA-B232-D28C7A43288B@gbiv.com> <CAHBU6ivfNaAXsh-x5kqzUnzRfoPpr00COHz3oi2tWRcxgPZfxQ@mail.gmail.com> <C761AFCD-BCD7-45EE-9D89-FB568ABEE53A@gbiv.com> <4F478872.8020103@cs.tcd.ie> <8B377788-1995-4F38-88A8-E33C2FBFD2E5@mnot.net> <4F48E62C.5020902@cs.tcd.ie> <4F48EA4B.6050500@gmx.de> <4F48EC87.4040302@cs.tcd.ie> <4F48EE34.3020504@gmx.de> <4F491E02.9020207@cs.tcd.ie> <4F49271C.5030509@gmx.de>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.2.3 (3.2.3-1.fc16)
Content-Transfer-Encoding: 8bit
Mime-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (vps1.henriknordstrom.net [IPv6:2a02:750:7::d0a]); Wed, 29 Feb 2012 20:11:03 +0000 (UTC)
X-Mailman-Approved-At: Thu, 01 Mar 2012 08:18:30 -0800
Cc: IETF-Discussion <ietf@ietf.org>, "Roy T. Fielding" <fielding@gbiv.com>, Paul Hoffman <paul.hoffman@vpnc.org>, Mark Nottingham <mnot@mnot.net>, Tim Bray <tbray@textuality.com>, The IESG <iesg@ietf.org>, ietf-http-wg@w3.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 29 Feb 2012 22:37:01 -0000

lör 2012-02-25 klockan 19:23 +0100 skrev Julian Reschke:
> Well, I'm one of the editors of the authentication framework spec, so if 
> there's something wrong with it, I'd like to know.

Only the thing said earluer

- Define how servers may influence the visible appearance of the login
action

- Perhaps some way of triggering a logout.

> So if we collectively think that the framework probably is ok, and that 
> we *do* need a new authentication scheme, what's stopping us to start 
> that activity *right now*?

Nothing.

A cleaned up http digest with less fancy bells no one implements
correctly and stronger methods would do nicely at improving the raw
security side of things.

But at the same time it alone does solve the reasons why HTTP Digest is
not widely used today which is or any of the newer use cases with auth
delegation via trusted third parties.

A very interesting thought is to look into how for example Kerberos
could be implemented as a first class HTTP Auth citizen without
violating HTTP messaging semantics. Is there anything needed at the
framework side for making that work right?

Regards
Henrik