From discuss-bounces@apps.ietf.org Fri Jun 01 00:19:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htybw-0006Jd-R1; Fri, 01 Jun 2007 00:19:36 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Htybv-0006JS-Ie for discuss-confirm+ok@megatron.ietf.org; Fri, 01 Jun 2007 00:19:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htybv-0006JK-8d for discuss@apps.ietf.org; Fri, 01 Jun 2007 00:19:35 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htybt-0008Lp-TV for discuss@apps.ietf.org; Fri, 01 Jun 2007 00:19:35 -0400 Received: from [127.0.0.1] (unknown [216.145.54.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id C8BAF5197F; Fri, 1 Jun 2007 00:19:29 -0400 (EDT) In-Reply-To: <4C044C0E-C6B8-4816-9243-FAB72DA5F24F@gbiv.com> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <1358AF2C-F967-46D6-B291-BC65126CCDF6@gbiv.com> <8FBD37BC-E635-485D-A368-22D9DE332498@mnot.net> <68fba5c50705311804w2d39ea88o985d9b6a8aa33220@mail.gmail.com> <6C26C1C5-B99B-41EA-989A-F86DCF8489FC@mnot.net> <4C044C0E-C6B8-4816-9243-FAB72DA5F24F@gbiv.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7E09FD13-FA92-474F-B394-C732393EF354@mnot.net> Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: Straw-man charter for http-bis Date: Fri, 1 Jun 2007 14:19:25 +1000 To: Roy T. Fielding X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: Apps Discuss , "ietf-http-wg@w3.org Group" , Robert Sayre X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On 01/06/2007, at 12:25 PM, Roy T. Fielding wrote: Taking a stab at what that might look like in 2616 terms: > I am talking about splitting the document into > > messaging 4, 5, 6, 7, 9, 10, various parts of 3, parts of the relevant header defs in 14 > conditional requests and range requests 3.12, parts of 10.3.5 and 10.2.7, parts of the relevant header defs in 14 > caching and cache control 13, parts of the relevant header defs in 14 > content negotiation 12, parts of the relevant header defs in 14 > http and https URIs 3.2 > HTTP implementation guide for TCP transports 8, parts of the relevant header defs in 14 > to go along with > > authentication and access control 11, parts of the relevant header defs in 14 Is that in the ballpark? Couple of questions; 1) If going down this path, my intuition would be to continue having sections dedicated to lists of headers, status codes, methods, etc., but to limit them to syntax and base semantics, while pushing the protocol-related parts (e.g., the mechanics of caching, conditional requests, etc.) into the separate sections. Is that what you had in mind? 2) With the exception of the impact of (1), the above seems like relatively straightforward rearrangement. Did you just have rearrangement in mind (perhaps with new introductory text), or did you want deeper changes? > and then replacing the BNF with ABNF Already on the table. > removing the (relatively few) > parts of the document that specify server implementation instead of > interface requirements in the method definitions Could you please raise this as an issue when you get a chance? I think I know what you're talking about, but examples and proposals would be helpful. > , and fixing the > errata already identified. I can do that in late July and then > publish one draft each per month until it is done. Chicago's cutoff for -00 drafts is July 2; could you have an initial draft by then, perhaps just doing the rearrangement and leaving ABNF and errata until later? Something to give people even a rough idea of what you were talking about would be very helpful. > If, for some unforeseen reason, I am unable to make those drafts > happen, then nothing on your charter schedule needs to change. > If the WG chooses not to adopt the changed drafts after they > have been reviewed, then so be it. I just don't want to burn > the time editing the drafts only to have someone declare > discussion of them to be out of scope. My personal preference would be to make a decision beforehand; a well- scoped charter can be frustrating, but it can also prevent many ratholes. Knowing what they're getting into raises people's comfort level considerably. If you can get a draft in before Chicago, we could discuss it there and either get them built into the WG's scope, or decide that they're already within it, or even base the charter on your document. > BTW, structural changes have to be done first, using 2616 as > the basis. There is no point of reviewing diffs of 2616 when > nobody bothers to read 2616 as a whole. Diffs after restructuring > can then be viewed in their proper context, with all of the relevant > requirements in the same comprehensible space. That makes it seem that you're thinking of something more substantial than a straight rearrangement. One more question (not necessarily for Roy): at what point does rewrite/rearrangement affect the transition from Proposed to Draft? -- Mark Nottingham http://www.mnot.net/ From discuss-bounces@apps.ietf.org Fri Jun 01 01:17:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtzVi-00079s-FX; Fri, 01 Jun 2007 01:17:14 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtzVf-00078N-Nx for discuss-confirm+ok@megatron.ietf.org; Fri, 01 Jun 2007 01:17:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtzVf-00077p-08 for discuss@apps.ietf.org; Fri, 01 Jun 2007 01:17:11 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtzVd-0005Hz-Gp for discuss@apps.ietf.org; Fri, 01 Jun 2007 01:17:10 -0400 Received: from [127.0.0.1] (unknown [216.145.54.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 2D99E51937; Fri, 1 Jun 2007 01:17:06 -0400 (EDT) In-Reply-To: <7E09FD13-FA92-474F-B394-C732393EF354@mnot.net> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <1358AF2C-F967-46D6-B291-BC65126CCDF6@gbiv.com> <8FBD37BC-E635-485D-A368-22D9DE332498@mnot.net> <68fba5c50705311804w2d39ea88o985d9b6a8aa33220@mail.gmail.com> <6C26C1C5-B99B-41EA-989A-F86DCF8489FC@mnot.net> <4C044C0E-C6B8-4816-9243-FAB72DA5F24F@gbiv.com> <7E09FD13-FA92-474F-B394-C732393EF354@mnot.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8FAE8A21-1B88-448C-8A02-569962440424@mnot.net> Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: Straw-man charter for http-bis Date: Fri, 1 Jun 2007 15:17:04 +1000 To: Mark Nottingham X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Apps Discuss , "Roy T. Fielding" , "ietf-http-wg@w3.org Group" , Robert Sayre X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On 01/06/2007, at 2:19 PM, Mark Nottingham wrote: > One more question (not necessarily for Roy): at what point does > rewrite/rearrangement affect the transition from Proposed to Draft? *shakes head at self* Let me re-phrase that: does a rewrite/rearrangement affect the Draft Standard status? Considering: > A Draft Standard is normally considered to be a final > specification, > and changes are likely to be made only to solve specific problems > encountered. In most circumstances, it is reasonable for > vendors to > deploy implementations of Draft Standards into a disruption > sensitive > environment. -- Mark Nottingham http://www.mnot.net/ From discuss-bounces@apps.ietf.org Fri Jun 01 03:56:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu1zo-0006pZ-D5; Fri, 01 Jun 2007 03:56:28 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hu1zm-0006o8-TE for discuss-confirm+ok@megatron.ietf.org; Fri, 01 Jun 2007 03:56:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu1zm-0006o0-Iq for discuss@apps.ietf.org; Fri, 01 Jun 2007 03:56:26 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu1zl-0006Kl-CF for discuss@apps.ietf.org; Fri, 01 Jun 2007 03:56:26 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 5D5E01EE1BE; Fri, 1 Jun 2007 03:56:20 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EJ6JanaVStJ; Fri, 1 Jun 2007 03:56:03 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 249BE1EE174; Fri, 1 Jun 2007 03:55:58 -0400 (EDT) Message-ID: <465FD10B.8030000@cs.utk.edu> Date: Fri, 01 Jun 2007 03:55:55 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Mark Nottingham Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <1358AF2C-F967-46D6-B291-BC65126CCDF6@gbiv.com> <8FBD37BC-E635-485D-A368-22D9DE332498@mnot.net> <68fba5c50705311804w2d39ea88o985d9b6a8aa33220@mail.gmail.com> <6C26C1C5-B99B-41EA-989A-F86DCF8489FC@mnot.net> <4C044C0E-C6B8-4816-9243-FAB72DA5F24F@gbiv.com> <7E09FD13-FA92-474F-B394-C732393EF354@mnot.net> <8FAE8A21-1B88-448C-8A02-569962440424@mnot.net> In-Reply-To: <8FAE8A21-1B88-448C-8A02-569962440424@mnot.net> X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Apps Discuss , "Roy T. Fielding" , "ietf-http-wg@w3.org Group" , Robert Sayre X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > Let me re-phrase that: does a rewrite/rearrangement affect the Draft > Standard status? one of the main purposes of the document status is to show how much confidence there is in the specification's clarity and accuracy. if you substantially rewrite a specification, whatever confidence you had in the original specification no longer applies to the new specification. and you need to reestablish confidence in the rewritten specification. that implies a reset to Proposed. so basically if you argue that the HTTP spec is so bad that a major rewrite is needed, you're also arguing for the rewritten HTTP spec to have a Proposed Standard status. (as was done for [2]822 and SMTP). From discuss-bounces@apps.ietf.org Fri Jun 01 09:06:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu6qI-0006cm-Vo; Fri, 01 Jun 2007 09:06:59 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtvZH-0005ZF-GD for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 21:04:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtvZH-0005Z7-6Y for discuss@apps.ietf.org; Thu, 31 May 2007 21:04:39 -0400 Received: from wa-out-1112.google.com ([209.85.146.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtvZF-0008CY-TV for discuss@apps.ietf.org; Thu, 31 May 2007 21:04:39 -0400 Received: by wa-out-1112.google.com with SMTP id k22so482206waf for ; Thu, 31 May 2007 18:04:35 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kpQpBlAGSVFrzfXyfRLc4NVaFXx84DQtoa75e4ihXDp2sZRrFQdGlpJj6yHXopvrKCzE6groPWuAafGuGhTuSQ9zu4lLv0bjZ9ejM6O2NqOE3evEz5IQEJmAwxSjErTJflICtB7RzhBVRy8hJTGUIfoXKcIEXC8cNQYBtS6Qs6E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aUyT7hiL8y1TEqfM+rL4lSYqb6GLKqLmaSDIHWADaTVw3VXWFIJqcAAxVJGsvuBne54nO8IniBuziHCVzMqd6vg1UBX3wbrbCFr9j2k6xV84Ql4fqK+q1WtMaThwbh8JtEwF4lYu1oynrP41O6hEs7PnRMZNFXBoPcjErFqiTKk= Received: by 10.115.32.1 with SMTP id k1mr1207520waj.1180659872420; Thu, 31 May 2007 18:04:32 -0700 (PDT) Received: by 10.114.205.4 with HTTP; Thu, 31 May 2007 18:04:32 -0700 (PDT) Message-ID: <68fba5c50705311804w2d39ea88o985d9b6a8aa33220@mail.gmail.com> Date: Thu, 31 May 2007 21:04:32 -0400 From: "Robert Sayre" To: "Roy T. Fielding" Subject: Re: Straw-man charter for http-bis In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <1358AF2C-F967-46D6-B291-BC65126CCDF6@gbiv.com> <8FBD37BC-E635-485D-A368-22D9DE332498@mnot.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-Mailman-Approved-At: Fri, 01 Jun 2007 09:06:57 -0400 Cc: Apps Discuss , Mark Nottingham , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On 5/31/07, Roy T. Fielding wrote: > > I am not going > to support an IETF working group that says "nobody is allowed > to do a better job describing HTTP than what is in our charter." ... > > If I make the real changes that are needed in draft form and submit > them to the WG, then I will expect them to be evaluated without bias > or the WG to be closed. If the answer is "that's too much > for me to review, so you aren't allowed to do that in the IETF" > then I won't. I will do it elsewhere and the IETF specification > will become irrelevant. I think application of forking pressure is OK. It is always present anyway. I don't understand why the two approaches are mutually exclusive. I think the best way to start is by doing exactly what has been done so far. I agree with Roy that we shouldn't rule out large scale restructuring at some point, but it might be better to let everyone look at a few rounds of diffs before any major structural changes are made. The issues list is already getting a little big. > > I don't hear anyone else saying that 2616 needs to be revised before > 2617, yet you continue to take that as an assumption. The order is irrelevant, and they don't need to be undertaken by the same group. > 2616 doesn't *need* to be revised at all. Disagree. The document is losing usefulness as a reference because it is poorly structured, crawling with inaccuracies, and the net is full of things that claim to be HTTP but aren't. > 2617 desperately does need to in order > to meet the IESG requirements. Why is that unclear? The requirements have been revisited. -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From discuss-bounces@apps.ietf.org Fri Jun 01 09:06:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu6qI-0006bc-Bc; Fri, 01 Jun 2007 09:06:58 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Htskk-0005gc-9B for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 18:04:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htskj-0005gU-VR for discuss@apps.ietf.org; Thu, 31 May 2007 18:04:17 -0400 Received: from av6-2-sn3.vrr.skanova.net ([81.228.9.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htski-0007n0-Hh for discuss@apps.ietf.org; Thu, 31 May 2007 18:04:17 -0400 Received: by av6-2-sn3.vrr.skanova.net (Postfix, from userid 502) id DEEEF38755; Fri, 1 Jun 2007 00:04:14 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av6-2-sn3.vrr.skanova.net (Postfix) with ESMTP id C3A1B37F9F; Fri, 1 Jun 2007 00:04:14 +0200 (CEST) Received: from henriknordstrom.net (81-233-163-21-no84.tbcn.telia.com [81.233.163.21]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 255BA37E46; Fri, 1 Jun 2007 00:04:10 +0200 (CEST) Received: from [192.168.1.2] (henriknordstrom.net [192.168.1.2] (may be forged)) by henriknordstrom.net (8.12.11.20060308/8.12.8) with ESMTP id l4VM49UT019114; Fri, 1 Jun 2007 00:04:09 +0200 Subject: RE: Straw-man charter for http-bis -- call for errata/clarifications to 2617 From: Henrik Nordstrom To: Eric Lawrence In-Reply-To: <8301DE7F96C0074C8DA98484623D7E51157CAB5862@DF-MASTIFF-MSG.exchange.corp.microsoft.com> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <465D987F.5070906@cisco.com> <000c01c7a318$7bc243e0$7346cba0$@org> <68fba5c50705302228v7f8ab278y50cf38c9f971f0a3@mail.gmail.com> <1180637848.4471.11.camel@henriknordstrom.net> <8301DE7F96C0074C8DA98484623D7E51157CAB5862@DF-MASTIFF-MSG.exchange.corp.microsoft.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-CSxoylVC4AEKYMXbb2fM" Date: Fri, 01 Jun 2007 00:04:09 +0200 Message-Id: <1180649049.5423.31.camel@henriknordstrom.net> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on henriknordstrom.net X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-Mailman-Approved-At: Fri, 01 Jun 2007 09:06:57 -0400 Cc: Eliot Lear , Larry Masinter , Robert Sayre , Apps Discuss , Mark Nottingham , "ietf-http-wg@w3.org" , Paul Hoffman X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --=-CSxoylVC4AEKYMXbb2fM Content-Type: text/plain Content-Transfer-Encoding: quoted-printable tor 2007-05-31 klockan 14:28 -0700 skrev Eric Lawrence: > You're right, but Henrik's point still stands. The existing > implementation of Negotiate/NTLM is significantly different than the > conventional HTTP authentication "per-message" model. It may be > difficult (or undesirable) to roll this into RFC2616. I would undesirable. It requires a far too big change in the transport & message model of HTTP, and in it's current form has some serious (but partially documented) security implications when using proxies. HTTP is explicitly designed as a transport-independent message oriented protocol where each message is self-contained and not dependent on being sent on a specific transport connection. RFC4559 is completely connection oriented, with messages far from self-contained and very dependent of which transport connection is being used. Regards Henrik --=-CSxoylVC4AEKYMXbb2fM Content-Type: application/pgp-signature; name=signature.asc Content-Description: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad meddelandedel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iQCVAwUARl9GVkNPQ5Kbx8daAQJWLAP5AXiHJmNWDFlCxEpu7qe5N9f55fOqS50x TmUq4p0AOU4OItGJx9TX8E44jp4sxFXVgHvCONz5R2t+tAyftE+bRD7QwG0wQK1x 5x46PgHPlOIaiRvZLZpELVt4SEknychVfCoWAW2aqc7cYrv3v85QwGu2pbCJYxby QyaiEJk1/G8= =WDzl -----END PGP SIGNATURE----- --=-CSxoylVC4AEKYMXbb2fM-- From discuss-bounces@apps.ietf.org Fri Jun 01 09:06:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu6qI-0006cm-Vo; Fri, 01 Jun 2007 09:06:59 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtvZH-0005ZF-GD for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 21:04:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtvZH-0005Z7-6Y for discuss@apps.ietf.org; Thu, 31 May 2007 21:04:39 -0400 Received: from wa-out-1112.google.com ([209.85.146.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtvZF-0008CY-TV for discuss@apps.ietf.org; Thu, 31 May 2007 21:04:39 -0400 Received: by wa-out-1112.google.com with SMTP id k22so482206waf for ; Thu, 31 May 2007 18:04:35 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kpQpBlAGSVFrzfXyfRLc4NVaFXx84DQtoa75e4ihXDp2sZRrFQdGlpJj6yHXopvrKCzE6groPWuAafGuGhTuSQ9zu4lLv0bjZ9ejM6O2NqOE3evEz5IQEJmAwxSjErTJflICtB7RzhBVRy8hJTGUIfoXKcIEXC8cNQYBtS6Qs6E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aUyT7hiL8y1TEqfM+rL4lSYqb6GLKqLmaSDIHWADaTVw3VXWFIJqcAAxVJGsvuBne54nO8IniBuziHCVzMqd6vg1UBX3wbrbCFr9j2k6xV84Ql4fqK+q1WtMaThwbh8JtEwF4lYu1oynrP41O6hEs7PnRMZNFXBoPcjErFqiTKk= Received: by 10.115.32.1 with SMTP id k1mr1207520waj.1180659872420; Thu, 31 May 2007 18:04:32 -0700 (PDT) Received: by 10.114.205.4 with HTTP; Thu, 31 May 2007 18:04:32 -0700 (PDT) Message-ID: <68fba5c50705311804w2d39ea88o985d9b6a8aa33220@mail.gmail.com> Date: Thu, 31 May 2007 21:04:32 -0400 From: "Robert Sayre" To: "Roy T. Fielding" Subject: Re: Straw-man charter for http-bis In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <1358AF2C-F967-46D6-B291-BC65126CCDF6@gbiv.com> <8FBD37BC-E635-485D-A368-22D9DE332498@mnot.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-Mailman-Approved-At: Fri, 01 Jun 2007 09:06:57 -0400 Cc: Apps Discuss , Mark Nottingham , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On 5/31/07, Roy T. Fielding wrote: > > I am not going > to support an IETF working group that says "nobody is allowed > to do a better job describing HTTP than what is in our charter." ... > > If I make the real changes that are needed in draft form and submit > them to the WG, then I will expect them to be evaluated without bias > or the WG to be closed. If the answer is "that's too much > for me to review, so you aren't allowed to do that in the IETF" > then I won't. I will do it elsewhere and the IETF specification > will become irrelevant. I think application of forking pressure is OK. It is always present anyway. I don't understand why the two approaches are mutually exclusive. I think the best way to start is by doing exactly what has been done so far. I agree with Roy that we shouldn't rule out large scale restructuring at some point, but it might be better to let everyone look at a few rounds of diffs before any major structural changes are made. The issues list is already getting a little big. > > I don't hear anyone else saying that 2616 needs to be revised before > 2617, yet you continue to take that as an assumption. The order is irrelevant, and they don't need to be undertaken by the same group. > 2616 doesn't *need* to be revised at all. Disagree. The document is losing usefulness as a reference because it is poorly structured, crawling with inaccuracies, and the net is full of things that claim to be HTTP but aren't. > 2617 desperately does need to in order > to meet the IESG requirements. Why is that unclear? The requirements have been revisited. -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From discuss-bounces@apps.ietf.org Fri Jun 01 09:06:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu6qI-0006bc-Bc; Fri, 01 Jun 2007 09:06:58 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Htskk-0005gc-9B for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 18:04:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htskj-0005gU-VR for discuss@apps.ietf.org; Thu, 31 May 2007 18:04:17 -0400 Received: from av6-2-sn3.vrr.skanova.net ([81.228.9.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htski-0007n0-Hh for discuss@apps.ietf.org; Thu, 31 May 2007 18:04:17 -0400 Received: by av6-2-sn3.vrr.skanova.net (Postfix, from userid 502) id DEEEF38755; Fri, 1 Jun 2007 00:04:14 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av6-2-sn3.vrr.skanova.net (Postfix) with ESMTP id C3A1B37F9F; Fri, 1 Jun 2007 00:04:14 +0200 (CEST) Received: from henriknordstrom.net (81-233-163-21-no84.tbcn.telia.com [81.233.163.21]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 255BA37E46; Fri, 1 Jun 2007 00:04:10 +0200 (CEST) Received: from [192.168.1.2] (henriknordstrom.net [192.168.1.2] (may be forged)) by henriknordstrom.net (8.12.11.20060308/8.12.8) with ESMTP id l4VM49UT019114; Fri, 1 Jun 2007 00:04:09 +0200 Subject: RE: Straw-man charter for http-bis -- call for errata/clarifications to 2617 From: Henrik Nordstrom To: Eric Lawrence In-Reply-To: <8301DE7F96C0074C8DA98484623D7E51157CAB5862@DF-MASTIFF-MSG.exchange.corp.microsoft.com> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <465D987F.5070906@cisco.com> <000c01c7a318$7bc243e0$7346cba0$@org> <68fba5c50705302228v7f8ab278y50cf38c9f971f0a3@mail.gmail.com> <1180637848.4471.11.camel@henriknordstrom.net> <8301DE7F96C0074C8DA98484623D7E51157CAB5862@DF-MASTIFF-MSG.exchange.corp.microsoft.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-CSxoylVC4AEKYMXbb2fM" Date: Fri, 01 Jun 2007 00:04:09 +0200 Message-Id: <1180649049.5423.31.camel@henriknordstrom.net> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on henriknordstrom.net X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-Mailman-Approved-At: Fri, 01 Jun 2007 09:06:57 -0400 Cc: Eliot Lear , Larry Masinter , Robert Sayre , Apps Discuss , Mark Nottingham , "ietf-http-wg@w3.org" , Paul Hoffman X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --=-CSxoylVC4AEKYMXbb2fM Content-Type: text/plain Content-Transfer-Encoding: quoted-printable tor 2007-05-31 klockan 14:28 -0700 skrev Eric Lawrence: > You're right, but Henrik's point still stands. The existing > implementation of Negotiate/NTLM is significantly different than the > conventional HTTP authentication "per-message" model. It may be > difficult (or undesirable) to roll this into RFC2616. I would undesirable. It requires a far too big change in the transport & message model of HTTP, and in it's current form has some serious (but partially documented) security implications when using proxies. HTTP is explicitly designed as a transport-independent message oriented protocol where each message is self-contained and not dependent on being sent on a specific transport connection. RFC4559 is completely connection oriented, with messages far from self-contained and very dependent of which transport connection is being used. Regards Henrik --=-CSxoylVC4AEKYMXbb2fM Content-Type: application/pgp-signature; name=signature.asc Content-Description: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad meddelandedel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iQCVAwUARl9GVkNPQ5Kbx8daAQJWLAP5AXiHJmNWDFlCxEpu7qe5N9f55fOqS50x TmUq4p0AOU4OItGJx9TX8E44jp4sxFXVgHvCONz5R2t+tAyftE+bRD7QwG0wQK1x 5x46PgHPlOIaiRvZLZpELVt4SEknychVfCoWAW2aqc7cYrv3v85QwGu2pbCJYxby QyaiEJk1/G8= =WDzl -----END PGP SIGNATURE----- --=-CSxoylVC4AEKYMXbb2fM-- From discuss-bounces@apps.ietf.org Fri Jun 01 09:06:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu6qI-0006cC-Jf; Fri, 01 Jun 2007 09:06:58 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Htt82-00026j-Rd for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 18:28:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htt82-00025A-HK for discuss@apps.ietf.org; Thu, 31 May 2007 18:28:22 -0400 Received: from av6-1-sn3.vrr.skanova.net ([81.228.9.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htt82-0004WA-47 for discuss@apps.ietf.org; Thu, 31 May 2007 18:28:22 -0400 Received: by av6-1-sn3.vrr.skanova.net (Postfix, from userid 502) id CF35D389D6; Fri, 1 Jun 2007 00:28:20 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av6-1-sn3.vrr.skanova.net (Postfix) with ESMTP id B853838710; Fri, 1 Jun 2007 00:28:20 +0200 (CEST) Received: from henriknordstrom.net (81-233-163-21-no84.tbcn.telia.com [81.233.163.21]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 6C98437E45; Fri, 1 Jun 2007 00:28:10 +0200 (CEST) Received: from [192.168.1.2] (henriknordstrom.net [192.168.1.2] (may be forged)) by henriknordstrom.net (8.12.11.20060308/8.12.8) with ESMTP id l4VMS6Dd019554; Fri, 1 Jun 2007 00:28:06 +0200 Subject: Re: Straw-man charter for http-bis From: Henrik Nordstrom To: Mark Nottingham In-Reply-To: <8FBD37BC-E635-485D-A368-22D9DE332498@mnot.net> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <1358AF2C-F967-46D6-B291-BC65126CCDF6@gbiv.com> <8FBD37BC-E635-485D-A368-22D9DE332498@mnot.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Uu23rNYsS9bfJqA9At5g" Date: Fri, 01 Jun 2007 00:28:05 +0200 Message-Id: <1180650485.5423.51.camel@henriknordstrom.net> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on henriknordstrom.net X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-Mailman-Approved-At: Fri, 01 Jun 2007 09:06:57 -0400 Cc: Apps Discuss , "Roy T. Fielding" , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --=-Uu23rNYsS9bfJqA9At5g Content-Type: text/plain Content-Transfer-Encoding: quoted-printable fre 2007-06-01 klockan 07:15 +1000 skrev Mark Nottingham: > Somehow, HTTP has been implemented and become one of the most widely-=20 > deployed application protocols today, despite your claims that the =20 > spec needs to be re-written from scratch. I don't hear *anyone* else =20 > saying that this necessary, or a realistic option. It probably is from the perspective of having a easy to read and error free protocol specification, but this is not one of the requirements for an IETF protocol standard. Imho the goal of this effort is to push HTTP/1.1 specifications forward to the level that it can be accepted as an IEFT standard. Not to make a perfect specification. Once that is accomplished work should start on the next version of HTTP to improve both specifications and protocol based on what is learnt from HTTP, WebDAV, CalDAV and other HTTP extensions or applications using HTTP as a meaningful substrate, but that's a separate effort. Regards Henrik --=-Uu23rNYsS9bfJqA9At5g Content-Type: application/pgp-signature; name=signature.asc Content-Description: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad meddelandedel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iQCVAwUARl9L80NPQ5Kbx8daAQLK4AQAqj7JDNzXWcr45NIrdq47374kCc7Z3Hch czctm0m2RzyzMENx8oF8O3WQBA9LUa7+MApeER4vYnqQ2ZQjB8KOV9BWPG8oRwbU ZO3dDod4LTXOKtxZinXY54cMiRuk3o28/2eKF9jfd1C6ejZ3P2P8fF3NKfaURUfq 0uPYSXEzQTI= =OhxX -----END PGP SIGNATURE----- --=-Uu23rNYsS9bfJqA9At5g-- From discuss-bounces@apps.ietf.org Fri Jun 01 09:06:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu6qI-0006bh-FQ; Fri, 01 Jun 2007 09:06:58 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtsnA-00068U-WF for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 18:06:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtsnA-00068M-Mc for discuss@apps.ietf.org; Thu, 31 May 2007 18:06:48 -0400 Received: from mail1.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htsn8-00086z-9p for discuss@apps.ietf.org; Thu, 31 May 2007 18:06:48 -0400 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.700.0; Thu, 31 May 2007 15:05:54 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) with Microsoft SMTP Server id 8.0.700.0; Thu, 31 May 2007 15:06:44 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 31 May 2007 15:06:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Straw-man charter for http-bis Date: Thu, 31 May 2007 15:05:40 -0700 Message-ID: <76323E9F0A911944A4E9225FACFC55BA04AFFB6C@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <8FBD37BC-E635-485D-A368-22D9DE332498@mnot.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Straw-man charter for http-bis thread-index: AcejyQK829xY3JXoQSC2G2KcjeLPOwABWg+Q References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <1358AF2C-F967-46D6-B291-BC65126CCDF6@gbiv.com> <8FBD37BC-E635-485D-A368-22D9DE332498@mnot.net> From: Paul Leach To: Mark Nottingham , Roy T.Fielding X-OriginalArrivalTime: 31 May 2007 22:06:40.0585 (UTC) FILETIME=[F74BDB90:01C7A3CF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-Mailman-Approved-At: Fri, 01 Jun 2007 09:06:57 -0400 Cc: Apps Discuss , ietf-http-wg@w3.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Sometimes, the best is the enemy of the good. I think this is one of cases. As all good engineers should, I have great emotional sympathy for Roy's approach of producing the best possible HTTP spec, but while a brand-new, easy-to-implement-from HTTP/1.1 spec would sure be wonderful, if it isn't very likely to From discuss-bounces@apps.ietf.org Fri Jun 01 09:06:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu6qI-0006cC-Jf; Fri, 01 Jun 2007 09:06:58 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Htt82-00026j-Rd for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 18:28:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htt82-00025A-HK for discuss@apps.ietf.org; Thu, 31 May 2007 18:28:22 -0400 Received: from av6-1-sn3.vrr.skanova.net ([81.228.9.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htt82-0004WA-47 for discuss@apps.ietf.org; Thu, 31 May 2007 18:28:22 -0400 Received: by av6-1-sn3.vrr.skanova.net (Postfix, from userid 502) id CF35D389D6; Fri, 1 Jun 2007 00:28:20 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av6-1-sn3.vrr.skanova.net (Postfix) with ESMTP id B853838710; Fri, 1 Jun 2007 00:28:20 +0200 (CEST) Received: from henriknordstrom.net (81-233-163-21-no84.tbcn.telia.com [81.233.163.21]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 6C98437E45; Fri, 1 Jun 2007 00:28:10 +0200 (CEST) Received: from [192.168.1.2] (henriknordstrom.net [192.168.1.2] (may be forged)) by henriknordstrom.net (8.12.11.20060308/8.12.8) with ESMTP id l4VMS6Dd019554; Fri, 1 Jun 2007 00:28:06 +0200 Subject: Re: Straw-man charter for http-bis From: Henrik Nordstrom To: Mark Nottingham In-Reply-To: <8FBD37BC-E635-485D-A368-22D9DE332498@mnot.net> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <1358AF2C-F967-46D6-B291-BC65126CCDF6@gbiv.com> <8FBD37BC-E635-485D-A368-22D9DE332498@mnot.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Uu23rNYsS9bfJqA9At5g" Date: Fri, 01 Jun 2007 00:28:05 +0200 Message-Id: <1180650485.5423.51.camel@henriknordstrom.net> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on henriknordstrom.net X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-Mailman-Approved-At: Fri, 01 Jun 2007 09:06:57 -0400 Cc: Apps Discuss , "Roy T. Fielding" , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --=-Uu23rNYsS9bfJqA9At5g Content-Type: text/plain Content-Transfer-Encoding: quoted-printable fre 2007-06-01 klockan 07:15 +1000 skrev Mark Nottingham: > Somehow, HTTP has been implemented and become one of the most widely-=20 > deployed application protocols today, despite your claims that the =20 > spec needs to be re-written from scratch. I don't hear *anyone* else =20 > saying that this necessary, or a realistic option. It probably is from the perspective of having a easy to read and error free protocol specification, but this is not one of the requirements for an IETF protocol standard. Imho the goal of this effort is to push HTTP/1.1 specifications forward to the level that it can be accepted as an IEFT standard. Not to make a perfect specification. Once that is accomplished work should start on the next version of HTTP to improve both specifications and protocol based on what is learnt from HTTP, WebDAV, CalDAV and other HTTP extensions or applications using HTTget done, then it isn't in reality better than a careful revision of the current one. (Another aspect of good engineering is dealing with tradeoffs.) Indeed, the above analysis also applies to the proposed charter: wouldn't an informational RFC "HTTP Implementors Guide" be nearly as good as the proposed RFC2616bis? And far less work, hence available much sooner? (And hey, since it isn't us, who are these evil "short-term corporate interests"? Are they available to take other heat off us, too? :-) P as a meaningful substrate, but that's a separate effort. Regards Henrik --=-Uu23rNYsS9bfJqA9At5g Content-Type: application/pgp-signature; name=signature.asc Content-Description: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad meddelandedel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iQCVAwUARl9L80NPQ5Kbx8daAQLK4AQAqj7JDNzXWcr45NIrdq47374kCc7Z3Hch czctm0m2RzyzMENx8oF8O3WQBA9LUa7+MApeER4vYnqQ2ZQjB8KOV9BWPG8oRwbU ZO3dDod4LTXOKtxZinXY54cMiRuk3o28/2eKF9jfd1C6ejZ3P2P8fF3NKfaURUfq 0uPYSXEzQTI= =OhxX -----END PGP SIGNATURE----- --=-Uu23rNYsS9bfJqA9At5g-- From discuss-bounces@apps.ietf.org Fri Jun 01 09:06:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu6qI-0006bh-FQ; Fri, 01 Jun 2007 09:06:58 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HtsnA-00068U-WF for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 18:06:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtsnA-00068M-Mc for discuss@apps.ietf.org; Thu, 31 May 2007 18:06:48 -0400 Received: from mail1.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htsn8-00086z-9p for discuss@apps.ietf.org; Thu, 31 May 2007 18:06:48 -0400 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.700.0; Thu, 31 May 2007 15:05:54 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) with Microsoft SMTP Server id 8.0.700.0; Thu, 31 May 2007 15:06:44 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 31 May 2007 15:06:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Straw-man charter for http-bis Date: Thu, 31 May 2007 15:05:40 -0700 Message-ID: <76323E9F0A911944A4E9225FACFC55BA04AFFB6C@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <8FBD37BC-E635-485D-A368-22D9DE332498@mnot.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Straw-man charter for http-bis thread-index: AcejyQK829xY3JXoQSC2G2KcjeLPOwABWg+Q References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <1358AF2C-F967-46D6-B291-BC65126CCDF6@gbiv.com> <8FBD37BC-E635-485D-A368-22D9DE332498@mnot.net> From: Paul Leach To: Mark Nottingham , Roy T.Fielding X-OriginalArrivalTime: 31 May 2007 22:06:40.0585 (UTC) FILETIME=[F74BDB90:01C7A3CF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-Mailman-Approved-At: Fri, 01 Jun 2007 09:06:57 -0400 Cc: Apps Discuss , ietf-http-wg@w3.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Sometimes, the best is the enemy of the good. I think this is one of cases. As all good engineers should, I have great emotional sympathy for Roy's approach of producing the best possible HTTP spec, but while a brand-new, easy-to-implement-from HTTP/1.1 spec would sure be wonderful, if it isn't very likely to get done, then it isn't in reality better than a careful revision of the current one. (Another aspect of good engineering is dealing with tradeoffs.) Indeed, the above analysis also applies to the proposed charter: wouldn't an informational RFC "HTTP Implementors Guide" be nearly as good as the proposed RFC2616bis? And far less work, hence available much sooner? (And hey, since it isn't us, who are these evil "short-term corporate interests"? Are they available to take other heat off us, too? :-) From discuss-bounces@apps.ietf.org Fri Jun 01 09:06:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu6qI-0006cU-Or; Fri, 01 Jun 2007 09:06:58 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Httbg-00011I-RH for discuss-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 18:59:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Httbf-000114-S0 for discuss@apps.ietf.org; Thu, 31 May 2007 18:58:59 -0400 Received: from mailbigip.dreamhost.com ([208.97.132.5] helo=spaceymail-a3.g.dreamhost.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Httbf-0000bT-Bp for discuss@apps.ietf.org; Thu, 31 May 2007 18:58:59 -0400 Received: from [192.168.0.133] (ip72-211-200-45.oc.oc.cox.net [72.211.200.45]) by spaceymail-a3.g.dreamhost.com (Postfix) with ESMTP id 8B5031951BE; Thu, 31 May 2007 15:58:58 -0700 (PDT) In-Reply-To: <8FBD37BC-E635-485D-A368-22D9DE332498@mnot.net> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <1358AF2C-F967-46D6-B291-BC65126CCDF6@gbiv.com> <8FBD37BC-E635-485D-A368-22D9DE332498@mnot.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Roy T. Fielding" Subject: Re: Straw-man charter for http-bis Date: Thu, 31 May 2007 15:59:15 -0700 To: Mark Nottingham X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a X-Mailman-Approved-At: Fri, 01 Jun 2007 09:06:57 -0400 Cc: Apps Discuss , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On May 31, 2007, at 2:15 PM, Mark Nottingham wrote: > On 01/06/2007, at 5:10 AM, Roy T. Fielding wrote: > >> Just to reiterate what I have said before, I think it is absurd to >> make >> minor editorial modifications to RFC 2616 in a new revision. If >> minor >> editorial changes are necessary right now, the RFC editor can make >> them >> with a simple set of instructions from the original authors. >> However, >> I don't see them as necessary -- the existing list of errata is >> sufficient until such time as the more pressing security issues can >> be resolved in other specifications. > > I'm very aware of your feelings. I'm also aware of the pain that > folks go through when they try to implement the current spec. Yes, > some of that is caused by the organisation and committee-speak > there, but much more is on very specific points where the spec is > silent or misleading -- our issues list now has more than sixty > issues. That this effort will help in those cases. No, it's not a > magic pill, but a complete rewrite wouldn't be either, and it would > have much less chance of success. > >> The reason that RFC 2616 had so many editorial mistakes is because >> the >> RFC became completely unreadable due to far too much committee-driven >> discussion being added in the revision from 2068 to 2616. >> If an actual revision is desired for HTTP/1.1, then a ground-up reorg >> of the specification and formal ABNF productions are necessary. >> I don't care if that matches "group consensus desires" or not; >> sometimes the work needs to be done regardless of popular opinion. > >> What matters is not what work the working group is willing to embark >> upon, but what work the group is willing to review at the end. If I >> completely rewrite the HTTP/1.1 specification without adding >> features, >> and submit that new draft for review, will the working group consider >> it to be out of scope? If not, then limiting the scope of changes >> to the specification (aside from not adding new features) is >> irrelevant >> to the charter. If it will be out of scope, then I have no interest >> in participating here and will fork the standard to a place that >> isn't being driven by a short-term corporate agenda. > > Is your threat to attempt a fork of HTTP if you don't get your way > a hypothetical, or something you're actually considering? It is not "if I don't get my way". Who appointed you to be the determinant of group consensus in the first place? I am not going to support an IETF working group that says "nobody is allowed to do a better job describing HTTP than what is in our charter." If you don't allow people to produce drafts, and allow the working group to evaluate those drafts on the basis of whether the contents are better or not, then all you are doing is dictating the content of the specification based upon some imagined position of authority. So, you should decide whether your work item is to replace 2616 or to produce a list of errata to be published in RFC form. If it is the former, than I know a lot more about this subject than you and I know for a fact that just making small changes around the edges is not sufficient. We already tried that twice. If I make the real changes that are needed in draft form and submit them to the WG, then I will expect them to be evaluated without bias or the WG to be closed. If the answer is "that's too much for me to review, so you aren't allowed to do that in the IETF" then I won't. I will do it elsewhere and the IETF specification will become irrelevant. > Also, on what do you base the accusation that this is being driven > by "short-term corporate agendas?" On the basis that you presuppose every work item as being limited to what you want to do, rather than a task that can be accomplished if someone does it, and the continual reference to vendors and "developers" that never actually show themselves on this list. > In any case, I don't think re-organising parts of the spec is off > the table; indeed, it's already been discussed on a small scale. Re- > writing the entire spec sentence-for-sentence is, in my opinion. In your opinion. You chose to ignore mine, in spite of the fact that I have a bit of history on the subject, and that is why I have to make comments on these proposals. >> If an IETF HTTP WG is to be recreated, then its task items should be >> to create what the working group believes to be the best documents >> to replace 2616 and 2617. The charter does not need to constrain >> that. > > That would be disruptive and unproductive. You may be willing to re- > write HTTP from scratch, but the review requirements are much > higher than required for what we're attempting (with step-by-step > diffs, by the way). > > Somehow, HTTP has been implemented and become one of the most > widely-deployed application protocols today, despite your claims > that the spec needs to be re-written from scratch. I don't hear > *anyone* else saying that this necessary, or a realistic option. I don't hear anyone else saying that 2616 needs to be revised before 2617, yet you continue to take that as an assumption. 2616 doesn't *need* to be revised at all. 2617 desperately does need to in order to meet the IESG requirements. Why is that unclear? I do not desire a revision on 2616. However, if a revision is called for, then the minimum revision is something that can be reviewed in its entirety. That was not the case for 2616, and certainly won't be the case for the patchwork of issues you have collected so far. ....Roy From discuss-bounces@apps.ietf.org Fri Jun 01 10:43:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu8Lb-000731-BW; Fri, 01 Jun 2007 10:43:23 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hu8La-00072w-RA for discuss-confirm+ok@megatron.ietf.org; Fri, 01 Jun 2007 10:43:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu8La-00072m-HL for discuss@apps.ietf.org; Fri, 01 Jun 2007 10:43:22 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu8LZ-0000ug-Al for discuss@apps.ietf.org; Fri, 01 Jun 2007 10:43:22 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 0CAA11EE1D3; Fri, 1 Jun 2007 10:43:20 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntLcomEeGOEK; Fri, 1 Jun 2007 10:43:05 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 3E6751EE1BB; Fri, 1 Jun 2007 10:42:59 -0400 (EDT) Message-ID: <46603071.3020109@cs.utk.edu> Date: Fri, 01 Jun 2007 10:42:57 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Robert Sayre Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <1358AF2C-F967-46D6-B291-BC65126CCDF6@gbiv.com> <8FBD37BC-E635-485D-A368-22D9DE332498@mnot.net> <68fba5c50705311804w2d39ea88o985d9b6a8aa33220@mail.gmail.com> In-Reply-To: <68fba5c50705311804w2d39ea88o985d9b6a8aa33220@mail.gmail.com> X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Apps Discuss , "Roy T. Fielding" , Mark Nottingham , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >> 2616 doesn't *need* to be revised at all. > > Disagree. The document is losing usefulness as a reference because it > is poorly structured, crawling with inaccuracies, and the net is full > of things that claim to be HTTP but aren't. is this because implementors tried to read the existing HTTP spec and failed to grasp it, or because they didn't even bother trying to read the spec? (seriously, at least for SMTP it's pretty obvious that a lot of authors of bad implementations never bothered to read the spec, they just copied what they saw someone else do. ) revising 2616 will help the implementors who are actually trying to get it right, and for that reason it is probably a worthwhile effort. but it won't do anything for the remainder of the implementations. From discuss-bounces@apps.ietf.org Fri Jun 01 10:48:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu8Qy-0007nK-Us; Fri, 01 Jun 2007 10:48:56 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hu8Qx-0007n9-Li for discuss-confirm+ok@megatron.ietf.org; Fri, 01 Jun 2007 10:48:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu8Qx-0007n1-C6 for discuss@apps.ietf.org; Fri, 01 Jun 2007 10:48:55 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu8Qw-0001r3-4t for discuss@apps.ietf.org; Fri, 01 Jun 2007 10:48:55 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 1CB6F1EE152; Fri, 1 Jun 2007 10:48:52 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCSh2iiq4YRI; Fri, 1 Jun 2007 10:48:41 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id B416F1EE1A7; Fri, 1 Jun 2007 10:48:40 -0400 (EDT) Message-ID: <466031C7.4050906@cs.utk.edu> Date: Fri, 01 Jun 2007 10:48:39 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: "Roy T. Fielding" Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <1358AF2C-F967-46D6-B291-BC65126CCDF6@gbiv.com> <8FBD37BC-E635-485D-A368-22D9DE332498@mnot.net> In-Reply-To: X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Apps Discuss , Mark Nottingham , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > I am not going > to support an IETF working group that says "nobody is allowed > to do a better job describing HTTP than what is in our charter." that's your choice, of course. but the charter wording is up to the IESG, and they have the authority to make decisions about what kinds of activities are in scope and which kinds of activities are out of scope. (the draft charter being discussed is just someone's idea of a proposal to be given to IESG and it's reasonable to debate it, or to suggest your own draft charter to the applications ADs) for better or worse, there's a lot of investment in the current prose. a drastic rewrite might remove some ambiguities but would certainly create others - and also create questions about exactly what was changed. if HTTP is updated by making relatively minor tweaks where possible, and major changes to text only when necessary, it's much clearer what was changed than if there's a major restructuring/rewriting of the document. that, and rewriting would force a reset to Proposed Standard and create an ambiguity over whether the Proposed or Draft version were authoritative. Keith From discuss-bounces@apps.ietf.org Fri Jun 01 12:56:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuAPx-0002b8-Hu; Fri, 01 Jun 2007 12:56:01 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HuAPv-0002ZP-OS for discuss-confirm+ok@megatron.ietf.org; Fri, 01 Jun 2007 12:55:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuAPv-0002YM-EM for discuss@apps.ietf.org; Fri, 01 Jun 2007 12:55:59 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuAPv-0003O7-49 for discuss@apps.ietf.org; Fri, 01 Jun 2007 12:55:59 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 0EFBA1EE1BA; Fri, 1 Jun 2007 12:55:57 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gm+Z4GVIuw-r; Fri, 1 Jun 2007 12:55:48 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 2255D1EE179; Fri, 1 Jun 2007 12:55:48 -0400 (EDT) Message-ID: <46604F92.4020404@cs.utk.edu> Date: Fri, 01 Jun 2007 12:55:46 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Robert Sayre Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <1358AF2C-F967-46D6-B291-BC65126CCDF6@gbiv.com> <8FBD37BC-E635-485D-A368-22D9DE332498@mnot.net> <68fba5c50705311804w2d39ea88o985d9b6a8aa33220@mail.gmail.com> <6C26C1C5-B99B-41EA-989A-F86DCF8489FC@mnot.net> <4C044C0E-C6B8-4816-9243-FAB72DA5F24F@gbiv.com> <7E09FD13-FA92-474F-B394-C732393EF354@mnot.net> <68fba5c50706010809r3632445cj24305edadc36340f@mail.gmail.com> In-Reply-To: <68fba5c50706010809r3632445cj24305edadc36340f@mail.gmail.com> X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Apps Discuss , Mark Nottingham , "Roy T. Fielding" , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > That's exactly the argument. If a "more substantial" rewrite does a > better job of documenting HTTP, we should consider it. This > possibility shouldn't cause discomfort, because our shared goal is to > accurately document HTTP 1.1, right? The catch is that HTTP is (currently) specified by RFC 2616, and the most accurate documentation about HTTP is in RFC 2616. If you replace 2616 with a completely different specification, you're not "accurately documenting" HTTP, you're _changing_ the specification. You will inevitably create incompatibilities between "old" HTTP and "new" HTTP. I'm not saying it's inherently a bad idea to do that, I'm saying that a rewrite is going to cause some interoperability issues even if you end up with a much clearer and/or more precise specification. People contemplating a rewrite of HTTP should really look hard that the experience from the DRUMS working group that updated RFC 822 and SMTP. It took a very long time, and while the results are clearer in many ways than the original specifications, IMHO they are not an improvement in every respect. For instance, a lot of effort was spent in rewriting the ABNF that describes internet messages. The new ABNF is perhaps more precise but it's _much_ harder to write a correct parser for the new grammar - and there's very little benefit to doing so because new mail readers still need to be able to parse pre-RFC2822 messages. So in practice, to write a good mail reader, you now need to refer to BOTH RFC 822 and RFC 2822 - because the RFC 822 grammar is the best one to write a parser from, and 2822 has the grammar that you should use when writing code to generate new messages. (And they're in different notations!) This means _more_ work for the implementor, a higher barrier to producing a correct implementation, and a greater temptation to not fully read the specifications and just implement whatever seems to work. Again, I'm not saying don't rewrite the HTTP spec. I'm saying don't underestimate the effort involved, or the harm caused by unintended changes or the difficulty of comparing old and new specifications with different structures. And be really sure you understand how the rewrite is going to benefit the community, taking into account that a lot of implementors won't bother reading the spec and a lot of existing implementations aren't going to get significant updates to conform to the new spec. > Personally, I don't care what color ribbon our pig wins at the county > fair. :) Even if it is cute enough to win a ribbon, do we really need another pig? Keith From discuss-bounces@apps.ietf.org Fri Jun 01 13:51:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuBHj-0003RK-Uy; Fri, 01 Jun 2007 13:51:35 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HuBHj-0003Nq-4l for discuss-confirm+ok@megatron.ietf.org; Fri, 01 Jun 2007 13:51:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuBHi-0003MQ-Ql for discuss@apps.ietf.org; Fri, 01 Jun 2007 13:51:34 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HuBHh-0003xr-DD for discuss@apps.ietf.org; Fri, 01 Jun 2007 13:51:34 -0400 Received: (qmail invoked by alias); 01 Jun 2007 17:51:31 -0000 Received: from p508FA47F.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.164.127] by mail.gmx.net (mp057) with SMTP; 01 Jun 2007 19:51:31 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/ECDlFHlvE6MaFt/iMdYxg3dZnU3DaWBK/yyi/OE IVmeNRIKl415tI Message-ID: <46605C9B.3080804@gmx.de> Date: Fri, 01 Jun 2007 19:51:23 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: "ietf-http-wg@w3.org Group" , Apps Discuss Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> In-Reply-To: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi, I'd like to make one small comment with respect to the opinion that maintaining an errata list (and potentially handing that to the RFC Editor) would be sufficient. 1) Scott Lawrence' original errata list ( is excellent, but it hasn't been maintained since 2004. So we needed to move somewhere else. 2) Just collecting errata sounds nice in theory, but my experience with spec writing is that you can't close a bug until you have applied the suggested fix to the spec text. Frequently, something that looks OK in isolation doesn't work in the specification context. Thus my preference is not only to collect errata and proposed resolutions, but to also have them applied to a copy of the original spec (and have that up for review for everybody). 3) Finally, looking at the amount of issues we have collected in the meantime, I'd be really amazed if the RFC Editor would be willing to take over the editorial work for updating the document. I bet the answer would be: please submit an Internet Draft. Best regards, Julian From discuss-bounces@apps.ietf.org Fri Jun 01 14:06:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuBVt-00068H-R4; Fri, 01 Jun 2007 14:06:13 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HuBVs-00068C-B4 for discuss-confirm+ok@megatron.ietf.org; Fri, 01 Jun 2007 14:06:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuBVs-000684-1M for discuss@apps.ietf.org; Fri, 01 Jun 2007 14:06:12 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuBVq-0005zf-JT for discuss@apps.ietf.org; Fri, 01 Jun 2007 14:06:12 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HuBVn-0009FM-HW; Fri, 01 Jun 2007 14:06:07 -0400 Date: Fri, 01 Jun 2007 14:06:06 -0400 From: John C Klensin To: Julian Reschke Subject: Re: Straw-man charter for http-bis Message-ID: In-Reply-To: <46605C9B.3080804@gmx.de> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <46605C9B.3080804@gmx.de> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Apps Discuss , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --On Friday, 01 June, 2007 19:51 +0200 Julian Reschke wrote: > Hi, > > I'd like to make one small comment with respect to the opinion > that maintaining an errata list (and potentially handing that > to the RFC Editor) would be sufficient. > > 1) Scott Lawrence' original errata list > ( is excellent, but it hasn't > been maintained since 2004. So we needed to move somewhere > else. > > 2) Just collecting errata sounds nice in theory, but my > experience with spec writing is that you can't close a bug > until you have applied the suggested fix to the spec text. > Frequently, something that looks OK in isolation doesn't work > in the specification context. Thus my preference is not only > to collect errata and proposed resolutions, but to also have > them applied to a copy of the original spec (and have that up > for review for everybody). > > 3) Finally, looking at the amount of issues we have collected > in the meantime, I'd be really amazed if the RFC Editor would > be willing to take over the editorial work for updating the > document. I bet the answer would be: please submit an Internet > Draft. Let me add one thing to this, while more or less agreeing with Julian on this particular point (no comment yet about other issues). There are two types of errata. One type just clears up typographical and similar errors where the intent of the text is fairly clear. Those are trivial, the RFC Editor rarely has a problem with them, but it is not clear that they are worth a lot of effort. The second involves a substantive clarification or correction to the document, especially one that permits one way to do things and excludes one or more others that some people might have thought plausible. That second type really requires some explicit process of determining or verifying community consensus; it is not something the RFC Editor ought to be publishing as authoritative at the request of any one party, even if that party were an author of the original document (or the responsible AD at the time :-( ). While I'm not sure I'd recommend it (in part for the reasons Julian identifies under (2) above), one could, in principle, prepare an I-D that was simply a listing of errata and discussion of ambiguities in the base spec, get rough consensus on that listing, and then ask the the IESG to process it and the RFC Editor to publish. That would be a little bit unusual, and would give the reader an extra, and separate, document to read, but I don't know of anything that would prohibit it procedurally. best regards, john From discuss-bounces@apps.ietf.org Fri Jun 01 14:31:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuBuM-0007AI-IB; Fri, 01 Jun 2007 14:31:30 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HuBuL-0007AC-6w for discuss-confirm+ok@megatron.ietf.org; Fri, 01 Jun 2007 14:31:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuBuK-0007A4-TZ for discuss@apps.ietf.org; Fri, 01 Jun 2007 14:31:28 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuBuJ-0000w6-Jy for discuss@apps.ietf.org; Fri, 01 Jun 2007 14:31:28 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 01 Jun 2007 20:31:28 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l51IVQC7019028; Fri, 1 Jun 2007 20:31:26 +0200 Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp160.cisco.com [10.61.64.160]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l51IVNDR005424; Fri, 1 Jun 2007 18:31:24 GMT Message-ID: <466065FB.8030505@cisco.com> Date: Fri, 01 Jun 2007 20:31:23 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Keith Moore Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <1358AF2C-F967-46D6-B291-BC65126CCDF6@gbiv.com> <8FBD37BC-E635-485D-A368-22D9DE332498@mnot.net> <68fba5c50705311804w2d39ea88o985d9b6a8aa33220@mail.gmail.com> <6C26C1C5-B99B-41EA-989A-F86DCF8489FC@mnot.net> <4C044C0E-C6B8-4816-9243-FAB72DA5F24F@gbiv.com> <7E09FD13-FA92-474F-B394-C732393EF354@mnot.net> <68fba5c50706010809r3632445cj24305edadc36340f@mail.gmail.com> <46604F92.4020404@cs.utk.edu> In-Reply-To: <46604F92.4020404@cs.utk.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=421; t=1180722686; x=1181586686; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20Straw-man=20charter=20for=20http-bis |Sender:=20; bh=6gO4ygZGCfsNt6HFH7mi26L9fVPILTXjRpxCeBxn+wo=; b=tQ8HuR38UHsaMv8rX32n/A15w4pBH9/w+uEQQ+lulTbhtBeiLz1c+0jFmxg+xtNbkTA18lOm YWzg1HHhA1JcL5bTzAnEQPdCsV0rRkBETcOqhcqglamUYEsOHjUQ56Xe; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Apps Discuss , Mark Nottingham , "Roy T. Fielding" , "ietf-http-wg@w3.org Group" , Robert Sayre X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Keith Moore wrote: > People contemplating a rewrite of HTTP should really look hard that the > experience from the DRUMS working group that updated RFC 822 and SMTP. > It took a very long time, and while the results are clearer in many ways > than the original specifications, IMHO they are not an improvement in > every respect. I think this is a very valid point. Many of us still have the scars. Eliot From discuss-bounces@apps.ietf.org Fri Jun 01 14:54:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuCGV-00080t-Fs; Fri, 01 Jun 2007 14:54:23 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HuCGS-0007gb-Uw for discuss-confirm+ok@megatron.ietf.org; Fri, 01 Jun 2007 14:54:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuCGS-0007dT-IO for discuss@apps.ietf.org; Fri, 01 Jun 2007 14:54:20 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuCGR-00037L-9I for discuss@apps.ietf.org; Fri, 01 Jun 2007 14:54:20 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 6A1F51EE165; Fri, 1 Jun 2007 14:54:18 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7i-sPXogaqY6; Fri, 1 Jun 2007 14:54:10 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id F3FDD1EE180; Fri, 1 Jun 2007 14:54:09 -0400 (EDT) Message-ID: <46606B50.6030308@cs.utk.edu> Date: Fri, 01 Jun 2007 14:54:08 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Julian Reschke Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <46605C9B.3080804@gmx.de> In-Reply-To: <46605C9B.3080804@gmx.de> X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Apps Discuss , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Julian Reschke wrote: > Hi, > > I'd like to make one small comment with respect to the opinion that > maintaining an errata list (and potentially handing that to the RFC > Editor) would be sufficient. > 1) Scott Lawrence' original errata list > ( is excellent, but it hasn't been > maintained since 2004. So we needed to move somewhere else. > > 2) Just collecting errata sounds nice in theory, but my experience > with spec writing is that you can't close a bug until you have applied > the suggested fix to the spec text. Frequently, something that looks > OK in isolation doesn't work in the specification context. Thus my > preference is not only to collect errata and proposed resolutions, but > to also have them applied to a copy of the original spec (and have > that up for review for everybody). > > 3) Finally, looking at the amount of issues we have collected in the > meantime, I'd be really amazed if the RFC Editor would be willing to > take over the editorial work for updating the document. I bet the > answer would be: please submit an Internet Draft. > > Best regards, Julian My recommendation would be for the group to construct a list of errata and get consensus on that list. Each erratum should mention the specific sections and text of RFC 2616 that it applies to, what the problem is, and what changes are needed to fix the problem. By the time the list is nearing completion, it should be apparent whether it's worth the effort to revise the HTTP specification. The original errata list would still be useful, perhaps as an appendix, because many implementors will just want to know what has changed. My guess is that if the group sees its task as making a good errata-and-fix list for 2616, it will stay focused and finish in a reasonable amount of time. If at that point it is seen as appropriate to actually update 2616, this will be a straightforward task which won't take a lot of additional time. (I do not propose that this task be delegated to the RFC editor - the RFC editor function needs to stay separate.) On the other hand, if the working group sees its task as revising 2616, the chance that it will take several years, dig into a dozen ratholes, and create even more ambiguity than currently exists, is quite large. Keith From discuss-bounces@apps.ietf.org Fri Jun 01 14:56:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuCIf-0002Cz-NV; Fri, 01 Jun 2007 14:56:37 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HuCIe-0002Cr-Cp for discuss-confirm+ok@megatron.ietf.org; Fri, 01 Jun 2007 14:56:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuCIe-0002Cj-39 for discuss@apps.ietf.org; Fri, 01 Jun 2007 14:56:36 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuCIc-0003Pi-Se for discuss@apps.ietf.org; Fri, 01 Jun 2007 14:56:36 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 2AB4C1EE18A; Fri, 1 Jun 2007 14:56:33 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLx73cEWAlVv; Fri, 1 Jun 2007 14:55:52 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 3BC7F1EE179; Fri, 1 Jun 2007 14:55:46 -0400 (EDT) Message-ID: <46606BB0.1050608@cs.utk.edu> Date: Fri, 01 Jun 2007 14:55:44 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Stefan Eissing Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <1358AF2C-F967-46D6-B291-BC65126CCDF6@gbiv.com> <8FBD37BC-E635-485D-A368-22D9DE332498@mnot.net> <68fba5c50705311804w2d39ea88o985d9b6a8aa33220@mail.gmail.com> <6C26C1C5-B99B-41EA-989A-F86DCF8489FC@mnot.net> <4C044C0E-C6B8-4816-9243-FAB72DA5F24F@gbiv.com> <7E09FD13-FA92-474F-B394-C732393EF354@mnot.net> <68fba5c50706010809r3632445cj24305edadc36340f@mail.gmail.com> <46604F92.4020404@cs.utk.edu> <2EE82D2A-CFEB-4F61-9C33-802C75483AE6@greenbytes.de> In-Reply-To: <2EE82D2A-CFEB-4F61-9C33-802C75483AE6@greenbytes.de> X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Apps Discuss , Mark Nottingham , "Roy T. Fielding" , "ietf-http-wg@w3.org Group" , Robert Sayre X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > Taking a step back, what needs attention from the best of minds is > 2617. Let's face it: http authentication is awkward and compared to > the rest of the protocol it feels like a child's toy, sitting in the > glove compartment of a BMW. very much agree. HTTP authentication as it currently exists is nearly useless, and forms-and-cookie authentication (at least as it tends to be implemented) isn't sufficient. From discuss-bounces@apps.ietf.org Fri Jun 01 15:07:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuCSi-00010w-Rn; Fri, 01 Jun 2007 15:07:00 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HuCSi-00010r-4U for discuss-confirm+ok@megatron.ietf.org; Fri, 01 Jun 2007 15:07:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuCSh-00010j-R6 for discuss@apps.ietf.org; Fri, 01 Jun 2007 15:06:59 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HuCSg-0004rd-Ep for discuss@apps.ietf.org; Fri, 01 Jun 2007 15:06:59 -0400 Received: (qmail invoked by alias); 01 Jun 2007 19:06:57 -0000 Received: from p508FA47F.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.164.127] by mail.gmx.net (mp038) with SMTP; 01 Jun 2007 21:06:57 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/CIxRFJKPCl1JYCalS2yNhN3N13+7zSE/UKzYrM2 apoXZrE+V33GaE Message-ID: <46606E4B.9040201@gmx.de> Date: Fri, 01 Jun 2007 21:06:51 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Keith Moore Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <46605C9B.3080804@gmx.de> <46606B50.6030308@cs.utk.edu> In-Reply-To: <46606B50.6030308@cs.utk.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Apps Discuss , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Keith Moore wrote: > ... > My recommendation would be for the group to construct a list of errata > and get consensus on that list. Each erratum should mention the > specific sections and text of RFC 2616 that it applies to, what the > problem is, and what changes are needed to fix the problem. > ... Yes, that's what we have been (slowly) doing over the last months. See . > By the time the list is nearing completion, it should be apparent > whether it's worth the effort to revise the HTTP specification. The > original errata list would still be useful, perhaps as an appendix, > because many implementors will just want to know what has changed. > My guess is that if the group sees its task as making a good > errata-and-fix list for 2616, it will stay focused and finish in a > reasonable amount of time. If at that point it is seen as appropriate > to actually update 2616, this will be a straightforward task which won't > take a lot of additional time. (I do not propose that this task be > delegated to the RFC editor - the RFC editor function needs to stay > separate.) I personally think that this should be a by-product of collecting and resolving the errata. > On the other hand, if the working group sees its task as revising 2616, > the chance that it will take several years, dig into a dozen ratholes, > and create even more ambiguity than currently exists, is quite large. I think this is why an attempt was made to restrict the charter as much as possible. Best regards, Julian From discuss-bounces@apps.ietf.org Fri Jun 01 15:13:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuCYh-0005k3-Nz; Fri, 01 Jun 2007 15:13:11 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HuCYg-0005jx-Gh for discuss-confirm+ok@megatron.ietf.org; Fri, 01 Jun 2007 15:13:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuCYg-0005jp-70 for discuss@apps.ietf.org; Fri, 01 Jun 2007 15:13:10 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuCYe-0005Gd-W8 for discuss@apps.ietf.org; Fri, 01 Jun 2007 15:13:10 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 4C6161EE1AF; Fri, 1 Jun 2007 15:13:08 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0BZb8HstXG3; Fri, 1 Jun 2007 15:12:48 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id E3A461EE18A; Fri, 1 Jun 2007 15:12:47 -0400 (EDT) Message-ID: <46606FAE.2000907@cs.utk.edu> Date: Fri, 01 Jun 2007 15:12:46 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Julian Reschke Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <46605C9B.3080804@gmx.de> <46606B50.6030308@cs.utk.edu> <46606E4B.9040201@gmx.de> In-Reply-To: <46606E4B.9040201@gmx.de> X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Apps Discuss , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > >> My recommendation would be for the group to construct a list of errata >> and get consensus on that list. Each erratum should mention the >> specific sections and text of RFC 2616 that it applies to, what the >> problem is, and what changes are needed to fix the problem. >> ... > > Yes, that's what we have been (slowly) doing over the last months. See > . I understand, and this is a useful head start. But you don't have a working group yet, and therefore you don't have working group consensus yet. The item isn't completed until an open, chartered working group has actually had time to go over the document. It's not acceptable to skip this step. >> My guess is that if the group sees its task as making a good >> errata-and-fix list for 2616, it will stay focused and finish in a >> reasonable amount of time. If at that point it is seen as appropriate >> to actually update 2616, this will be a straightforward task which won't >> take a lot of additional time. (I do not propose that this task be >> delegated to the RFC editor - the RFC editor function needs to stay >> separate.) > I personally think that this should be a by-product of collecting and > resolving the errata. I disagree, because I think the temptation to needlessly edit text will be too large. Keith From discuss-bounces@apps.ietf.org Fri Jun 01 15:20:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuCg9-0008H4-0D; Fri, 01 Jun 2007 15:20:53 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HuCg7-0008Gz-UZ for discuss-confirm+ok@megatron.ietf.org; Fri, 01 Jun 2007 15:20:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuCg7-0008Gr-Kv for discuss@apps.ietf.org; Fri, 01 Jun 2007 15:20:51 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuCg6-00060n-7I for discuss@apps.ietf.org; Fri, 01 Jun 2007 15:20:51 -0400 Received: from [10.20.30.108] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l51JKmFD029068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Jun 2007 12:20:49 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <46605C9B.3080804@gmx.de> Date: Fri, 1 Jun 2007 12:20:43 -0700 To: Apps Discuss , "ietf-http-wg@w3.org Group" From: Paul Hoffman Subject: Re: Straw-man charter for http-bis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org At 2:06 PM -0400 6/1/07, John C Klensin wrote: >While I'm not sure I'd recommend it (in part for the reasons >Julian identifies under (2) above), one could, in principle, >prepare an I-D that was simply a listing of errata and >discussion of ambiguities in the base spec, get rough consensus >on that listing, and then ask the the IESG to process it and the >RFC Editor to publish. That would be a little bit unusual, and >would give the reader an extra, and separate, document to read, >but I don't know of anything that would prohibit it procedurally. In fact, there is a recent example of this very thing happening: "IKEv2 Clarifications and Implementation Guidelines", RFC 4718. It is about 50 pages of clarifications on RFC 4306. The process of developing the spec went quite smoothly, and it really helped during the first f2f interop event. Based on the feedback we have gotten from developers, we are preparing an IKEv2bis which is RFC 4718 mixed into RFC 4306. They really wanted it all in one document. The draft for that is currently expired, but will be revived in the very near future. Note that some of the "clarifications" in RFC 4718 are in fact technical changes that were realized after RFC 4306 was published. We wiggly-worded them to sound like clarifications, but they are fixes to things that are broken. I would be quite surprised if the authors of an HTTP clarifications effort were not put into the exact same situation. From my experience with the IKEv2 document, I propose that you do a clarifications-and-errata document first, get most of the way through, then decide whether or not to do a bis document. (I was tempted to change my From: line to my @vpnc.org address because of the context, but I doubt the message would have gotten to this mailing list if I had.) From discuss-bounces@apps.ietf.org Fri Jun 01 15:22:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuCi6-000125-1g; Fri, 01 Jun 2007 15:22:54 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HuCi4-000120-T3 for discuss-confirm+ok@megatron.ietf.org; Fri, 01 Jun 2007 15:22:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuCi4-00011s-JL for discuss@apps.ietf.org; Fri, 01 Jun 2007 15:22:52 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HuCi4-0006Ek-77 for discuss@apps.ietf.org; Fri, 01 Jun 2007 15:22:52 -0400 Received: (qmail invoked by alias); 01 Jun 2007 19:22:51 -0000 Received: from p508FA47F.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.164.127] by mail.gmx.net (mp005) with SMTP; 01 Jun 2007 21:22:51 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19T7CsVpt1TbAByFolerg11lYpLLLu1DJiQnyQtBI j7KDZy4GRU0kwI Message-ID: <46607205.3010000@gmx.de> Date: Fri, 01 Jun 2007 21:22:45 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Keith Moore Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <46605C9B.3080804@gmx.de> <46606B50.6030308@cs.utk.edu> <46606E4B.9040201@gmx.de> <46606FAE.2000907@cs.utk.edu> In-Reply-To: <46606FAE.2000907@cs.utk.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Apps Discuss , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Keith Moore wrote: >>> My recommendation would be for the group to construct a list of errata >>> and get consensus on that list. Each erratum should mention the >>> specific sections and text of RFC 2616 that it applies to, what the >>> problem is, and what changes are needed to fix the problem. >>> ... >> Yes, that's what we have been (slowly) doing over the last months. See >> . > I understand, and this is a useful head start. But you don't have a > working group yet, and therefore you don't have working group consensus > yet. The item isn't completed until an open, chartered working group > has actually had time to go over the document. It's not acceptable to > skip this step. Right now things that are marked closed are in this state because the proposed resolutions got consensus on ietf-http-wg@w3.org. I know that's not a WG consensus, but it's the closest thing to that that we currently have. Of course, should an HTTP WG be formed, all these proposed resolutions can be challenged again (actually, that can happen even in the absence of a WG :-). >>> My guess is that if the group sees its task as making a good >>> errata-and-fix list for 2616, it will stay focused and finish in a >>> reasonable amount of time. If at that point it is seen as appropriate >>> to actually update 2616, this will be a straightforward task which won't >>> take a lot of additional time. (I do not propose that this task be >>> delegated to the RFC editor - the RFC editor function needs to stay >>> separate.) >> I personally think that this should be a by-product of collecting and >> resolving the errata. > I disagree, because I think the temptation to needlessly edit text will > be too large. I guess that depends on who's doing the editing. Speaking for myself, I have tried to make sure that changes are kept as minimal as possible, and that each and every change is linked to the issue it's supposed to resolve. Best regards, Julian From discuss-bounces@apps.ietf.org Fri Jun 01 15:45:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuD3f-0003Hu-5w; Fri, 01 Jun 2007 15:45:11 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HuD3e-0003DX-8o for discuss-confirm+ok@megatron.ietf.org; Fri, 01 Jun 2007 15:45:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuD3d-0003Co-US for discuss@apps.ietf.org; Fri, 01 Jun 2007 15:45:09 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuD3c-0002Nt-Na for discuss@apps.ietf.org; Fri, 01 Jun 2007 15:45:09 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 032E01EE188; Fri, 1 Jun 2007 15:45:04 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3UPrWDC96Yz; Fri, 1 Jun 2007 15:44:19 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id C45441EE1E1; Fri, 1 Jun 2007 15:44:09 -0400 (EDT) Message-ID: <46607708.4020603@cs.utk.edu> Date: Fri, 01 Jun 2007 15:44:08 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Julian Reschke Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <46605C9B.3080804@gmx.de> <46606B50.6030308@cs.utk.edu> <46606E4B.9040201@gmx.de> <46606FAE.2000907@cs.utk.edu> <46607205.3010000@gmx.de> In-Reply-To: <46607205.3010000@gmx.de> X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Apps Discuss , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > I guess that depends on who's doing the editing. Speaking for myself, > I have tried to make sure that changes are kept as minimal as > possible, and that each and every change is linked to the issue it's > supposed to resolve. Maybe I should clarify. If the working group sees itself as updating 2616, the working group can get into a rathole discussing changes to the text even if the people participating in that discussion can't actually change the text and submit a revised internet-draft for that text. But if it's clear up front that the WG is not chartered to actually change the document text, the participants are more likely to confine their discussion to descriptions of specific problems and fixes. (there's a reason we describe the job of being a WG chair (and for that matter, an AD) as "herding cats".) Keith From discuss-bounces@apps.ietf.org Sat Jun 02 08:10:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuSQx-0002rP-5N; Sat, 02 Jun 2007 08:10:15 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HuCKR-0002RB-Sa for discuss-confirm+ok@megatron.ietf.org; Fri, 01 Jun 2007 14:58:27 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HuCKR-0002R2-JB for discuss@apps.ietf.org; Fri, 01 Jun 2007 14:58:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuCCW-00024G-Hl for discuss@apps.ietf.org; Fri, 01 Jun 2007 14:50:16 -0400 Received: from mail.greenbytes.de ([217.91.35.233] helo=joe.greenbytes.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuCCU-0002fp-3M for discuss@apps.ietf.org; Fri, 01 Jun 2007 14:50:16 -0400 Received: from [192.168.178.21] (i5387C479.versanet.de [83.135.196.121]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by joe.greenbytes.de (Postfix) with ESMTP id 104F7659EE; Fri, 1 Jun 2007 20:50:10 +0200 (CEST) In-Reply-To: <46604F92.4020404@cs.utk.edu> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <1358AF2C-F967-46D6-B291-BC65126CCDF6@gbiv.com> <8FBD37BC-E635-485D-A368-22D9DE332498@mnot.net> <68fba5c50705311804w2d39ea88o985d9b6a8aa33220@mail.gmail.com> <6C26C1C5-B99B-41EA-989A-F86DCF8489FC@mnot.net> <4C044C0E-C6B8-4816-9243-FAB72DA5F24F@gbiv.com> <7E09FD13-FA92-474F-B394-C732393EF354@mnot.net> <68fba5c50706010809r3632445cj24305edadc36340f@mail.gmail.com> <46604F92.4020404@cs.utk.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2EE82D2A-CFEB-4F61-9C33-802C75483AE6@greenbytes.de> Content-Transfer-Encoding: 7bit From: Stefan Eissing Subject: Re: Straw-man charter for http-bis Date: Fri, 1 Jun 2007 20:50:05 +0200 To: Keith Moore X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-TMDA-Confirmed: Fri, 01 Jun 2007 14:58:27 -0400 X-Mailman-Approved-At: Sat, 02 Jun 2007 08:10:13 -0400 Cc: Apps Discuss , Mark Nottingham , "Roy T. Fielding" , "ietf-http-wg@w3.org Group" , Robert Sayre X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Am 01.06.2007 um 18:55 schrieb Keith Moore: >> [Robert]That's exactly the argument. If a "more substantial" >> rewrite does a >> better job of documenting HTTP, we should consider it. This >> possibility shouldn't cause discomfort, because our shared goal is to >> accurately document HTTP 1.1, right? > The catch is that HTTP is (currently) specified by RFC 2616, and the > most accurate documentation about HTTP is in RFC 2616. If you replace > 2616 with a completely different specification, you're not "accurately > documenting" HTTP, you're _changing_ the specification. You will > inevitably create incompatibilities between "old" HTTP and "new" HTTP. > > I'm not saying it's inherently a bad idea to do that, I'm saying > that a > rewrite is going to cause some interoperability issues even if you end > up with a much clearer and/or more precise specification. Taking a step back, what needs atteFrom discuss-bounces@apps.ietf.org Sat Jun 02 08:10:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuSQx-0002rP-5N; Sat, 02 Jun 2007 08:10:15 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HuCKR-0002RB-Sa for discuss-confirm+ok@megatron.ietf.org; Fri, 01 Jun 2007 14:58:27 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HuCKR-0002R2-JB for discuss@apps.ietf.org; Fri, 01 Jun 2007 14:58:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuCCW-00024G-Hl for discuss@apps.ietf.org; Fri, 01 Jun 2007 14:50:16 -0400 Received: from mail.greenbytes.de ([217.91.35.233] helo=joe.greenbytes.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuCCU-0002fp-3M for discuss@apps.ietf.org; Fri, 01 Jun 2007 14:50:16 -0400 Received: from [192.168.178.21] (i5387C479.versanet.de [83.135.196.121]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by joe.greenbytes.de (Postfix) with ESMTP id 104F7659EE; Fri, 1 Jun 2007 20:50:10 +0200 (CEST) In-Reply-To: <46604F92.4020404@cs.utk.edu> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <1358AF2C-F967-46D6-B291-BC65126CCDF6@gbiv.com> <8FBD37BC-E635-485D-A368-22D9DE332498@mnot.net> <68fba5c50705311804w2d39ea88o985d9b6a8aa33220@mail.gmail.com> <6C26C1C5-B99B-41EA-989A-F86DCF8489FC@mnot.net> <4C044C0E-C6B8-4816-9243-FAB72DA5F24F@gbiv.com> <7E09FD13-FA92-474F-B394-C732393EF354@mnot.net> <68fba5c50706010809r3632445cj24305edadc36340f@mail.gmail.com> <46604F92.4020404@cs.utk.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2EE82D2A-CFEB-4F61-9C33-802C75483AE6@greenbytes.de> Content-Transfer-Encoding: 7bit From: Stefan Eissing Subject: Re: Straw-man charter for http-bis Date: Fri, 1 Jun 2007 20:50:05 +0200 To: Keith Moore X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-TMDA-Confirmed: Fri, 01 Jun 2007 14:58:27 -0400 X-Mailman-Approved-At: Sat, 02 Jun 2007 08:10:13 -0400 Cc: Apps Discuss , Mark Nottingham , "Roy T. Fielding" , "ietf-http-wg@w3.org Group" , Robert Sayre X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Am 01.06.2007 um 18:55 schrieb Keith Moore: >> [Robert]That's exactly the argument. If a "more substantial" >> rewrite does a >> better job of documenting HTTP, we should consider it. This >> possibility shouldn't cause discomfort, because our shared goal is to >> accurately document HTTP 1.1, right? > The catch is that HTTP is (currently) specified by RFC 2616, and the > most accurate documentation about HTTP is in RFC 2616. If you replace > 2616 with a completely different specification, you're not "accurately > documenting" HTTP, you're _changing_ the specification. You will > inevitably create incompatibilities between "old" HTTP and "new" HTTP. > > I'm not saying it's inherently a bad idea to do that, I'm saying > that a > rewrite is going to cause some interoperability issues even if you end > up with a much clearer and/or more precise specification. Taking a step back, what needs attention from the best of minds is 2617. Let's face it: http authentication is awkward and compared to the rest of the protocol it feels like a child's toy, sitting in the glove compartment of a BMW. With this in mind, I think a complete rewrite of 2616 is a waste of time and resources. //Stefan From discuss-bounces@apps.ietf.org Sat Jun 02 08:10:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuSQx-0002rK-19; Sat, 02 Jun 2007 08:10:15 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hu8kw-0002nT-Od for discuss-confirm+ok@megatron.ietf.org; Fri, 01 Jun 2007 11:09:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu8kw-0002lm-EB for discuss@apps.ietf.org; Fri, 01 Jun 2007 11:09:34 -0400 Received: from nz-out-0506.google.com ([64.233.162.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu8kt-0007sz-4G for discuss@apps.ietf.org; Fri, 01 Jun 2007 11:09:34 -0400 Received: by nz-out-0506.google.com with SMTP id i28so458242nzi for ; Fri, 01 Jun 2007 08:09:30 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FO9hfzH2z8zEo4Q/uBmNxydH3kVMVgjzLOQMTrbE6wNb+jWAdb1eRfEtfMM4HTpd0FVkj+9Q2evcbFKIdZc1phxSnfCO39d79i05+0so26cexRfq+gf2mY3+9imhviTp3bo/VyPRPdjiwUt7jRoAkasTKhofKz7suNLU6UMo3HE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aUhaPcEaT9cLG6jYdcoxpSAYWWf5hxZVLXM2Vqd+30KY1MzekPTIQJ0RXAvoUHIjYgq9w/raE7jTcltvbiq7bcGjFn+aNSDq3KHFLulZmyGPaw831XhjGS4iObqp+Q4KSUNlb7IJrKbsgkrf0SYN21Q9q8i/ILalSJ01eISGKPE= Received: by 10.115.32.1 with SMTP id k1mr1887027waj.1180710566973; Fri, 01 Jun 2007 08:09:26 -0700 (PDT) Received: by 10.114.205.4 with HTTP; Fri, 1 Jun 2007 08:09:26 -0700 (PDT) Message-ID: <68fba5c50706010809r3632445cj24305edadc36340f@mail.gmail.com> Date: Fri, 1 Jun 2007 11:09:26 -0400 From: "Robert Sayre" To: "Mark Nottingham" Subject: Re: Straw-man charter for http-bis In-Reply-To: <7E09FD13-FA92-474F-B394-C732393EF354@mnot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <1358AF2C-F967-46D6-B291-BC65126CCDF6@gbiv.com> <8FBD37BC-E635-485D-A368-22D9DE332498@mnot.net> <68fba5c50705311804w2d39ea88o985d9b6a8aa33220@mail.gmail.com> <6C26C1C5-B99B-41EA-989A-F86DCF8489FC@mnot.net> <4C044C0E-C6B8-4816-9243-FAB72DA5F24F@gbiv.com> <7E09FD13-FA92-474F-B394-C732393EF354@mnot.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 X-Mailman-Approved-At: Sat, 02 Jun 2007 08:10:13 -0400 Cc: Apps Discuss , "Roy T. Fielding" , Keith Moore , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On 6/1/07, Mark Nottingham wrote: > > > > If, for some unforeseen reason, I am unable to make those drafts > > happen, tntion from the best of minds is 2617. Let's face it: http authentication is awkward and compared to the rest of the protocol it feels like a child's toy, sitting in the glove compartment of a BMW. With this in mind, I think a complete rewrite of 2616 is a waste of time and resources. //Stefan From discuss-bounces@apps.ietf.org Sat Jun 02 08:10:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuSQx-0002rK-19; Sat, 02 Jun 2007 08:10:15 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hu8kw-0002nT-Od for discuss-confirm+ok@megatron.ietf.org; Fri, 01 Jun 2007 11:09:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu8kw-0002lm-EB for discuss@apps.ietf.org; Fri, 01 Jun 2007 11:09:34 -0400 Received: from nz-out-0506.google.com ([64.233.162.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu8kt-0007sz-4G for discuss@apps.ietf.org; Fri, 01 Jun 2007 11:09:34 -0400 Received: by nz-out-0506.google.com with SMTP id i28so458242nzi for ; Fri, 01 Jun 2007 08:09:30 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FO9hfzH2z8zEo4Q/uBmNxydH3kVMVgjzLOQMTrbE6wNb+jWAdb1eRfEtfMM4HTpd0FVkj+9Q2evcbFKIdZc1phxSnfCO39d79i05+0so26cexRfq+gf2mY3+9imhviTp3bo/VyPRPdjiwUt7jRoAkasTKhofKz7suNLU6UMo3HE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aUhaPcEaT9cLG6jYdcoxpSAYWWf5hxZVLXM2Vqd+30KY1MzekPTIQJ0RXAvoUHIjYgq9w/raE7jTcltvbiq7bcGjFn+aNSDq3KHFLulZmyGPaw831XhjGS4iObqp+Q4KSUNlb7IJrKbsgkrf0SYN21Q9q8i/ILalSJ01eISGKPE= Received: by 10.115.32.1 with SMTP id k1mr1887027waj.1180710566973; Fri, 01 Jun 2007 08:09:26 -0700 (PDT) Received: by 10.114.205.4 with HTTP; Fri, 1 Jun 2007 08:09:26 -0700 (PDT) Message-ID: <68fba5c50706010809r3632445cj24305edadc36340f@mail.gmail.com> Date: Fri, 1 Jun 2007 11:09:26 -0400 From: "Robert Sayre" To: "Mark Nottingham" Subject: Re: Straw-man charter for http-bis In-Reply-To: <7E09FD13-FA92-474F-B394-C732393EF354@mnot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <1358AF2C-F967-46D6-B291-BC65126CCDF6@gbiv.com> <8FBD37BC-E635-485D-A368-22D9DE332498@mnot.net> <68fba5c50705311804w2d39ea88o985d9b6a8aa33220@mail.gmail.com> <6C26C1C5-B99B-41EA-989A-F86DCF8489FC@mnot.net> <4C044C0E-C6B8-4816-9243-FAB72DA5F24F@gbiv.com> <7E09FD13-FA92-474F-B394-C732393EF354@mnot.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 X-Mailman-Approved-At: Sat, 02 Jun 2007 08:10:13 -0400 Cc: Apps Discuss , "Roy T. Fielding" , Keith Moore , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On 6/1/07, Mark Nottingham wrote: > > > > If, for some unforeseen reason, I am unable to make those drafts > > happen, then nothing on your charter schedule needs to change. > > If the WG chooses not to adopt the changed drafts after they > > have been reviewed, then so be it. I just don't want to burn > > the time editing the drafts only to have someone declare > > discussion of them to be out of scope. > > My personal preference would be to make a decision beforehand; a well- > scoped charter can be frustrating, but it can also prevent many > ratholes. Knowing what they're getting into raises people's comfort > level considerably. I think Roy's suggestion fits well within the charter you've just sent out, which doesn't restrict the amount of editing that can be done. The debate centers on the best way to *describe* HTTP 1.1 in a timely manner. This is a good argument to be having. Perhaps people should suggest concrete changes to the charter text instead of merely stating their opinions. Seems to me like we need some text that states what we don't have to accomplish regarding authentication, and some text that explicitly allows large scale editorial changes. > If you can get a draft in before Chicago, we could discuss it there > and either get them built into the WG's scope, or decide that they're > already within it, or even base the charter on your document. That would be great, but it's a lot of work, and that's a tight deadline. An outline sent to the list before the meeting would be enough, I think. > > BTW, structural changes have to be done first, using 2616 as > > the basis. There is no point of reviewing diffs of 2616 when > > nobody bothers to read 2616 as a whole. Diffs after restructuring > > can then be viewed in their proper context, with all of the relevant > > requirements in the same comprehensible space. > > That makes it seem that you're thinking of something more substantial > than a straight rearrangement. That's exactly the argument. If a "more substantial" rewrite does a better job of documenting HTTP, we should consider it. This possibility shouldn't cause discomfort, because our shared goal is to accurately document HTTP 1.1, right? On 6/1/07, Keith Moore wrote: > > so basically if you argue that the HTTP spec is so bad that a major > rewrite is needed, you're also arguing for > the rewritten HTTP spec to have a Proposed Standard status. (as was > done for [2]822 and SMTP). Personally, I don't care what color ribbon our pig wins at the county fair. :) On 6/1/07, Keith Moore wrote: > > is this because implementors tried to read the existing HTTP spec and > failed to grasp it, or because they didn't even bother trying to read > the spec? Here's a concrete example: I am sick of questions about this from people who have only read RFC2616. It's a waste of my time and theirs. -- Robert Sayre "I would have written a shorter letter, but I did not have the time." hen nothing on your charter schedule needs to change. > > If the WG chooses not to adopt the changed drafts after they > > have been reviewed, then so be it. I just don't want to burn > > the time editing the drafts only to have someone declare > > discussion of them to be out of scope. > > My personal preference would be to make a decision beforehand; a well- > scoped charter can be frustrating, but it can also prevent many > ratholes. Knowing what they're getting into raises people's comfort > level considerably. I think Roy's suggestion fits well within the charter you've just sent out, which doesn't restrict the amount of editing that can be done. The debate centers on the best way to *describe* HTTP 1.1 in a timely manner. This is a good argument to be having. Perhaps people should suggest concrete changes to the charter text instead of merely stating their opinions. Seems to me like we need some text that states what we don't have to accomplish regarding authentication, and some text that explicitly allows large scale editorial changes. > If you can get a draft in before Chicago, we could discuss it there > and either get them built into the WG's scope, or decide that they're > already within it, or even base the charter on your document. That would be great, but it's a lot of work, and that's a tight deadline. An outline sent to the list before the meeting would be enough, I think. > > BTW, structural changes have to be done first, using 2616 as > > the basis. There is no point of reviewing diffs of 2616 when > > nobody bothers to read 2616 as a whole. Diffs after restructuring > > can then be viewed in their proper context, with all of the relevant > > requirements in the same comprehensible space. > > That makes it seem that you're thinking of something more substantial > than a straight rearrangement. That's exactly the argument. If a "more substantial" rewrite does a better job of documenting HTTP, we should consider it. This possibility shouldn't cause discomfort, because our shared goal is to accurately document HTTP 1.1, right? On 6/1/07, Keith Moore wrote: > > so basically if you argue that the HTTP spec is so bad that a major > rewrite is needed, you're also arguing for > the rewritten HTTP spec to have a Proposed Standard status. (as was > done for [2]822 and SMTP). Personally, I don't care what color ribbon our pig wins at the county fair. :) On 6/1/07, Keith Moore wrote: > > is this because implementors tried to read the existing HTTP spec and > failed to grasp it, or because they didn't even bother trying to read > the spec? Here's a concrete example: I am sick of questions about this from people who have only read RFC2616. It's a waste of my time and theirs. -- Robert Sayre "I would have written a shorter letter, but I did not have the time." From discuss-bounces@apps.ietf.org Mon Jun 04 18:17:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvKrO-0001tg-LN; Mon, 04 Jun 2007 18:17:10 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HvKrM-0001tT-Sm for discuss-confirm+ok@megatron.ietf.org; Mon, 04 Jun 2007 18:17:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvKrM-0001tH-JA for discuss@apps.ietf.org; Mon, 04 Jun 2007 18:17:08 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvKrJ-0004wg-Bj for discuss@apps.ietf.org; Mon, 04 Jun 2007 18:17:07 -0400 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E0584142202; Mon, 4 Jun 2007 15:17:04 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bm2jI68DNNiQ; Mon, 4 Jun 2007 15:17:00 -0700 (PDT) Received: from [192.168.1.100] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 212B91421FB; Mon, 4 Jun 2007 15:17:00 -0700 (PDT) In-Reply-To: <7AB296E7-177E-4CDC-9347-4946152A3057@osafoundation.org> References: <7AB296E7-177E-4CDC-9347-4946152A3057@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: Use of LWSP in ABNF -- consensus call Date: Mon, 4 Jun 2007 15:16:58 -0700 To: Lisa Dusseault X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Apps Discuss , Paul Overell , Dave Crocker , IETF General Discussion Mailing List , ietf-dkim@mipassoc.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Since I composed this I saw additional opinions - one for doing nothing, and a couple that I interpreted as something stronger than a warning (e.g. "do not use in the future"). I still believe there to be rough consensus for a warning. If anybody can suggest (or repost) very specific text this could help the authors. Thanks, Lisa On May 22, 2007, at 4:29 PM, Lisa Dusseault wrote: > Thanks for everybody's input on this. I interpret the discussion > as showing consensus for a comment with a warning near the > definition of LWSP. > > Details: I counted 18 opinions. I couldn't see anybody arguing > for "no comment or text whatsoever". I saw arguments against > treating this as a Security Consideration. I saw opinions in > favour of "deprecating" the construct, but I am not sure if that's > an opinion for or against the health warning (since the definition > of deprecation is loose here). In any case, even if you count > those as "votes against" , I still see rough consensus. > > Lisa > > >> >> The IESG reviewed > crocker-rfc4234bis-00.txt> for publication as Internet Standard >> and would like to know if there is consensus to recommend against >> the use of LWSP in future specifications, as it has caused >> problems recently in DKIM and could cause problems in other places. >> >> Some discussion on this point already: >> - http://www1.ietf.org/mail-archive/web/ietf/current/msg46048.html >> - http://www1.ietf.org/mail-archive/web/discuss/current/ >> msg00463.html >> - http://mipassoc.org/pipermail/ietf-dkim/2007q1/007295.html >> - https://datatracker.ietf.org/public/pidtracker.cgi? >> command=view_comment&id=66440 (in this tracker comment, Chris >> Newman recommended to remove LWSP, but for backward-compatibility >> it's probably better to keep it and recommend against use) >> >> Thanks for your input, >> Lisa Dusseault >> >> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www1.ietf.org/mailman/listinfo/ietf > From discuss-bounces@apps.ietf.org Tue Jun 05 12:19:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvbkN-00037V-MG; Tue, 05 Jun 2007 12:19:03 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HvbkM-00031I-Me for discuss-confirm+ok@megatron.ietf.org; Tue, 05 Jun 2007 12:19:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvbkM-000303-Cd for discuss@apps.ietf.org; Tue, 05 Jun 2007 12:19:02 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvbkL-0006lu-47 for discuss@apps.ietf.org; Tue, 05 Jun 2007 12:19:02 -0400 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7715F142201 for ; Tue, 5 Jun 2007 09:19:00 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swPkvTbkCPDL for ; Tue, 5 Jun 2007 09:18:59 -0700 (PDT) Received: from [192.168.1.100] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 427621421FF for ; Tue, 5 Jun 2007 09:18:58 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Apps Discuss From: Lisa Dusseault Subject: Testers for new ID submission tool Date: Tue, 5 Jun 2007 09:18:57 -0700 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Anybody interested in testing the new ID submission tool? Russ asked for 10 names, let me know if you're going to be updating a draft or submitting a new draft and I'll pass the first ten names on to Russ. Thanks, Lisa From discuss-bounces@apps.ietf.org Tue Jun 05 12:21:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvbmh-0004j1-Ay; Tue, 05 Jun 2007 12:21:27 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hvbmf-0004ip-PY for discuss-confirm+ok@megatron.ietf.org; Tue, 05 Jun 2007 12:21:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvbmf-0004ih-FN for discuss@apps.ietf.org; Tue, 05 Jun 2007 12:21:25 -0400 Received: from purgatory.unfix.org ([2001:7b8:20d:0:290:27ff:fe24:c19f]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvbmf-0007nw-3D for discuss@apps.ietf.org; Tue, 05 Jun 2007 12:21:25 -0400 Received: from [IPv6:2001:770:100:9e::2] (spaghetti.unfix.org [IPv6:2001:770:100:9e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by purgatory.unfix.org (Postfix) with ESMTP id CE401140C0D3; Tue, 5 Jun 2007 18:21:23 +0200 (CEST) Message-ID: <46658D85.7050101@spaghetti.zurich.ibm.com> Date: Tue, 05 Jun 2007 17:21:25 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: Testers for new ID submission tool References: In-Reply-To: X-Enigmail-Version: 0.95.0 OpenPGP: id=333E7C23 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig940951F05E27BC9CD4934CB2" X-Virus-Scanned: ClamAV version 0.90.2, clamav-milter version 0.90.2 on purgatory.unfix.org X-Virus-Status: Clean X-Spam-Score: -2.8 (--) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig940951F05E27BC9CD4934CB2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Lisa Dusseault wrote: >=20 > Anybody interested in testing the new ID submission tool? Russ asked > for 10 names, let me know if you're going to be updating a draft or > submitting a new draft and I'll pass the first ten names on to Russ. Does it accept .xml's ? :) Greets, Jeroen --------------enig940951F05E27BC9CD4934CB2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkZljYUuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I34pAJ9Ra2jrgyZgEzXgNTd6aLIdIahS fQCeKlpQv4txVXTJvlH4MMjbAS0c4yQ= =OgL4 -----END PGP SIGNATURE----- --------------enig940951F05E27BC9CD4934CB2-- From discuss-bounces@apps.ietf.org Wed Jun 06 18:43:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw4DV-0001tX-Li; Wed, 06 Jun 2007 18:43:01 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hw4DU-0001tR-48 for discuss-confirm+ok@megatron.ietf.org; Wed, 06 Jun 2007 18:43:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw4DT-0001tG-Qh for discuss@apps.ietf.org; Wed, 06 Jun 2007 18:42:59 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw4DT-0005gR-00 for discuss@apps.ietf.org; Wed, 06 Jun 2007 18:42:59 -0400 Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l56MgwZ9025296 for ; Wed, 6 Jun 2007 22:42:58 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JJ800L01JYKWN00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for discuss@apps.ietf.org; Wed, 06 Jun 2007 16:42:58 -0600 (MDT) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JJ800DJEKFHG940@mail-amer.sun.com>; Wed, 06 Jun 2007 16:42:58 -0600 (MDT) Date: Wed, 06 Jun 2007 15:42:54 -0700 From: Chris Newman Subject: Re: Straw-man charter for http-bis In-reply-to: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> To: Mark Nottingham , "ietf-http-wg@w3.org Group" Message-id: <6AE049B9045C00064222693F@[10.1.110.5]> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Here's my take as AD on some of the interesting topics in this thread: 1. HTTP Digest Authentication The SASL WG appears to have decided that SASL DIGEST-MD5 is not a useful authentication mechanism for a number of technical reasons. I would be uncomfortable having a WG spend a lot of time refining the existing HTTP Digest mechanism based on that experience. However, documenting the i18n behavior of deployed implementations sounds like a sensible thing to do. 2. HTTP Security Phishing demonstrates that HTTP's present security mechanisms are not adequate to meet some important requirements of the present users of the protocol. I would be uncomfortable moving HTTP from Draft Standard to Standard given this situation. It's likely that new work on HTTP security mechanisms (as outlined by draft-hartman-webauth-phishing) is necessary. However, even with the present security situation, I have no doubt that RFC 2616 is widely useful and improving the technical clarity of the base specification is good work that would benefit the Internet community. The minimum work necessary to make a draft standard revision of the base specification complete would be to clearly document the limitations of the presently deployed HTTP security mechanisms and the fact they are not adequate for all situations. Beyond that I consider it inappropriate to hold publication of a useful revision hostage to new security engineering work. That opinion may not be shared by others on the IESG. Regardless, I would very much like to see forward progress on the HTTP security situation. 3. One vs. Two WGs I would support the formation of two separate WGs: HTTP and HTTP security as the people who have appropriate expertise for those efforts are not identical. Indeed I'd be uncomfortable with a single WG that was both revising 2616 and designing new HTTP security mechanisms as the latter may be helped by the attention of security experts that likely have no interest in the former. 4. Specification Rewrite Because the IETF process gives quite a bit of control to the document editor and design teams, our process allows an alternate editor to produce a competing specification and ask for a WG consensus call to adopt that competing specification. This is discussed in the following IESG Note: >From discussions here, I suspect it's unlikely an alternate specification would be adopted by the WG in this case, especially because it might drop the target status from draft to proposed for the reasons Keith mentioned. However, this is an important mechanism the keep the process open. - Chris Newman Applications Area Director From discuss-bounces@apps.ietf.org Thu Jun 07 04:40:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwDXM-0001ZK-GI; Thu, 07 Jun 2007 04:40:08 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HwDXL-0001ZC-By for discuss-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 04:40:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwDXL-0001Z4-20 for discuss@apps.ietf.org; Thu, 07 Jun 2007 04:40:07 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwDXJ-0007lk-Iu for discuss@apps.ietf.org; Thu, 07 Jun 2007 04:40:07 -0400 Received: (qmail invoked by alias); 07 Jun 2007 08:40:03 -0000 Received: from p508F9544.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.149.68] by mail.gmx.net (mp053) with SMTP; 07 Jun 2007 10:40:03 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/x1mR53rXxBoQXWERHjwu9R4TxXwv5Y9CaGwxnEe eLNq2NEn+PaZ27 Message-ID: <4667C461.5080704@gmx.de> Date: Thu, 07 Jun 2007 10:40:01 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Chris Newman Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@[10.1.110.5]> In-Reply-To: <6AE049B9045C00064222693F@[10.1.110.5]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: Apps Discuss , Mark Nottingham , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Chris Newman wrote: > > Here's my take as AD on some of the interesting topics in this thread: > > 1. HTTP Digest Authentication > > The SASL WG appears to have decided that SASL DIGEST-MD5 is not a useful > authentication mechanism for a number of technical reasons. I would be > uncomfortable having a WG spend a lot of time refining the existing HTTP > Digest mechanism based on that experience. However, documenting the > i18n behavior of deployed implementations sounds like a sensible thing > to do. Agreed. Q: if we found out that Digest can't be fixed for I18N without a minor incompatible change, would it make sense to define a "Digestbis" authentication scheme (assuming for a moment that server and UA developers would support it)? > 2. HTTP Security > > Phishing demonstrates that HTTP's present security mechanisms are not > adequate to meet some important requirements of the present users of the > protocol. I would be uncomfortable moving HTTP from Draft Standard to > Standard given this situation. It's likely that new work on HTTP Q: RFC2616 doesn't define security at all (except for the hooks used by RFC2617). Are you saying that RFC2616 can't be advanced to Full Standard without fixes to RFC2617? I guess this translates to the question: is the reference to RFC2617 normative or informative... (just looking for clarification here). > security mechanisms (as outlined by draft-hartman-webauth-phishing) is > necessary. However, even with the present security situation, I have no > doubt that RFC 2616 is widely useful and improving the technical clarity > of the base specification is good work that would benefit the Internet > community. The minimum work necessary to make a draft standard revision > of the base specification complete would be to clearly document the > limitations of the presently deployed HTTP security mechanisms and the > fact they are not adequate for all situations. Beyond that I consider > it inappropriate to hold publication of a useful revision hostage to new > security engineering work. That opinion may not be shared by others on > the IESG. Regardless, I would very much like to see forward progress on > the HTTP security situation. Agreed. > 3. One vs. Two WGs > > I would support the formation of two separate WGs: HTTP and HTTP > security as the people who have appropriate expertise for those efforts > are not identical. Indeed I'd be uncomfortable with a single WG that was > both revising 2616 and designing new HTTP security mechanisms as the > latter may be helped by the attention of security experts that likely > have no interest in the former. Agreed. There will be some overlap people-wise, but IMHO that's not a problem. Looking at RFC2617, there seem to be several areas that need work: (1) The framework itself, (2) Known issues with Basic and Digest (including I18N), (3) New schemes. Re (1): in practice, form based authentication is frequently used for the simple reason because people feel that the authentication related popups in browsers are insufficient/ugly/whatever. It would be really great if the people who are going to work on RFC2617bis co-operate with the W3C HTML working group on fixing this. > 4. Specification Rewrite > > Because the IETF process gives quite a bit of control to the document > editor and design teams, our process allows an alternate editor to > produce a competing specification and ask for a WG consensus call to > adopt that competing specification. This is discussed in the following > IESG Note: > >>> From discussions here, I suspect it's unlikely an alternate >>> specification would > be adopted by the WG in this case, especially because it might drop the > target status from draft to proposed for the reasons Keith mentioned. > However, this is an important mechanism the keep the process open. Agreed. Best regards, Julian From discuss-bounces@apps.ietf.org Thu Jun 07 08:28:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwH6b-0001u2-7z; Thu, 07 Jun 2007 08:28:45 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HwDS1-0006j3-54 for discuss-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 04:34:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwDS0-0006ip-9g for discuss@apps.ietf.org; Thu, 07 Jun 2007 04:34:36 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwDRy-00075Y-Tz for discuss@apps.ietf.org; Thu, 07 Jun 2007 04:34:36 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 7 Jun 2007 09:34:33 +0100 Message-ID: <4667C2C9.2000105@isode.com> Date: Thu, 07 Jun 2007 09:33:13 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Chris Newman Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@[10.1.110.5]> In-Reply-To: <6AE049B9045C00064222693F@[10.1.110.5]> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-Mailman-Approved-At: Thu, 07 Jun 2007 08:28:43 -0400 Cc: Apps Discuss , Mark Nottingham , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Chris Newman wrote: > Here's my take as AD on some of the interesting topics in this thread: > > 1. HTTP Digest Authentication > > The SASL WG appears to have decided that SASL DIGEST-MD5 is not a > useful authentication mechanism for a number of technical reasons. I > would be uncomfortable having a WG spend a lot of time refining the > existing HTTP Digest mechanism based on that experience. Indeed. But I think it might be worth just doing a revision of HTTP Basic, in particular to addresas i18n. I haven't yet made up my mind on whether this should happen in the HTTPbis or in another HTTPauth WG. > However, documenting the i18n behavior of deployed implementations > sounds like a sensible thing to do. From discuss-bounces@apps.ietf.org Thu Jun 07 11:45:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwKAV-000407-Dz; Thu, 07 Jun 2007 11:44:59 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HwKAU-000401-Rq for discuss-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 11:44:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwKAU-0003zt-IO for discuss@apps.ietf.org; Thu, 07 Jun 2007 11:44:58 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwKAU-0004nh-3E for discuss@apps.ietf.org; Thu, 07 Jun 2007 11:44:58 -0400 Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l57FisBS003281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jun 2007 08:44:56 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <6AE049B9045C00064222693F@[10.1.110.5]> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@[10.1.110.5]> Date: Thu, 7 Jun 2007 08:44:44 -0700 To: "ietf-http-wg@w3.org Group" , Apps Discuss From: Paul Hoffman Subject: Re: Straw-man charter for http-bis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org At 3:42 PM -0700 6/6/07, Chris Newman wrote: >1. HTTP Digest Authentication > >The SASL WG appears to have decided that SASL DIGEST-MD5 is not a >useful authentication mechanism for a number of technical reasons. >I would be uncomfortable having a WG spend a lot of time refining >the existing HTTP Digest mechanism based on that experience. >However, documenting the i18n behavior of deployed implementations >sounds like a sensible thing to do. It seems weird to do significant clarification work on 2616 and basically ignore 2617, given the normative reference to the latter. A better option would be to do full clarifications in 2617, including a discussion of the not-clarifiable internationalization issues. One such clarification is a list of the problems of HTTP Digest in the modern world. This probably should not take "a lot of time"; if it does, it means that the clarifications are all the more valuable. HTTP implementers who see a lot of work in 2616bis and nothing in 2617 will not necessarily come to the conclusion that the IETF wants; it would be better to have a 2617bis that says what we want to say. >2. HTTP Security > >Phishing demonstrates that HTTP's present security mechanisms are >not adequate to meet some important requirements of the present >users of the protocol. I would be uncomfortable moving HTTP from >Draft Standard to Standard given this situation. It's likely that >new work on HTTP security mechanisms (as outlined by >draft-hartman-webauth-phishing) is necessary. However, even with >the present security situation, I have no doubt that RFC 2616 is >widely useful and improving the technical clarity of the base >specification is good work that would benefit the Internet >community. The minimum work necessary to make a draft standard >revision of the base specification complete would be to clearly >document the limitations of the presently deployed HTTP security >mechanisms and the fact they are not adequate for all situations. Agree, but... >Beyond that I consider it inappropriate to hold publication of a >useful revision hostage to new security engineering work. That >opinion may not be shared by others on the IESG. Knowing ahead of time whether or not the work of this proposed WG is likely to get smacked down at the end by the IESG would greatly affect the people working on HTTPbis. >Regardless, I would very much like to see forward progress on the >HTTP security situation. draft-hartman-webauth-phishing generated no significant follow-on discussion that I can see (I would be happy to be mistaken). There are little bits of discussion here and there, but no momentum. Without a strong push from the Apps area for this work, I suspect that it will not happen or, if it does happen in a limited fashion, the results will not be widely adopted in implementations. >3. One vs. Two WGs > >I would support the formation of two separate WGs: HTTP and HTTP >security as the people who have appropriate expertise for those >efforts are not identical. Indeed I'd be uncomfortable with a single >WG that was both revising 2616 and designing new HTTP security >mechanisms as the latter may be helped by the attention of security >experts that likely have no interest in the former. Fair enough. >4. Specification Rewrite > >Because the IETF process gives quite a bit of control to the >document editor and design teams, our process allows an alternate >editor to produce a competing specification and ask for a WG >consensus call to adopt that competing specification. This is >discussed in the following IESG Note: > >>From discussions here, I suspect it's unlikely an alternate >>specification would >be adopted by the WG in this case, especially because it might drop >the target status from draft to proposed for the reasons Keith >mentioned. However, this is an important mechanism the keep the >process open. The status of the new document is *much* less important than its correctness and usability to HTTP implementers. From discuss-bounces@apps.ietf.org Thu Jun 07 12:01:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwKQK-0003rE-Kh; Thu, 07 Jun 2007 12:01:20 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HwKQI-0003qC-TT for discuss-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 12:01:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwKQI-0003pY-IN for discuss@apps.ietf.org; Thu, 07 Jun 2007 12:01:18 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwKQH-0003ol-4s for discuss@apps.ietf.org; Thu, 07 Jun 2007 12:01:18 -0400 Received: (qmail invoked by alias); 07 Jun 2007 16:01:16 -0000 Received: from p508F9544.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.149.68] by mail.gmx.net (mp004) with SMTP; 07 Jun 2007 18:01:16 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19wGag3G+9wUYPLmty4wgheyNHkxepdWhABOD3XBQ s3vpY2BNUySCY6 Message-ID: <46682BC9.9050504@gmx.de> Date: Thu, 07 Jun 2007 18:01:13 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Paul Hoffman Subject: RFC2616 vs RFC2617, was: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@[10.1.110.5]> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Apps Discuss , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Paul Hoffman wrote: > > At 3:42 PM -0700 6/6/07, Chris Newman wrote: >> 1. HTTP Digest Authentication >> >> The SASL WG appears to have decided that SASL DIGEST-MD5 is not a >> useful authentication mechanism for a number of technical reasons. I >> would be uncomfortable having a WG spend a lot of time refining the >> existing HTTP Digest mechanism based on that experience. However, >> documenting the i18n behavior of deployed implementations sounds like >> a sensible thing to do. > > It seems weird to do significant clarification work on 2616 and > basically ignore 2617, given the normative reference to the latter. A > better option would be to do full clarifications in 2617, including a > discussion of the not-clarifiable internationalization issues. One such > clarification is a list of the problems of HTTP Digest in the modern world. > > This probably should not take "a lot of time"; if it does, it means that > the clarifications are all the more valuable. HTTP implementers who see > a lot of work in 2616bis and nothing in 2617 will not necessarily come > to the conclusion that the IETF wants; it would be better to have a > 2617bis that says what we want to say. > ... Hi, maybe things become clearer if we consider re-organizing the security stuff? Currently, - RFC2616 refers (normatively?) to RFC2617 for authentication, and - RFC2617 defines a framework (Section 1.2) and two schemes (Basic and Digest). Assuming that there's no immediate need to change the framework defines in RCF2617, Section 1.2, wouldn't it make sense to: - Move the authentication framework itself into RFC2616bis, and - to then publish stand-alone documents upgrading/fixing both Basic and Digest? The benefits being: - RFC2616bis doesn't have the dependency on its sister spec anymore, which suffers from Basic and Digest problems, and - Basic, Digest and new schemes could evolve independently. Best regards, Julian From discuss-bounces@apps.ietf.org Thu Jun 07 12:11:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwKZp-0000LF-HJ; Thu, 07 Jun 2007 12:11:09 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HwKZn-0000Ju-JO for discuss-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 12:11:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwKZn-0000Jm-9c for discuss@apps.ietf.org; Thu, 07 Jun 2007 12:11:07 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwKZl-0008NB-Tp for discuss@apps.ietf.org; Thu, 07 Jun 2007 12:11:07 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 1F7FD1EE1AE; Thu, 7 Jun 2007 12:11:05 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3D2sDrK3dFx; Thu, 7 Jun 2007 12:10:10 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 5AE551EE1BA; Thu, 7 Jun 2007 12:09:55 -0400 (EDT) Message-ID: <46682DC3.2010405@cs.utk.edu> Date: Thu, 07 Jun 2007 12:09:39 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Paul Hoffman Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@[10.1.110.5]> In-Reply-To: X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Apps Discuss , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Paul Hoffman wrote: > It seems weird to do significant clarification work on 2616 and > basically ignore 2617, given the normative reference to the latter. A > better option would be to do full clarifications in 2617, including a > discussion of the not-clarifiable internationalization issues. One > such clarification is a list of the problems of HTTP Digest in the > modern world. > > This probably should not take "a lot of time"; if it does, it means > that the clarifications are all the more valuable. HTTP implementers > who see a lot of work in 2616bis and nothing in 2617 will not > necessarily come to the conclusion that the IETF wants; it would be > better to have a 2617bis that says what we want to say. 2617 doesn't need clarification, it needs to be deprecated and replaced with not only different schemes but an entirely different framework. I18N is the least of its problems. Maybe it would be useful to have an informational document that says what's wrong with 2617 and suggests how to fix the parts that are fixable, for the sake of sites that continue to use it, but I don't think such work should be critical path for either htttpbis or httpsec. > Knowing ahead of time whether or not the work of this proposed WG is > likely to get smacked down at the end by the IESG would greatly affect > the people working on HTTPbis. by "at the end" do you mean at RFC publication time, or charter time? If the latter, I agree; if the former, I think that's how the process is supposed to work. but basically IESG understands that HTTP is important and that it needs maintenance AND good security, and they're also going to understand that security work needs to happen in a separate group, so I think they're going to want to approve charters that further these ends rather than smack them down . > The status of the new document is *much* less important than its > correctness and usability to HTTP implementers. mostly agree, though it would be confusing to "outsiders" to have 2616 be at draft standard and a new, rewritten specification be at proposed. as for "correctness" that's fairly arbitrary. does it mean: the document that IETF says is correct (say via an applicability statement), the document that best reflects the "intent" of the protocol designers, the document that describes what works best in practice with today's (perhaps not tomorrow's) browsers and servers, or what? Keith From discuss-bounces@apps.ietf.org Thu Jun 07 12:12:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwKbL-0000Y5-Il; Thu, 07 Jun 2007 12:12:43 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HwKbK-0000Xr-Kl for discuss-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 12:12:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwKbK-0000XZ-5B for discuss@apps.ietf.org; Thu, 07 Jun 2007 12:12:42 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwKbI-00018N-UE for discuss@apps.ietf.org; Thu, 07 Jun 2007 12:12:42 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 7AE4B1EE1BE; Thu, 7 Jun 2007 12:12:40 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFRbg+uW6Z2y; Thu, 7 Jun 2007 12:11:49 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 24DD11EE1BF; Thu, 7 Jun 2007 12:11:01 -0400 (EDT) Message-ID: <46682E06.7030603@cs.utk.edu> Date: Thu, 07 Jun 2007 12:10:46 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Julian Reschke Subject: Re: RFC2616 vs RFC2617, was: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@[10.1.110.5]> <46682BC9.9050504@gmx.de> In-Reply-To: <46682BC9.9050504@gmx.de> X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Paul Hoffman , Apps Discuss , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org no. deprecate 2617. deprecate the framework that is in 2616. HTTP security needs a clean slate approach. > maybe things become clearer if we consider re-organizing the security > stuff? > > Currently, > > - RFC2616 refers (normatively?) to RFC2617 for authentication, and > > - RFC2617 defines a framework (Section 1.2) and two schemes (Basic and > Digest). > > Assuming that there's no immediate need to change the framework > defines in RCF2617, Section 1.2, wouldn't it make sense to: > > - Move the authentication framework itself into RFC2616bis, and > > - to then publish stand-alone documents upgrading/fixing both Basic > and Digest? > > The benefits being: > > - RFC2616bis doesn't have the dependency on its sister spec anymore, > which suffers from Basic and Digest problems, and > > - Basic, Digest and new schemes could evolve independently. > > Best regards, Julian > > > From discuss-bounces@apps.ietf.org Thu Jun 07 12:13:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwKcJ-0000os-E0; Thu, 07 Jun 2007 12:13:43 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HwKcI-0000of-KR for discuss-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 12:13:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwKcI-0000oX-Ao for discuss@apps.ietf.org; Thu, 07 Jun 2007 12:13:42 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwKcH-0001o4-SA for discuss@apps.ietf.org; Thu, 07 Jun 2007 12:13:42 -0400 Received: (qmail invoked by alias); 07 Jun 2007 16:13:41 -0000 Received: from p508F9544.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.149.68] by mail.gmx.net (mp045) with SMTP; 07 Jun 2007 18:13:41 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19b61RZ2BlbP5rognHy0Y1k97z4CKjgFI168ZykBL 09htwcCBAFihHH Message-ID: <46682EB2.5030900@gmx.de> Date: Thu, 07 Jun 2007 18:13:38 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Paul Hoffman Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@[10.1.110.5]> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Apps Discuss , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Paul Hoffman wrote: > ... >> Beyond that I consider it inappropriate to hold publication of a >> useful revision hostage to new security engineering work. That >> opinion may not be shared by others on the IESG. > > Knowing ahead of time whether or not the work of this proposed WG is > likely to get smacked down at the end by the IESG would greatly affect > the people working on HTTPbis. Definitively. It seems to me that the requirements to apply errata and clarifications to an existing specification (with wide deployment) should be completely different from those for new protocols. If they aren't, existing specs just won't get revised, because it's either too much work, irrelevant (considering running code), or impossible (backwards compatibility). >> Regardless, I would very much like to see forward progress on the HTTP >> security situation. > > draft-hartman-webauth-phishing generated no significant follow-on > discussion that I can see (I would be happy to be mistaken). There are > little bits of discussion here and there, but no momentum. Without a > strong push from the Apps area for this work, I suspect that it will not > happen or, if it does happen in a limited fashion, the results will not > be widely adopted in implementations. I believe that improvements in HTTP authentication require collaboration between implementors, namely UAs (Firefox, IE) and servers (httpd, IIS). We need to make that happen somehow. > ... >> 4. Specification Rewrite >> >> Because the IETF process gives quite a bit of control to the document >> editor and design teams, our process allows an alternate editor to >> produce a competing specification and ask for a WG consensus call to >> adopt that competing specification. This is discussed in the >> following IESG Note: >> >>>> From discussions here, I suspect it's unlikely an alternate >>> specification would >> be adopted by the WG in this case, especially because it might drop >> the target status from draft to proposed for the reasons Keith >> mentioned. However, this is an important mechanism the keep the >> process open. > > The status of the new document is *much* less important than its > correctness and usability to HTTP implementers. Correct. Almost nobody cares. Most people don't even understand the difference between Informational, Experimental, and Standards Track (sometimes I don't as well...). Best regards, Julian From discuss-bounces@apps.ietf.org Thu Jun 07 12:18:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwKgl-0000sT-Qy; Thu, 07 Jun 2007 12:18:19 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HwKgk-0000mV-Pn for discuss-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 12:18:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwKgk-0000kT-EG for discuss@apps.ietf.org; Thu, 07 Jun 2007 12:18:18 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwKgj-0003K7-1o for discuss@apps.ietf.org; Thu, 07 Jun 2007 12:18:18 -0400 Received: (qmail invoked by alias); 07 Jun 2007 16:18:15 -0000 Received: from p508F9544.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.149.68] by mail.gmx.net (mp055) with SMTP; 07 Jun 2007 18:18:15 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/vDV09khPvxRIy2zo8N8TwVRPzasw2YBE3Nw7+eT hXRkWtFRTzHkKZ Message-ID: <46682FC5.5030204@gmx.de> Date: Thu, 07 Jun 2007 18:18:13 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Keith Moore Subject: Re: RFC2616 vs RFC2617, was: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@[10.1.110.5]> <46682BC9.9050504@gmx.de> <46682E06.7030603@cs.utk.edu> In-Reply-To: <46682E06.7030603@cs.utk.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Paul Hoffman , Apps Discuss , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Keith Moore wrote: > no. deprecate 2617. deprecate the framework that is in 2616. HTTP > security needs a clean slate approach. I personally have no problem with this. In the wild, most authentication isn't using RFC2617 anyway. However, my understanding is that the IESG doesn't allow RFC2616bis not to discuss authentication in *some* manner. BTW: does the framework really require fixing? Best regards, Julian From discuss-bounces@apps.ietf.org Thu Jun 07 13:35:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwLtI-0006OZ-WD; Thu, 07 Jun 2007 13:35:21 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HwLtI-0006OU-8W for discuss-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 13:35:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwLtH-0006OM-VM for discuss@apps.ietf.org; Thu, 07 Jun 2007 13:35:19 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwLtE-0008Ax-Iv for discuss@apps.ietf.org; Thu, 07 Jun 2007 13:35:19 -0400 Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l57HZEGX026486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jun 2007 10:35:15 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <46682DC3.2010405@cs.utk.edu> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@[10.1.110.5]> <46682DC3.2010405@cs.utk.edu> Date: Thu, 7 Jun 2007 10:35:03 -0700 To: Keith Moore From: Paul Hoffman Subject: Re: Straw-man charter for http-bis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Apps Discuss , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org At 12:09 PM -0400 6/7/07, Keith Moore wrote: >2617 doesn't need clarification, it needs to be deprecated and replaced >with not only different schemes but an entirely different framework. We need to deal with the real world. In the real world, Basic and Digest Auth are used. In the real world, the better replacement for them is not deployed. It is fine for us to say "please stop doing that, use this instead", but it is myopic and unhelpful to deprecate something that is in widespread use. From discuss-bounces@apps.ietf.org Thu Jun 07 14:52:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwN6F-0007At-ON; Thu, 07 Jun 2007 14:52:47 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HwN6E-0007Aj-8W for discuss-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 14:52:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwN6D-0007Ab-Uz for discuss@apps.ietf.org; Thu, 07 Jun 2007 14:52:45 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwN6C-00076c-L0 for discuss@apps.ietf.org; Thu, 07 Jun 2007 14:52:45 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 07 Jun 2007 20:52:42 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l57Iqfkt016345; Thu, 7 Jun 2007 20:52:41 +0200 Received: from elear-mac.local (ams3-vpn-dhcp4229.cisco.com [10.61.80.132]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l57IqbDR001532; Thu, 7 Jun 2007 18:52:40 GMT Message-ID: <466853F5.6030609@cisco.com> Date: Thu, 07 Jun 2007 19:52:37 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Paul Hoffman Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@[10.1.110.5]> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1082; t=1181242361; x=1182106361; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20Straw-man=20charter=20for=20http-bis |Sender:=20; bh=lbcZL9rfb5bnfvAxnJPJDcGRrnMDkQ5W3xDTFV2UnJU=; b=RXqKen90QMBINAxq6pGuAQ9cZIOu+bI6ZZylgQM6qSdDAxQxxMBGIl1/nwvRU3LDc70b8epo 7NDkyx41KsZo8+UjnBXEZe9h7En2C8wjxcFxOnrhxwkUHMQBuXwq13Yn; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Apps Discuss , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Paul Hoffman wrote: > draft-hartman-webauth-phishing generated no significant follow-on > discussion that I can see (I would be happy to be mistaken). There are > little bits of discussion here and there, but no momentum. Without a > strong push from the Apps area for this work, I suspect that it will > not happen or, if it does happen in a limited fashion, the results > will not be widely adopted in implementations. I am forced to agree (sadly). We all need a good kick in the pants on this one. Sam has put together what I think is a fairly provocative requirements document (he provoked me to make a comment and a contribution or two ;-). Given the lack luster response, I don't think even I can support my early desire to see the security considerations of HTTP dealt with, and the situation is truly abysmal. And so I think we need to have two groups, and it's not even clear that we have enough support for the 2nd, right now. I'm CC'ing Sam, by the way, who can perhaps more accurately respond to what comments he's gotten. Eliot From discuss-bounces@apps.ietf.org Thu Jun 07 18:12:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwQDR-0003s3-Gg; Thu, 07 Jun 2007 18:12:25 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HwQDQ-0003rv-6r for discuss-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 18:12:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwQDP-0003rn-Td for discuss@apps.ietf.org; Thu, 07 Jun 2007 18:12:23 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwQDO-0001Zm-Lp for discuss@apps.ietf.org; Thu, 07 Jun 2007 18:12:23 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id E6E701EE1A1; Thu, 7 Jun 2007 18:12:21 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0qhFepKuXCL; Thu, 7 Jun 2007 18:12:09 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id D80421EE18A; Thu, 7 Jun 2007 18:12:08 -0400 (EDT) Message-ID: <466882A9.5010303@cs.utk.edu> Date: Thu, 07 Jun 2007 18:11:53 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Julian Reschke Subject: Re: RFC2616 vs RFC2617, was: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@[10.1.110.5]> <46682BC9.9050504@gmx.de> <46682E06.7030603@cs.utk.edu> <46682FC5.5030204@gmx.de> In-Reply-To: <46682FC5.5030204@gmx.de> X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Paul Hoffman , Apps Discuss , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Julian Reschke wrote: > Keith Moore wrote: >> no. deprecate 2617. deprecate the framework that is in 2616. HTTP >> security needs a clean slate approach. > > I personally have no problem with this. In the wild, most > authentication isn't using RFC2617 anyway. > > However, my understanding is that the IESG doesn't allow RFC2616bis > not to discuss authentication in *some* manner. I'm certain that there will have to be a good answer to the authentication question before 2616bis will be allowed to get any kind of standardization status. (it could probably be in a separate document). > BTW: does the framework really require fixing? I am pretty sure that it does. I think sites will continue to insist on being in control of the look and feel of the username/password dialog. I also think that the phishing concerns have to be dealt with. The two of these together make for an interesting set of constraints. Keith From discuss-bounces@apps.ietf.org Thu Jun 07 18:13:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwQEZ-0006NP-UY; Thu, 07 Jun 2007 18:13:35 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HwQEY-0006NF-Sk for discuss-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 18:13:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwQEY-0006N4-J0 for discuss@apps.ietf.org; Thu, 07 Jun 2007 18:13:34 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwQEX-0001l3-CW for discuss@apps.ietf.org; Thu, 07 Jun 2007 18:13:34 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 07DE71EE19E; Thu, 7 Jun 2007 18:13:33 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqoYn6KE7bg5; Thu, 7 Jun 2007 18:13:15 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id AADCA1EE152; Thu, 7 Jun 2007 18:13:14 -0400 (EDT) Message-ID: <466882EB.5060009@cs.utk.edu> Date: Thu, 07 Jun 2007 18:12:59 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Paul Hoffman Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@[10.1.110.5]> <46682DC3.2010405@cs.utk.edu> In-Reply-To: X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Apps Discuss , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Paul Hoffman wrote: > At 12:09 PM -0400 6/7/07, Keith Moore wrote: >> 2617 doesn't need clarification, it needs to be deprecated and replaced >> with not only different schemes but an entirely different framework. > > We need to deal with the real world. In the real world, Basic and > Digest Auth are used. In the real world, the better replacement for > them is not deployed. It is fine for us to say "please stop doing > that, use this instead", but it is myopic and unhelpful to deprecate > something that is in widespread use. basic and digest are used, but not widely. deprecate means "please stop doing that, use this instead". Keith From discuss-bounces@apps.ietf.org Thu Jun 07 18:25:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwQPz-0007nK-L7; Thu, 07 Jun 2007 18:25:23 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HwQPy-0007hQ-L6 for discuss-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 18:25:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwQPy-0007cO-9m for discuss@apps.ietf.org; Thu, 07 Jun 2007 18:25:22 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwQP7-0004hx-6W for discuss@apps.ietf.org; Thu, 07 Jun 2007 18:24:30 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 872D11EE187; Thu, 7 Jun 2007 18:24:28 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEzxrY2ttnM9; Thu, 7 Jun 2007 18:23:54 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id ECBEB1EE1C6; Thu, 7 Jun 2007 18:23:41 -0400 (EDT) Message-ID: <4668855E.7080409@cs.utk.edu> Date: Thu, 07 Jun 2007 18:23:26 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Paul Leach Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@10.1.110.5> <46682DC3.2010405@cs.utk.edu> <5c902b9e0706071057y5ad331acwc07439c50b08cc07@mail.gmail.com> <76323E9F0A911944A4E9225FACFC55BA04C3D4BC@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <76323E9F0A911944A4E9225FACFC55BA04C3D4BC@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Paul Hoffman , Apps Discuss , Justin Erenkrantz , ietf-http-wg@w3.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org 1. "A Proposed Standard should have no known technical omissions with respect to the requirements placed upon it." 2. Draft and full Standard documents must also meet the requirements for Proposed Standard. 3. "Security" is generally accepted as a requirement for all Internet standards-track protocols, but this is rather vague as the meaning of "security" varies from one protocol and use case to another. In the case of HTTP there is clearly a need for clients to be able to authenticate to servers, servers to be authenticate to clients, and for there to be a means to assure the secrecy of data passed between servers and clients. > For a long time, the IESG has required that all new protocols have a > "security considerations" section. I have not heard that that has > changed to a more stringent mandate. For many protocols, including > HTTP, that section would have to show that they are securable. > However, in addition, IMO it is obvious that for HTTP, that section > also says that anonymous clients and unauthenticated servers are OK > in many circumstances, and here are the mechanisms that can be used > when it isn't OK. From discuss-bounces@apps.ietf.org Thu Jun 07 18:27:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwQRi-0000XY-F5; Thu, 07 Jun 2007 18:27:10 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HwQRg-0000Ir-O8 for discuss-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 18:27:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwQRg-0000Gz-CZ for discuss@apps.ietf.org; Thu, 07 Jun 2007 18:27:08 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwQRf-00063f-6A for discuss@apps.ietf.org; Thu, 07 Jun 2007 18:27:08 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id B89B71EE174; Thu, 7 Jun 2007 18:27:06 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hlz0fsSHeM3v; Thu, 7 Jun 2007 18:26:58 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 8D59C1EE152; Thu, 7 Jun 2007 18:26:57 -0400 (EDT) Message-ID: <46688622.5030305@cs.utk.edu> Date: Thu, 07 Jun 2007 18:26:42 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Justin Erenkrantz Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@10.1.110.5> <46682DC3.2010405@cs.utk.edu> <5c902b9e0706071057y5ad331acwc07439c50b08cc07@mail.gmail.com> In-Reply-To: <5c902b9e0706071057y5ad331acwc07439c50b08cc07@mail.gmail.com> X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Paul Hoffman , Apps Discuss , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > I think that *mandating* that we use > SSL (or some similar connection-oriented security mechanism) for *all* > Web traffic is going to kill everyone. IETF has no means of doing that anyway. The most we can do is make recommendations. So when we use the word "deprecate" it just means we are withdrawing our previous recommendation to use something. We don't pretend we can stop users from doing something that make sense to them, or even that we can stop users from doing things that make no sense at all. Keith From discuss-bounces@apps.ietf.org Thu Jun 07 19:16:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwRDP-0008L1-SR; Thu, 07 Jun 2007 19:16:27 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HwRDO-0008Km-Rr for discuss-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 19:16:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwRDO-0008Ke-Hu for discuss@apps.ietf.org; Thu, 07 Jun 2007 19:16:26 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwRDN-0007Ww-9R for discuss@apps.ietf.org; Thu, 07 Jun 2007 19:16:26 -0400 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B943A14220E; Thu, 7 Jun 2007 16:16:24 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yg9dJGz9NJ5Q; Thu, 7 Jun 2007 16:16:23 -0700 (PDT) Received: from [10.1.1.203] (ip10.commerce.net [157.22.41.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id C0CDB142201; Thu, 7 Jun 2007 16:16:22 -0700 (PDT) In-Reply-To: <76323E9F0A911944A4E9225FACFC55BA04C3D4BC@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@10.1.110.5> <46682DC3.2010405@cs.utk.edu> <5c902b9e0706071057y5ad331acwc07439c50b08cc07@mail.gmail.com> <76323E9F0A911944A4E9225FACFC55BA04C3D4BC@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: Straw-man charter for http-bis Date: Thu, 7 Jun 2007 16:16:20 -0700 To: Paul Leach X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Paul Hoffman , Apps Discuss , Keith Moore , Justin Erenkrantz , ietf-http-wg@w3.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Jun 7, 2007, at 11:03 AM, Paul Leach wrote: > > For a long time, the IESG has required that all new protocols have a > "security considerations" section. I have not heard that that has > changed to a more stringent mandate. There's a little more, mostly in RFC3552, e.g. "Unprotected (plaintext) username/password systems are not acceptable in IETF standards." > For many protocols, including HTTP, > that section would have to show that they are securable. However, in > addition, IMO it is obvious that for HTTP, that section also says that > anonymous clients and unauthenticated servers are OK in many > circumstances, and here are the mechanisms that can be used when it > isn't OK. +1 Lisa From discuss-bounces@apps.ietf.org Fri Jun 08 04:10:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwZYP-0007Sa-Me; Fri, 08 Jun 2007 04:10:41 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HwZYN-0007SJ-5T for discuss-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 04:10:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwZYM-0007S9-6y for discuss@apps.ietf.org; Fri, 08 Jun 2007 04:10:38 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwZYJ-0006nu-Tb for discuss@apps.ietf.org; Fri, 08 Jun 2007 04:10:38 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id E01FB1C0101; Fri, 8 Jun 2007 10:10:34 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id DB0CD1C00F1; Fri, 8 Jun 2007 10:10:32 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id CD83558ED1E; Fri, 8 Jun 2007 10:10:32 +0200 (CEST) Date: Fri, 8 Jun 2007 10:10:32 +0200 From: Stephane Bortzmeyer To: Julian Reschke Subject: Re: RFC2616 vs RFC2617, was: Straw-man charter for http-bis Message-ID: <20070608081032.GA12039@nic.fr> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@[10.1.110.5]> <46682BC9.9050504@gmx.de> <46682E06.7030603@cs.utk.edu> <46682FC5.5030204@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46682FC5.5030204@gmx.de> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Apps Discuss , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Thu, Jun 07, 2007 at 06:18:13PM +0200, Julian Reschke wrote a message of 14 lines which said: > In the wild, most authentication isn't using RFC2617 anyway. Any data here? IMHO, this assertion is not true, unless you limit to big e-commerce Web sites. For instance, HTTP-based Web services use 2617. Also, 2617 is typically the simplest way for a small and rapidly setup Web site, even if it does not have the visibility of Amazon. From discuss-bounces@apps.ietf.org Fri Jun 08 08:25:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwdWq-0000Td-KO; Fri, 08 Jun 2007 08:25:20 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hwbrx-0002Mr-BW for discuss-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 06:39:01 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hwbrx-0002Mb-26 for discuss@apps.ietf.org; Fri, 08 Jun 2007 06:39:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwbrN-0000ty-Ts for discuss@apps.ietf.org; Fri, 08 Jun 2007 06:38:25 -0400 Received: from smtp.aaisp.net.uk ([2001:8b0:0:81::51bb:5133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwbrL-0004cE-In for discuss@apps.ietf.org; Fri, 08 Jun 2007 06:38:25 -0400 Received: from mail.manyfish.co.uk ([81.187.127.133]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.62) (envelope-from ) id 1HwbrE-0003gO-OG; Fri, 08 Jun 2007 11:38:16 +0100 Received: from joe by mail.manyfish.co.uk with local (Exim 4.63) (envelope-from ) id 1HwbrC-0002F4-Eo; Fri, 08 Jun 2007 11:38:14 +0100 Date: Fri, 8 Jun 2007 11:38:14 +0100 From: Joe Orton To: Keith Moore Subject: Re: RFC2616 vs RFC2617, was: Straw-man charter for http-bis Message-ID: <20070608103814.GA6204@manyfish.co.uk> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@[10.1.110.5]> <46682BC9.9050504@gmx.de> <46682E06.7030603@cs.utk.edu> <46682FC5.5030204@gmx.de> <466882A9.5010303@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <466882A9.5010303@cs.utk.edu> User-Agent: Mutt/1.4.2.2i X-Spam-Score: -2.8 (--) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-TMDA-Confirmed: Fri, 08 Jun 2007 06:39:01 -0400 X-Mailman-Approved-At: Fri, 08 Jun 2007 08:25:18 -0400 Cc: Paul Hoffman , "ietf-http-wg@w3.org Group" , Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Thu, Jun 07, 2007 at 06:11:53PM -0400, Keith Moore wrote: > Julian Reschke wrote: > > BTW: does the framework really require fixing? > > I am pretty sure that it does. I think sites will continue to insist on > being in control of the look and feel of the username/password dialog. Fixing that does not require any changes to the HTTP auth framework. Roy pointed out a long time ago that this can be done simply by defining an extension to HTML which allows an HTML 401/407 response body to contain a form which is used to enter credentials.
or something. (and possibly some method for browsers to advertise support for this) joe From discuss-bounces@apps.ietf.org Fri Jun 08 08:25:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwdWq-0000SG-1j; Fri, 08 Jun 2007 08:25:20 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HwMLX-0005YR-4z for discuss-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 14:04:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwMLW-0005YJ-Ri for From discuss-bounces@apps.ietf.org Fri Jun 08 08:25:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwdWq-0000Td-KO; Fri, 08 Jun 2007 08:25:20 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hwbrx-0002Mr-BW for discuss-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 06:39:01 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hwbrx-0002Mb-26 for discuss@apps.ietf.org; Fri, 08 Jun 2007 06:39:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwbrN-0000ty-Ts for discuss@apps.ietf.org; Fri, 08 Jun 2007 06:38:25 -0400 Received: from smtp.aaisp.net.uk ([2001:8b0:0:81::51bb:5133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwbrL-0004cE-In for discuss@apps.ietf.org; Fri, 08 Jun 2007 06:38:25 -0400 Received: from mail.manyfish.co.uk ([81.187.127.133]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.62) (envelope-from ) id 1HwbrE-0003gO-OG; Fri, 08 Jun 2007 11:38:16 +0100 Received: from joe by mail.manyfish.co.uk with local (Exim 4.63) (envelope-from ) id 1HwbrC-0002F4-Eo; Fri, 08 Jun 2007 11:38:14 +0100 Date: Fri, 8 Jun 2007 11:38:14 +0100 From: Joe Orton To: Keith Moore Subject: Re: RFC2616 vs RFC2617, was: Straw-man charter for http-bis Message-ID: <20070608103814.GA6204@manyfish.co.uk> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@[10.1.110.5]> <46682BC9.9050504@gmx.de> <46682E06.7030603@cs.utk.edu> <46682FC5.5030204@gmx.de> <466882A9.5010303@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <466882A9.5010303@cs.utk.edu> User-Agent: Mutt/1.4.2.2i X-Spam-Score: -2.8 (--) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-TMDA-Confirmed: Fri, 08 Jun 2007 06:39:01 -0400 X-Mailman-Approved-At: Fri, 08 Jun 2007 08:25:18 -0400 Cc: Paul Hoffman , "ietf-http-wg@w3.org Group" , Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Thu, Jun 07, 2007 at 06:11:53PM -0400, Keith Moore wrote: > Julian Reschke wrote: > > BTW: does the framework really require fixing? > > I am pretty sure that it does. I think sites will continue to insist on > being in control of the look and feel of the username/password dialog. Fixing that does not require any changes to the HTTP auth framework. Roy pointed out a long time ago that this can be done simply by defining an extension to HTML which allows an HTML 401/407 response body to contain a form which is used to enter credentials. or something. (and possibly some method for browsers to advertise support for this) joe From discuss-bounces@apps.ietf.org Fri Jun 08 08:25:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwdWq-0000SG-1j; Fri, 08 Jun 2007 08:25:20 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HwMLX-0005YR-4z for discuss-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 14:04:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwMLW-0005YJ-Ri for discuss@apps.ietf.org; Thu, 07 Jun 2007 14:04:30 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwMLV-00082M-GA for discuss@apps.ietf.org; Thu, 07 Jun 2007 14:04:30 -0400 Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.700.0; Thu, 7 Jun 2007 11:03:15 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) with Microsoft SMTP Server id 8.0.726.0; Thu, 7 Jun 2007 11:04:16 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Jun 2007 11:04:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Straw-man charter for http-bis Date: Thu, 7 Jun 2007 11:03:59 -0700 Message-ID: <76323E9F0A911944A4E9225FACFC55BA04C3D4BC@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <5c902b9e0706071057y5ad331acwc07439c50b08cc07@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Straw-man charter for http-bis thread-index: AcepLWCfTcew93qiTdCkzC15ZBGGNQAAA6zw References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@10.1.110.5> <46682DC3.2010405@cs.utk.edu> <5c902b9e0706071057y5ad331acwc07439c50b08cc07@mail.gmail.com> From: Paul Leach To: Justin Erenkrantz , Paul Hoffman X-OriginalArrivalTime: 07 Jun 2007 18:04:16.0618 (UTC) FILETIME=[434EDCA0:01C7A92E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-Mailman-Approved-At: Fri, 08 Jun 2007 08:25:18 -0400 Cc: Apps Discuss , Keith Moore , ietf-http-wg@w3.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org For a long time, the IESG has required that all new protocols have a "security considerations" section. I have not heard that that has changed to a more stringent mandate. For many protocols, including HTTP, that section would have to show that they are securable. However, in addition, IMO it is obvious that for HTTP, that section also says that anonymous clients and unauthenticated servers are OK in many circumstances, and here are the mechanisms that can be used when it isn't OK. -----Original Message----- From: Justin Erenkrantz Sent: Thursday, June 07, 2007 1:57 PM Furthermore, my understanding is that IESG now requires all new protocols to always be secure. =20 discuss@apps.ietf.org; Thu, 07 Jun 2007 14:04:30 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwMLV-00082M-GA for discuss@apps.ietf.org; Thu, 07 Jun 2007 14:04:30 -0400 Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.700.0; Thu, 7 Jun 2007 11:03:15 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) with Microsoft SMTP Server id 8.0.726.0; Thu, 7 Jun 2007 11:04:16 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Jun 2007 11:04:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Straw-man charter for http-bis Date: Thu, 7 Jun 2007 11:03:59 -0700 Message-ID: <76323E9F0A911944A4E9225FACFC55BA04C3D4BC@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <5c902b9e0706071057y5ad331acwc07439c50b08cc07@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Straw-man charter for http-bis thread-index: AcepLWCfTcew93qiTdCkzC15ZBGGNQAAA6zw References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@10.1.110.5> <46682DC3.2010405@cs.utk.edu> <5c902b9e0706071057y5ad331acwc07439c50b08cc07@mail.gmail.com> From: Paul Leach To: Justin Erenkrantz , Paul Hoffman X-OriginalArrivalTime: 07 Jun 2007 18:04:16.0618 (UTC) FILETIME=[434EDCA0:01C7A92E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-Mailman-Approved-At: Fri, 08 Jun 2007 08:25:18 -0400 Cc: Apps Discuss , Keith Moore , ietf-http-wg@w3.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org For a long time, the IESG has required that all new protocols have a "security considerations" section. I have not heard that that has changed to a more stringent mandate. For many protocols, including HTTP, that section would have to show that they are securable. However, in addition, IMO it is obvious that for HTTP, that section also says that anonymous clients and unauthenticated servers are OK in many circumstances, and here are the mechanisms that can be used when it isn't OK. -----Original Message----- From: Justin Erenkrantz Sent: Thursday, June 07, 2007 1:57 PM Furthermore, my understanding is that IESG now requires all new protocols to always be secure. =20 From discuss-bounces@apps.ietf.org Fri Jun 08 08:25:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwdWq-0000SL-67; Fri, 08 Jun 2007 08:25:20 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HwPPd-00074O-1x for discuss-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 17:20:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwPMb-0004t6-JC for discuss@apps.ietf.org; Thu, 07 Jun 2007 17:17:49 -0400 Received: from av9-1-sn3.vrr.skanova.net ([81.228.9.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwPIE-0004uH-76 for discuss@apps.ietf.org; Thu, 07 Jun 2007 17:13:18 -0400 Received: by av9-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 60DF237EF4; Thu, 7 Jun 2007 23:13:16 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av9-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 485C837EB7; Thu, 7 Jun 2007 23:13:16 +0200 (CEST) Received: from henriknordstrom.net (81-233-163-21-no84.tbcn.telia.com [81.233.163.21]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id DF75E37E47; Thu, 7 Jun 2007 23:13:14 +0200 (CEST) Received: from [192.168.1.2] (henriknordstrom.net [192.168.1.2]) by henriknordstrom.net (8.12.11.20060308/8.12.8) with ESMTP id l57LDEwd028790; Thu, 7 Jun 2007 23:13:14 +0200 Subject: Re: Straw-man charter for http-bis From: Henrik Nordstrom To: Chris Newman In-Reply-To: <6AE049B9045C00064222693F@[10.1.110.5]> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@[10.1.110.5]> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-cVn+pzHiifINwEsr15wt" Date: Thu, 07 Jun 2007 23:13:14 +0200 Message-Id: <1181250794.24162.109.camel@henriknordstrom.net> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on henriknordstrom.net X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 X-Mailman-Approved-At: Fri, 08 Jun 2007 08:25:19 -0400 Cc: Apps Discuss , Mark Nottingham , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --=-cVn+pzHiifINwEsr15wt Content-Type: text/plain Content-Transfer-Encoding: quoted-printable ons 2007-06-06 klockan 15:42 -0700 skrev Chris Newman: > 2. HTTP Security >=20 > Phishing demonstrates that HTTP's present security mechanisms are not ade= quate=20 > to meet some important requirements of the present users of the protocol.= I=20 > would be uncomfortable moving HTTP from Draft Standard to Standard given = this=20 > situation. It's likely that new work on HTTP security mechanisms (as out= lined=20 > by draft-hartman-webauth-phishing) is necessary. Just a reflection on the phishing problem. IMHO this is more of an UA and education problem, not so much a protocol problem even if having something more secure than Digest would be a good thing. But you should also be aware that making HTTP authentication stronger won't make any of the common forms of phishing much harder. The most common form of phishing is for collecting non-HTTP details about the user such as credit card details or bank accounts, or for phishing of the users login details to some financial service (bank or similar), but such services tend to stop using static passwords once hit.. There is imho three primary reasons why Digest has not gained much foothold, neither being security. a) Implementation rather complex, with few if any implementation getting it entirely right.. b) It's inability to integrate well with existing authentication frameworks on the server side. c) UA integration, or web site owners requiring control over the login process beyond a standard "login+password" dialog. Then there is also the single-sign-on issue, but thats more of an implementation thing than protocol. Digest fits just as fine in single-sign-on models as the NTLM or Negotiate schemes widely deployed for the purpose today, but due to it being a different authentication mechanism than used for the desktop it's not used in that context. Even if HTTP had the strongest authentication possible, fulfilling the goals of draft-hartman-webauth-phishing etc, phishing would still be equally possible by the exact same means used today. Or as long as the primary key to the authentication process is a some piece of static information provided by the user. The phishing attacks is a soscial enginering attack on the weakness of any static shared secret authentication mechanism. Works for login +password, works for credit card details, works for bank account details, works for very many forms of identity theft based on the user providing any form of static secret. Also in coming up with a usable secure authentication scheme to replace Digest it's important to not underestimate the integration into existing systems. Equally important is the complexity of implementation. Very few if any (certainly none of the commonly used browsers) implement Digest correctly even if the ambiguous or weak parts of the specification is taken aside. Also it's worth noting that TLS + Digest already fulfills most of the requirements of draft-hartman-webauth-phishing. There is some like the enrollment criteria it do not address however. > However, even with the=20 > present security situation, I have no doubt that RFC 2616 is widely usefu= l and=20 > improving the technical clarity of the base specification is good work th= at=20 > would benefit the Internet community. It certainly is. RFC2616 provides the message protocol basics and anonymous access to content, with hooks to hook in pretty much any message authentication scheme. > The minimum work necessary to make a=20 > draft standard revision of the base specification complete would be to cl= early=20 > document the limitations of the presently deployed HTTP security mechanis= ms and=20 > the fact they are not adequate for all situations. Beyond that I conside= r it=20 > inappropriate to hold publication of a useful revision hostage to new sec= urity=20 > engineering work. Good. > 3. One vs. Two WGs >=20 > I would support the formation of two separate WGs: HTTP and HTTP security= as=20 > the people who have appropriate expertise for those efforts are not ident= ical. The people revising RFC2616 and 2617 to clarify the specifications and prune out ambiguities or other specification errors could well be the same group, but the group coming up with a secure message authentication scheme beyond digest needs a quite different group of people and is not really HTTP related. Such scheme is needed all over the computing industry, covering pretty much all protocols not just HTTP. The problems in coming up with such scheme is by no means HTTP specific. > Indeed I'd be uncomfortable with a single WG that was both revising 2616 = and=20 > designing new HTTP security mechanisms as the latter may be helped by the= =20 > attention of security experts that likely have no interest in the former. Exactly. > From discussions here, I suspect it's unlikely an alternate specification= would=20 > be adopted by the WG in this case, especially because it might drop the t= arget=20 > status from draft to proposed for the reasons Keith mentioned. However, = this=20 > is an important mechanism the keep the process open. I would probably not be very comfortable with an largely rewritten alternate specification within the target of specifying HTTP/1.1. If the goal was to make a revision of HTTP and not a revision of RFC2616 then yes, or even a requirement for such work. But I do not rule it out entirely as there is many things about the structure of RFC2616 which could be done better to not confuse new readers so much.. Regards Henrik --=-cVn+pzHiifINwEsr15wt Content-Type: application/pgp-signature; name=signature.asc Content-Description: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad meddelandedel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iQCVAwUARmh050NPQ5Kbx8daAQLKrQQAuOki9u0onkHVmn6eN9/jOwQzVqzCaMmx b9vwQ0pFEownIUjh4gGW0snKqi3xjsp6wjG6Wiq5FuIbZCAgK3obG8GGMzXZKsu2 RXceG7V3M/zk8vwOh0dhVeh7te+5M+fPq+iyUHgPgFyirrV97yBEBW93Fqxok7lV wM6nxyf78qs= =Q6vP -----END PGP SIGNATURE----- --=-cVn+pzHiifINwEsr15wt-- From discuss-bounces@apps.ietf.org Fri Jun 08 08:25:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwdWq-0000SQ-AG; Fri, 08 Jun 2007 08:25:20 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HwQ5O-0002m3-JO for discuss-confirm+ok@megatron.ietf.org; Thu, 07 Jun 2007 18:04:06 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HwQ5O-0002lv-A7 for discuss@apps.ietf.org; Thu, 07 Jun 2007 18:04:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwQ4i-0002fq-6W for discuss@apps.ietf.org; Thu, 07 Jun 2007 18:03:24 -0400 Received: from dsl.ingostruck.de ([85.183.48.31] helo=neo.rs) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwQ4g-0007zf-KN for discuss@apps.ietf.org; Thu, 07 Jun 2007 18:03:24 -0400 Received: (qmail 2185 invoked by uid 500); 7 Jun 2007 23:14:13 -0000 From: lists@ingostruck.de To: Henrik Nordstrom Subject: Re: RFC2616 vs RFC2617, was: Straw-man charter for http-bis Date: Thu, 7 Jun 2007 23:14:11 +0000 User-Agent: KMail/1.8.2 References: <6AE049B9045C00064222693F@[10.1.110.5]> <1181250794.24162.109.camel@henriknordstrom.net> In-Reply-To: <1181250794.24162.109.camel@henriknordstrom.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200706072314.13575.lists@ingostruck.de> X-Spam-Score: 0.2 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-TMDA-Confirmed: Thu, 07 Jun 2007 18:04:06 -0400 X-Mailman-Approved-At: Fri, 08 Jun 2007 08:25:18 -0400 Cc: Apps Discuss , Mark Nottingham , Chris Newman , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Henrik, > There is imho three primary reasons why Digest has not gained much > foothold, neither being security. > > a) Implementation rather complex, with few if any implementation getting > it entirely right.. > > b) It's inability to integrate well with existing authentication > frameworks on the server side. > > c) UA integration, or web site owners requiring control over the login > process beyond a standard "login+password" dialog. I think that you got that perfectly right. My opinion is, that a) could be improved by a strictly editorial revision of RFC2617 while c) requires substantial revision of the contents. I do not consider b) to be a problem of the spec but of the implementors. For me it seems that the real obstacle for RFC2617's popularity is c). People just seem to insist on having their authentication procedure in the "look-and-feel" they want it to be and concrete-cast it into their HTML/flash/whatever-content (even though that may seem to be a silly idea from a usability point of view). Maybe a solution just like rfc2388 could be suitable here. Needed is a well-defined way to interact between the application and the protocol -- the only difference here is, that the auth stuff needs to interact with the HTTP header, while the form submission stuff needed/needs to interact with the HTTP POST body. I guess that a similar "bridge" could be a solution for the problem. Of course that would need interaction with HTML, e.g. it would need the introduction of together with or the like, which are defined to have their contents be passed on to a well-defined HTTP-Auth scheme. It could even be done without the need to (substantially) change the HTML spec, e.g. by reserving special form element ids for that purpose, lets say or the like. Having that said I would tend to use a double tracked approach: - editorial revision of rfc2617 to make existing impls or new impls that have to interact with them happy - simultaneously develop a "completely new" scheme that does not have the fundamental deficiency of being unable to interact with the "application layer" Kind regards Ingo Struck From discuss-bounces@apps.ietf.org Fri Jun 08 08:25:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwdWq-0000TK-FG; Fri, 08 Jun 2007 08:25:20 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HwZkY-0001va-31 for discuss-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 04:23:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwZkX-0001vS-Mu for discuss@apps.ietf.org; Fri, 08 Jun 2007 04:23:13 -0400 Received: from dsl.ingostruck.de ([85.183.48.31]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwZkW-00054x-5C for discuss@apps.ietf.org; Fri, 08 Jun 2007 04:23:13 -0400 Received: (qmail 2686 invoked by uid 500); 8 Jun 2007 09:34:06 -0000 From: lists@ingostruck.de To: Stephane Bortzmeyer Subject: Re: RFC2616 vs RFC2617, was: Straw-man charter for http-bis Date: Fri, 8 Jun 2007 09:34:04 +0000 User-Agent: KMail/1.8.2 References: <46682FC5.5030204@gmx.de> <20070608081032.GA12039@nic.fr> In-Reply-To: <20070608081032.GA12039@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200706080934.06204.lists@ingostruck.de> X-Spam-Score: 0.2 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-Mailman-Approved-At: Fri, 08 Jun 2007 08:25:19 -0400 Cc: Apps Discuss , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Friday 08 June 2007 08:10, Stephane Bortzmeyer wrote: > On Thu, Jun 07, 2007 at 06:18:13PM +0200, > Julian Reschke wrote > > a message of 14 lines which said: > > In the wild, most authentication isn't using RFC2617 anyway. > > Any data here? IMHO, this assertion is not true, unless you limit to > big e-commerce Web sites. For instance, HTTP-based Web services use > 2617. Also, 2617 is typically the simplest way for a small and rapidly > setup Web site, even if it does not have the visibility of Amazon. Apart from that there is an applications where rfc2617 imho currently is the only widely usable auth scheme: restricted proxies. If you want to have a semi-public proxy that needs auth, anything else but using rfc2617 Proxy-Authentication is a pain. If you do not want plaintext credentials, rfc2617 digest currently remains the only working option (at least for me, but admittedly this doesn't say anything about "widespread-use"). Kind regards Ingo Struck From discuss-bounces@apps.ietf.org Fri Jun 08 10:46:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwfiz-0006QI-Bz; Fri, 08 Jun 2007 10:46:01 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hwfiy-0006O7-7X for discuss-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 10:46:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwfix-0006Nz-UJ for discuss@apps.ietf.org; Fri, 08 Jun 2007 10:45:59 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwfix-0001ro-J6 for discuss@apps.ietf.org; Fri, 08 Jun 2007 10:45:59 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 08 Jun 2007 16:45:59 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l58Ejw4F009953; Fri, 8 Jun 2007 16:45:58 +0200 Received: from elear-mac.local (ams3-vpn-dhcp597.cisco.com [10.61.66.85]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l58EjiDR002055; Fri, 8 Jun 2007 14:45:48 GMT Message-ID: <46696B98.1090201@cisco.com> Date: Fri, 08 Jun 2007 15:45:44 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Henrik Nordstrom Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@[10.1.110.5]> <1181250794.24162.109.camel@henriknordstrom.net> In-Reply-To: <1181250794.24162.109.camel@henriknordstrom.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3022; t=1181313958; x=1182177958; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20Straw-man=20charter=20for=20http-bis |Sender:=20; bh=o/U5clIu9BWstwX/q/7M+57bN7x/nCIn3pbvtksg8wQ=; b=O3j6LY/pt4CHXJBvPM5VdGtcma1vGlcEfHn/ycKKPk6PSt/VKmervfMbOmCJ8h0/Te+LO3Hz jA6YkG1SQxTjlTTyBrcOyQc9QRGmwjO7E9bSG4o5I4CRcQ6UGeMeOOfo; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Apps Discuss , Mark Nottingham , Chris Newman , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Henrik Nordstrom wrote: > Just a reflection on the phishing problem. > > IMHO this is more of an UA and education problem, not so much a protocol > problem even if having something more secure than Digest would be a good > thing. But you should also be aware that making HTTP authentication > stronger won't make any of the common forms of phishing much harder. > I disagree in the strongest possible terms. This *is* a problem we can solve technically. It's just that no one has the will to do it and we've organized ourselves so that the work cannot be done in one place. If you had a component that was separate from your workstation, that had but a single function – authentication – we could write appropriate APIs and protocols to access that device such that you would never log in without using it. The riskiest functions would be registration. In that single area would I view this an education problem, but even there, if we came up with a standard way to legitimately register individuals we could probably make that problem much more solvable. The problem is this: * Registration and authentication occur with the forms interface that W3C handles; * The APIs are owned in large part by Microsoft and IEEE (POSIX); * IETF owns the wire protocol * Smartcard design is done by numerous (ISO, IEEE, other) But to not attempt to solve these problems is dereliction of duty to the community we as an organization are supposed to be serving. The LEAST the IETF can do is put forth an authentication mechanism that solves the wire protocol problem. It should jive with the other functions as they evolve and provide flexibility to the organizations in question to offer opaque communications so we can have better authentication mechanisms as time goes on. It's just shameful. And yes, I suppose I'm being a bit emotive, but we have GOT to get off the dime, and the ONLY work that does so in this space right now is Sam's draft and that of Leif Johannson. > Then there is also the single-sign-on issue, but thats more of an > implementation thing than protocol. Digest fits just as fine in > single-sign-on models as the NTLM or Negotiate schemes widely deployed > for the purpose today, but due to it being a different authentication > mechanism than used for the desktop it's not used in that context. > I disagree with you on this as well, but then the term "single sign-on" is so overloaded we really can't argue the point without debating the term first. So I'll define it as only requiring one password to do whatever it is I want to do (what the DIX/WAE BoFs called "Eliot's Dad's Problem"). But I also think there's no use in me whining about the lack of this stuff, and so I suppose it's time to shut up and either write a draft that actually attempts to address Sam's concerns or build some code to match some existing drafts, and then we can see how far off we are. Eliot From discuss-bounces@apps.ietf.org Fri Jun 08 14:43:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwjQX-0000DS-Dx; Fri, 08 Jun 2007 14:43:13 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HwjQV-0000CP-PD for discuss-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 14:43:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwjQV-0000AP-EN for discuss@apps.ietf.org; Fri, 08 Jun 2007 14:43:11 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwjQH-00077b-Rz for discuss@apps.ietf.org; Fri, 08 Jun 2007 14:43:11 -0400 Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l58IgvGW017674 for ; Fri, 8 Jun 2007 18:42:57 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JJB00001XZ8XT00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for discuss@apps.ietf.org; Fri, 08 Jun 2007 12:42:57 -0600 (MDT) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JJB00KFLYNIM520@mail-amer.sun.com>; Fri, 08 Jun 2007 12:42:56 -0600 (MDT) Date: Fri, 08 Jun 2007 11:42:54 -0700 From: Chris Newman Subject: Re: Straw-man charter for http-bis In-reply-to: To: Paul Hoffman , "ietf-http-wg@w3.org Group" , Apps Discuss Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@[10.1.110.5]> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Paul Hoffman wrote on 6/7/07 8:44 -0700: >> Beyond that I consider it inappropriate to hold publication of a >> useful revision hostage to new security engineering work. That >> opinion may not be shared by others on the IESG. > > Knowing ahead of time whether or not the work of this proposed WG is likely > to get smacked down at the end by the IESG would greatly affect the people > working on HTTPbis. Agreed. The mechanism to get the knowledge in advance is to be specific in the charter about what will and what won't be done. - Chris From discuss-bounces@apps.ietf.org Fri Jun 08 15:00:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwjhO-0001eM-PL; Fri, 08 Jun 2007 15:00:38 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HwjhN-0001eH-Cu for discuss-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 15:00:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwjhN-0001e9-3O for discuss@apps.ietf.org; Fri, 08 Jun 2007 15:00:37 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwjhL-0006AL-FS for discuss@apps.ietf.org; Fri, 08 Jun 2007 15:00:37 -0400 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l58J0YV4004520 for ; Fri, 8 Jun 2007 19:00:34 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JJB00901ZC8T900@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for discuss@apps.ietf.org; Fri, 08 Jun 2007 13:00:34 -0600 (MDT) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JJB00ISUZGQUF30@mail-amer.sun.com>; Fri, 08 Jun 2007 13:00:29 -0600 (MDT) Date: Fri, 08 Jun 2007 12:00:26 -0700 From: Chris Newman Subject: Re: RFC2616 vs RFC2617, was: Straw-man charter for http-bis In-reply-to: <46682BC9.9050504@gmx.de> To: Julian Reschke , Paul Hoffman Message-id: <8A1C369985037B2AED5F566D@[10.1.110.5]> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@[10.1.110.5]> <46682BC9.9050504@gmx.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Apps Discuss , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Julian Reschke wrote on 6/7/07 18:01 +0200: > maybe things become clearer if we consider re-organizing the security stuff? > > Currently, > > - RFC2616 refers (normatively?) to RFC2617 for authentication, and > > - RFC2617 defines a framework (Section 1.2) and two schemes (Basic and > Digest). > > Assuming that there's no immediate need to change the framework defines in > RCF2617, Section 1.2, wouldn't it make sense to: > > - Move the authentication framework itself into RFC2616bis, and > > - to then publish stand-alone documents upgrading/fixing both Basic and > Digest? > > The benefits being: > > - RFC2616bis doesn't have the dependency on its sister spec anymore, which > suffers from Basic and Digest problems, and > > - Basic, Digest and new schemes could evolve independently. Sounds like an idea worth considering to me. In past cases where Apps has bundled authentication mechanisms with general frameworks (e.g. RFC 1731, 2595), the mechanisms have invariably been split away from the framework for one reason or another. - Chris From discuss-bounces@apps.ietf.org Fri Jun 08 18:34:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwn2G-0000qZ-75; Fri, 08 Jun 2007 18:34:24 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hwn2F-0000qU-KP for discuss-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 18:34:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwn2F-0000qM-Af for discuss@apps.ietf.org; Fri, 08 Jun 2007 18:34:23 -0400 Received: from av8-2-sn3.vrr.skanova.net ([81.228.9.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwn2E-0008BR-Rg for discuss@apps.ietf.org; Fri, 08 Jun 2007 18:34:23 -0400 Received: by av8-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 5C07938394; Sat, 9 Jun 2007 00:34:21 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av8-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 441F937F58; Sat, 9 Jun 2007 00:34:21 +0200 (CEST) Received: from henriknordstrom.net (81-233-163-21-no84.tbcn.telia.com [81.233.163.21]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 1FC7837E42; Sat, 9 Jun 2007 00:34:20 +0200 (CEST) Received: from [192.168.1.2] (henriknordstrom.net [192.168.1.2]) by henriknordstrom.net (8.12.11.20060308/8.12.8) with ESMTP id l58MYJRA005378; Sat, 9 Jun 2007 00:34:19 +0200 Subject: Re: Straw-man charter for http-bis From: Henrik Nordstrom To: Eliot Lear In-Reply-To: <46696B98.1090201@cisco.com> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@[10.1.110.5]> <1181250794.24162.109.camel@henriknordstrom.net> <46696B98.1090201@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-zclv1k3po3i02kgYTBKc" Date: Sat, 09 Jun 2007 00:34:19 +0200 Message-Id: <1181342059.4818.63.camel@henriknordstrom.net> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on henriknordstrom.net X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: Apps Discuss , Mark Nottingham , Chris Newman , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --=-zclv1k3po3i02kgYTBKc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable fre 2007-06-08 klockan 15:45 +0100 skrev Eliot Lear: > I disagree in the strongest possible terms. This *is* a problem we can=20 > solve technically. It's just that no one has the will to do it and=20 > we've organized ourselves so that the work cannot be done in one place. =20 > If you had a component that was separate from your workstation, that had=20 > but a single function =E2=80=93 authentication =E2=80=93 we could write a= ppropriate APIs=20 > and protocols to access that device such that you would never log in=20 > without using it. Note: My comment was regarding seeing stronger authentication in HTTP as a method to solve phishing. It is not. Stronger authentication in HTTP is means to secure the wire protocol for exchanging user credentials, nothing else. Regarding stronger authentication in general. Sure, and I fully agree. And what you say is already supported by using smartcards and TLS for authentication, and is used by quite many today. Here in Sweden I can get identity cards with a embedded trusted certificate, and use this to identify myself to the tax authorities, social services etc. (not yet to the banks who issue these certificates, but that's a completely different discussion in administrative policies and not wire protocols..) But if you read the current discussions regarding phishing it's claimed that having a hard token requirement is not acceptable and that the solution must work with just a login+password. What I am saing is just the simple fact that designing a protocol to prevent phishing of static secrets of any kind is rather fruitless as the phishing problem as such is really mainly is an UA and education problem, not so much a wire protocol problem. As long as the user is capable of giving out the information and don't need to think twice in doing so phishing will continue, no matter how strong wire protocols is designed for exchanging these user known secrets with trusted parties. > The riskiest functions would be registration. In=20 > that single area would I view this an education problem, but even there,=20 > if we came up with a standard way to legitimately register individuals=20 > we could probably make that problem much more solvable. And we already have that in TLS, with appointed trusted CAs and where each service provider selects what level of trust he appoints the different CAs in verifying the user identities. > I disagree with you on this as well, but then the term "single sign-on"=20 > is so overloaded we really can't argue the point without debating the=20 > term first. So I'll define it as only requiring one password to do=20 > whatever it is I want to do (what the DIX/WAE BoFs called "Eliot's Dad's=20 > Problem"). In what way do not Digest fit that? (putting aside the security concerns regarding Digest use of MD5 and how) What is missing for Digest is some standard means for esablishing the password without exchaning the password, but it's possible to do such exchange, at least to a reasonable level. > But I also think there's no use in me whining about the lack of this=20 > stuff, and so I suppose it's time to shut up and either write a draft=20 > that actually attempts to address Sam's concerns or build some code to=20 > match some existing drafts, and then we can see how far off we are. It's fully possible to come up with an replacement for Digest solving the wire concerns. The relevance to RFC2616 in such work is the need for some standard way of establishing the password in a secure manner. The rest is relevant to RFC2617 only. Regards Henrik --=-zclv1k3po3i02kgYTBKc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad meddelandedel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iQCVAwUARmnZaENPQ5Kbx8daAQI8rAQApUakzSM1c4oW0h3f6crT2wiisVpp+aqv 7O8IAl/RGNUC0Fy1BpZ8Ac8GeibSSpiuGFHnxCBWGUbI2U1R2TwNHzpukANKAkdg iw0J0DC18FkyiTNkxHV4QV8TVxFea864k1H92cCXWOWfgh2zeuu+M4Hx/lgEVswP Ex7uyWw5XQI= =n7a4 -----END PGP SIGNATURE----- --=-zclv1k3po3i02kgYTBKc-- From discuss-bounces@apps.ietf.org Fri Jun 08 21:43:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwpyd-0002fB-CJ; Fri, 08 Jun 2007 21:42:51 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hwpyb-0002eu-Rj for discuss-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 21:42:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwpya-0002bA-Dy for discuss@apps.ietf.org; Fri, 08 Jun 2007 21:42:48 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwpyZ-0006MK-SH for discuss@apps.ietf.org; Fri, 08 Jun 2007 21:42:48 -0400 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B69811421FB; Fri, 8 Jun 2007 18:42:44 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ju2hn5kcnTdu; Fri, 8 Jun 2007 18:42:43 -0700 (PDT) Received: from [192.168.1.100] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id A609B1421F9; Fri, 8 Jun 2007 18:42:42 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <346FBD64-C192-45AF-8F31-FB36D3F123FD@osafoundation.org> Content-Type: multipart/alternative; boundary=Apple-Mail-41--964785112 To: Apps Discuss , Lisa Dusseault's Chairs Subject: Lisa's Apps Area Activity for May (and Jan, Feb, Mar, Apr) From: Lisa Dusseault Date: Fri, 8 Jun 2007 18:42:41 -0700 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-41--964785112 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed BOFs meeting in Chicago HTTPBIS: Tentatively Tuesday, July 24 charter discussion: http://lists.w3.org/Archives/Public/ietf-http- wg/2007AprJun/thread.html VCARDDAV (Chris Newman is advising AD) BIFF aka Mail Store Notifications (Chris Newman is advising AD) Document Status and Progress Active Documents: my action - draft-ietf-lemonade-rfc2192bis-07 (IMAP URL): AD Evaluation -- AD review before IETF Last Call - draft-crispin-collation-unicasemap-04: in IETF Last Call - draft-ietf-sieve-body: In IETF Last Call - draft-hartman-webauth-phishing (Informational): in IETF Last Call - draft-atompub-protocol-15: IESG Evaluation -- dealing with DISCUSS issues mostly in security considerations - draft-kunze-rfc2413bis-07: IESG Evaluation -- dealing with one DISCUSS question on ANSI relationship - draft-nottingham-atompub-feed-history-10: -- dealing with 2 DISCUSS issues, one on security considerations and one on paging information - draft-montemurro-gsma-imei-urn-01-- deal with 4 DISCUSS including major issues Stalled Documents - draft-ietf-imapext-sort-18: waiting for unicasemap to finish - draft-daboo-imapext-annotate: stuck in RFC Editor queue waiting on imapext-sort! - draft-ietf-usefor-usefor: stuck in RFC Ed queue waiting on usepro from WG - draft-crocker-rfc4234bis-00: IESG Evaluation -- Revised ID needed with resolution from LWSP issue - draft-ietf-widex-requirements-04 -- waiting for authors to provide or approve changes to resolve IESG Evaluation issues. Recent RFCs/ added to RFC Queue (not stalled) - RFC4770: vCard Extensions for Instant Messaging (IM) - RFC4790: Internet Application Protocol Collation Registry, Standards Track - draft-siemborski-rfc1734bis-11: POP3 SASL Authentication Mechanism - draft-siemborski-rfc2554bis-09: SMTP Service Extension for Authentication - draft-snell-atompub-feed-license-11: Atom License Extension WG Quick Status AtomPub: last document is almost done Calsify: steady progress on 2445bis IMAPExt: No activity -- need to finish sort and i18n documents!! SIEVE: finished work on 3028, sieve-body extension, working on freed- sieve-date-index Usefor: Steady progress on "usepro" (protocol) document WIDEX: stalled -- no response on last actions with requirements document --Apple-Mail-41--964785112 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
BOFs meeting in = Chicago

HTTPBIS: Tentatively = Tuesday, July 24
VCARDDAV (Chris Newman is advising = AD)
BIFF aka Mail Store Notifications (Chris Newman is = advising AD)

Document Status and = Progress

Active Documents: my = action=A0
=A0- draft-ietf-lemonade-rfc2192bis-07 (IMAP = URL):=A0AD Evaluation -- AD review before IETF Last Call
=A0- = draft-crispin-collation-unicasemap-04: in IETF Last = Call
=A0-=A0draft-ietf-sieve-body: In IETF Last = Call
=A0- draft-hartman-webauth-phishing (Informational): in = IETF Last Call
=A0- draft-atompub-protocol-15: IESG Evaluation = -- dealing with DISCUSS issues mostly in security = considerations
=A0- draft-kunze-rfc2413bis-07: IESG Evaluation = -- dealing with one DISCUSS question on ANSI = relationship
=A0-=A0draft-nottingham-atompub-feed-history-10: = -- dealing with 2 DISCUSS issues, one on security considerations and one = on paging information
=A0-=A0draft-montemurro-gsma-imei-urn-01--= deal with 4 DISCUSS including major issues

Stalled = Documents
=A0- draft-ietf-imapext-sort-18: waiting for = unicasemap to finish
=A0- draft-daboo-imapext-annotate: stuck = in RFC Editor queue waiting on imapext-sort!
=A0- = draft-ietf-usefor-usefor: stuck in RFC Ed queue waiting on usepro from = WG
=A0- draft-crocker-rfc4234bis-00: IESG Evaluation -- = Revised ID needed with resolution from LWSP = issue
=A0-=A0draft-ietf-widex-requirements-04 -- waiting for = authors to provide or approve changes to resolve IESG Evaluation = issues.

Recent RFCs/ added to = RFC Queue (not stalled)
=A0- RFC4770:=A0vCard Extensions = for Instant Messaging (IM)
=A0- = RFC4790:=A0Internet Application Protocol Collation Registry, Standards = Track
=A0-=A0draft-siemborski-rfc1734bis-11:=A0POP3 SASL = Authentication = Mechanism
=A0-=A0draft-siemborski-rfc2554bis-09:=A0SMTP = Service Extension for = Authentication
=A0-=A0draft-snell-atompub-feed-license-11:=A0Ato= m License Extension

WG Quick = Status
AtomPub: last document is almost = done
Calsify: steady progress on 2445bis
IMAPExt:=A0 = No activity -- need to finish sort and i18n documents!!
SIEVE: = finished work on 3028, sieve-body extension, working on = freed-sieve-date-index
Usefor: Steady progress on "usepro" = (protocol) document
WIDEX: stalled -- no response on last = actions with requirements document


= --Apple-Mail-41--964785112-- From discuss-bounces@apps.ietf.org Sun Jun 10 17:10:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxUg0-0000vX-HW; Sun, 10 Jun 2007 17:10:20 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HxUg0-0000vS-0s for discuss-confirm+ok@megatron.ietf.org; Sun, 10 Jun 2007 17:10:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxUfz-0000vK-Mv for discuss@apps.ietf.org; Sun, 10 Jun 2007 17:10:19 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxUfx-0003iZ-W5 for discuss@apps.ietf.org; Sun, 10 Jun 2007 17:10:19 -0400 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 767A7142204; Sun, 10 Jun 2007 14:10:17 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrXEDI38OveR; Sun, 10 Jun 2007 14:10:15 -0700 (PDT) Received: from [192.168.1.100] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 4E497142202; Sun, 10 Jun 2007 14:10:14 -0700 (PDT) In-Reply-To: <1181342059.4818.63.camel@henriknordstrom.net> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@[10.1.110.5]> <1181250794.24162.109.camel@henriknordstrom.net> <46696B98.1090201@cisco.com> <1181342059.4818.63.camel@henriknordstrom.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/alternative; boundary=Apple-Mail-43--808334052 Message-Id: <8DD2BD5A-9068-43C3-973E-382FAD2E0EA8@osafoundation.org> From: Lisa Dusseault Subject: Re: Straw-man charter for http-bis Date: Sun, 10 Jun 2007 14:10:12 -0700 To: Henrik Nordstrom X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: Apps Discuss , Mark Nottingham , Chris Newman , "ietf-http-wg@w3.org Group" , Eliot Lear X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-43--808334052 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Jun 8, 2007, at 3:34 PM, Henrik Nordstrom wrote: > In what way do not Digest fit that? (putting aside the security > concerns > regarding Digest use of MD5 and how) > > What is missing for Digest is some standard means for esablishing the > password without exchaning the password, but it's possible to do such > exchange, at least to a reasonable level. Digest has a bad reputation particularly among Web App developers for a number of reasons, some inherent to the design and specification, some stemming from implementation and deployment choices. http://www.xml.com/pub/a/2003/12/17/dive.html: "most web hosting providers don't turn on digest authentication (it requires an Apache module that is not on by default). Even if Bob's ISP had mod_digest_auth enabled, it wouldn't help Bob, because he has no .htaccess rights to configure his passwords; and, because of the way Apache works, CGIs can't implement digest authentication on their own. (Scripts handled by an Apache module, such as mod_php or mod_perl, can implement HTTP digest authentication. But external CGI processes can't because Apache does not pass the necessary headers along to the CGI script. But that still doesn't help Bob because his hosting provider doesn't offer PHP; and, even if they did, his weblog software doesn't run on PHP anyway.)" http://blogs.msdn.com/drnick/archive/2006/05/12/understanding-http- authentication.aspx: "Digest authentication requires the use of Windows domain accounts. The digest realm indicates the Windows domain name. Due to this, a server running on an operating system that does not support Windows domains, such as Windows XP Home, cannot be used with Digest authentication. When the client is running on an operating system that does not support Windows domains, a domain account must be explicitly specified during the authentication." http://www.imc.org/atom-syntax/mail-archive/msg06103.html: " (1) Some web-servers remove the WWW-Authenticate header before passing it to a CGI program." http://www.imc.org/atom-protocol/mail-archive/msg00836.html: "do all digest and WSSE implementations require server-side access to clear-text passwords or is that just a weakness of the implementations I looked at?" http://www.imc.org/atom-syntax/mail-archive/msg00139.html: "I'm a small site, security is very much a concern and my host does not provide Digest and won't do so." Thus it's hard for an administrator to use today's Web server software and Digest authentication, and still have an application- specific database of usernames/passwords. The server software gets in the way -- it may even be easier for the Web App developer to implement something non-standard like WSSE than have to rely on built- in functions. i18n is also a problem: http://www.agileprogrammer.com/eightytwenty/ archive/2006/05/04/14280.aspx And for humour on the situation: http://bitworking.org/news/ Problems_with_HTTP_Authentication_Interop Lisa --Apple-Mail-43--808334052 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Jun 8, 2007, at = 3:34 PM, Henrik Nordstrom wrote:

In what way do not Digest = fit that? (putting aside the security concerns

regarding Digest use of MD5 = and how)


What is missing for Digest is some standard means for = esablishing the

password without exchaning the password, but it's possible to = do such

exchange, = at least to a reasonable level.

=

Digest has a bad reputation particularly = among Web App developers for a number of reasons, some inherent to the = design and specification, some stemming from implementation and = deployment choices.

http://www.xml.com/= pub/a/2003/12/17/dive.html:=A0 "most web hosting providers don't = turn on digest authentication (it requires an Apache module that is not = on by default). Even if Bob's ISP had mod_digest_auth enabled, it = wouldn't help Bob, because he has no .htaccess rights to configure his = passwords; and, because of the way Apache works, CGIs can't implement = digest authentication on their own. (Scripts handled by an Apache = module, such as mod_php or mod_perl, can implement HTTP digest = authentication. But external CGI processes can't because Apache does not = pass the necessary headers along to the CGI script. But that still = doesn't help Bob because his hosting provider doesn't offer PHP; and, = even if they did, his weblog software doesn't run on PHP = anyway.)"

http://blogs.msdn.com/drnick/archive/2006/05/12/unde= rstanding-http-authentication.aspx:=A0"Digest authentication = requires the use of Windows domain accounts.=A0 The digest realm = indicates the Windows domain name.=A0 Due to this, a server running on = an operating system that does not support Windows domains, such as = Windows XP Home, cannot be used with Digest authentication.=A0 When the = client is running on an operating system that does not support Windows = domains, a domain account must be explicitly specified during the = authentication."

http://= www.imc.org/atom-syntax/mail-archive/msg06103.html: "=A0(1) Some = web-servers remove the WWW-Authenticate header before passing it to a = CGI program."

http:= //www.imc.org/atom-protocol/mail-archive/msg00836.html: "do all = digest and WSSE implementations require server-side access to
clear-text passwords or is that just a weakness of = the implementations I looked at?"

http://= www.imc.org/atom-syntax/mail-archive/msg00139.html:=A0=A0"I'm a = small site, security is very much a concern and my host does not provide = Digest and won't do so."=A0

Thus it's hard for an = administrator to use today's Web server software and Digest = authentication, and still have an application-specific database of = usernames/passwords.=A0 The server software gets in the way -- it may = even be easier for the Web App developer to implement something = non-standard like WSSE than have to rely on built-in = functions.



= --Apple-Mail-43--808334052-- From discuss-bounces@apps.ietf.org Sun Jun 10 19:40:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxX16-0001WG-PP; Sun, 10 Jun 2007 19:40:16 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HxX14-0001WA-SD for discuss-confirm+ok@megatron.ietf.org; Sun, 10 Jun 2007 19:40:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxX14-0001W2-IZ for discuss@apps.ietf.org; Sun, 10 Jun 2007 19:40:14 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxX12-0004pS-Oh for discuss@apps.ietf.org; Sun, 10 Jun 2007 19:40:14 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l5ANe56K027128 for ; Mon, 11 Jun 2007 08:40:05 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 261a_ea826e2e_17ab_11dc_95f4_0014221fa3c9; Mon, 11 Jun 2007 08:40:05 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:53723) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 11 Jun 2007 08:38:15 +0900 Message-Id: <6.0.0.20.2.20070610165356.0a69cec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 10 Jun 2007 17:05:44 +0900 To: Julian Reschke , Paul Hoffman From: Martin Duerst Subject: Re: Straw-man charter for http-bis In-Reply-To: <465D9142.9050506@gmx.de> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Apps Discuss , Mark Nottingham , Felix Sasaki , "ietf-http-wg@w3.org Group" , Richard Ishida X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org At 23:59 07/05/30, Julian Reschke wrote: >Paul Hoffman wrote: >> Serious question, not a gratuitous opening of a big can-o-worms: would the WG also consider extensions to HTTP that would go into different documents? That is, is the WG only for the revision of the base spec, or also open to ( animated && lengthy && contentious ) discussion of other documents as well? > >I guess the idea was that the more we restrict the scope of what we want to do, the easier it'll be to gather the right group of people to do it. > >For instance, RFC2617 needs a revision badly as well (for instance, wrt to I18N of usernames and passwords, and, as far as I can recall, certain problems with the definition of Digest Auth). IMHO; this should occur in a separate working group. There are some i18n-related fixes needed in RFC 2616 as well. The two main ones I know of are: - RFC 2616 prescribes that headers containing non-ASCII have to use either iso-8859-1 or RFC 2047. This is unnecessarily complex and not necessarily followed. At the least, new extensions should be allowed to specify that UTF-8 is used. - RFC 2616 prescribes a default of iso-8859-1 for the 'charset' parameter for text/* mime types. At least in two very important cases, this is not followed: For text/html, there is no default, or put in other words, the default is whatever your browser is set to. For text/xml and related types, the default is US-ASCII. At a miminum, the spec should make sure the implementers get an idea of this, rather than having to find out the hard way. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From discuss-bounces@apps.ietf.org Sun Jun 10 23:23:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxaVV-0006WQ-4A; Sun, 10 Jun 2007 23:23:53 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HxaVU-0006WL-4G for discuss-confirm+ok@megatron.ietf.org; Sun, 10 Jun 2007 23:23:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxaVT-0006WD-R0 for discuss@apps.ietf.org; Sun, 10 Jun 2007 23:23:51 -0400 Received: from av7-2-sn3.vrr.skanova.net ([81.228.9.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxaVS-0003EA-9H for discuss@apps.ietf.org; Sun, 10 Jun 2007 23:23:51 -0400 Received: by av7-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 4C41338145; Mon, 11 Jun 2007 05:23:01 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av7-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 3087637F9B; Mon, 11 Jun 2007 05:23:01 +0200 (CEST) Received: from henriknordstrom.net (81-233-163-21-no84.tbcn.telia.com [81.233.163.21]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 73FA037E43; Mon, 11 Jun 2007 05:23:46 +0200 (CEST) Received: from [192.168.1.2] (henriknordstrom.net [192.168.1.2]) by henriknordstrom.net (8.12.11.20060308/8.12.8) with ESMTP id l5B3NiHq006821; Mon, 11 Jun 2007 05:23:44 +0200 Subject: Re: Straw-man charter for http-bis From: Henrik Nordstrom To: Lisa Dusseault In-Reply-To: <8DD2BD5A-9068-43C3-973E-382FAD2E0EA8@osafoundation.org> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@[10.1.110.5]> <1181250794.24162.109.camel@henriknordstrom.net> <46696B98.1090201@cisco.com> <1181342059.4818.63.camel@henriknordstrom.net> <8DD2BD5A-9068-43C3-973E-382FAD2E0EA8@osafoundation.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-3bVeNkNhMDqXW/snEWE2" Date: Mon, 11 Jun 2007 05:23:44 +0200 Message-Id: <1181532224.3389.47.camel@henriknordstrom.net> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on henriknordstrom.net X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: Apps Discuss , Mark Nottingham , Chris Newman , "ietf-http-wg@w3.org Group" , Eliot Lear X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --=-3bVeNkNhMDqXW/snEWE2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable s=C3=B6n 2007-06-10 klockan 14:10 -0700 skrev Lisa Dusseault: > Digest has a bad reputation particularly among Web App developers for > a number of reasons, some inherent to the design and specification, > some stemming from implementation and deployment choices. Nearly all is implementation. > http://www.xml.com/pub/a/2003/12/17/dive.html: "most web hosting > providers don't turn on digest authentication (it requires an Apache > module that is not on by default). Even if Bob's ISP had Implementation. > http://blogs.msdn.com/drnick/archive/2006/05/12/understanding-http-authen= tication.aspx: "Digest authentication requires the use of Windows domain ac= counts. Plain untrue, unless you restrict your view of Digest to the Microsoft IIS implementation in which case it's implementation. > http://www.imc.org/atom-syntax/mail-archive/msg06103.html: " (1) Some > web-servers remove the WWW-Authenticate header before passing it to a > CGI program." Implementation. Well, CGI is not the proper interface to implement authentication schemes, but it's implementation in the sense that web servers is a bit poor in allowing applications to set the authentication requirements in a sensible manner. But it is fully doable with only a little effort. > http://www.imc.org/atom-protocol/mail-archive/msg00836.html: "do all > digest and WSSE implementations require server-side access to > clear-text passwords or is that just a weakness of the implementations > I looked at?" No, the realm specific H(A1) is required. > http://www.imc.org/atom-syntax/mail-archive/msg00139.html: "I'm a > small site, security is very much a concern and my host does not > provide Digest and won't do so."=20 Implementation. > Thus it's hard for an administrator to use today's Web server software > and Digest authentication, and still have an application-specific > database of usernames/passwords. The server software gets in the way > -- it may even be easier for the Web App developer to implement > something non-standard like WSSE than have to rely on built-in > functions. Thats all implementation. Web servers don't make it easy for applications to use/control HTTP authentication. So applications don't use it. CGI is not the proper interface for HTTP authentication. It's the web servers responsibility to handle the fine details of HTTP (including authentication) and the CGIs responsibility to provide content & applications. > i18n is also a problem: > http://www.agileprogrammer.com/eightytwenty/archive/2006/05/04/14280.aspx Yes, this is a specifications problem inherent to both Basic and Digest, > And for humour on the situation: > http://bitworking.org/news/Problems_with_HTTP_Authentication_Interop Yes, there is lots of broken Digest implementations around either not reading the specs, not caring to implement anything but the absolute minimum required for a conditionally compliant implementation, not testing their implementation, or sticking to old specs considered obsolete and broken. And pressure from users that things must work even with the broken implementations as the users consider the broken browser implementations unfixable. Don't know how many times I have asked users to file a bug report with vendor X and always receive the same answer "no, it's of no use. we must work around the bug somehow". Regards Henrik --=-3bVeNkNhMDqXW/snEWE2 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad meddelandedel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iQCVAwUARmzAMENPQ5Kbx8daAQLz1gP/fTpaUgqAI538E3UYGFGd5CYHU6fMMAc3 na6LUT9lWqpwUhHZbfjP7OWyDGLVMDHMSRevxDi6dorxAePYnm0SFNOx/NCs/Qml 0Zp9T8fQbhbKP8O4F+BCznNyjewQwdVSW5ibg6VYXyaJO5EksbLvdCF2SbWTwHD/ 8bhwH26g+bk= =ajQ3 -----END PGP SIGNATURE----- --=-3bVeNkNhMDqXW/snEWE2-- From discuss-bounces@apps.ietf.org Sun Jun 10 23:34:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxafL-0000sJ-1O; Sun, 10 Jun 2007 23:34:03 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HxafJ-0000sD-Vo for discuss-confirm+ok@megatron.ietf.org; Sun, 10 Jun 2007 23:34:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxafJ-0000s5-Lx for discuss@apps.ietf.org; Sun, 10 Jun 2007 23:34:01 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxafI-0000lh-Fs for discuss@apps.ietf.org; Sun, 10 Jun 2007 23:34:01 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id D82CD1EE1C4; Sun, 10 Jun 2007 23:33:56 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccmdxNnNHhb5; Sun, 10 Jun 2007 23:33:38 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 0CD801EE1FE; Sun, 10 Jun 2007 23:33:17 -0400 (EDT) Message-ID: <466CC26F.90603@cs.utk.edu> Date: Sun, 10 Jun 2007 23:33:03 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Henrik Nordstrom Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@[10.1.110.5]> <1181250794.24162.109.camel@henriknordstrom.net> <46696B98.1090201@cisco.com> <1181342059.4818.63.camel@henriknordstrom.net> <8DD2BD5A-9068-43C3-973E-382FAD2E0EA8@osafoundation.org> <1181532224.3389.47.camel@henriknordstrom.net> In-Reply-To: <1181532224.3389.47.camel@henriknordstrom.net> X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Eliot Lear , Apps Discuss , Mark Nottingham , "ietf-http-wg@w3.org Group" , Chris Newman X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >> Digest has a bad reputation particularly among Web App developers for >> a number of reasons, some inherent to the design and specification, >> some stemming from implementation and deployment choices. >> > > Nearly all is implementation. > ah, but what's the reason for all of those implementation-imposed constraints? Keith From discuss-bounces@apps.ietf.org Sun Jun 10 23:57:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxb1i-0000Oo-RN; Sun, 10 Jun 2007 23:57:10 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hxb1h-0000Oj-HI for discuss-confirm+ok@megatron.ietf.org; Sun, 10 Jun 2007 23:57:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxb1h-0000Ob-2s for discuss@apps.ietf.org; Sun, 10 Jun 2007 23:57:09 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hxb1f-0008UR-Mf for discuss@apps.ietf.org; Sun, 10 Jun 2007 23:57:09 -0400 Received: (qmail invoked by alias); 11 Jun 2007 03:57:06 -0000 Received: from p508F9FDE.dip0.t-ipconnect.de (EHLO [192.168.178.22]) [80.143.159.222] by mail.gmx.net (mp044) with SMTP; 11 Jun 2007 05:57:06 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+k4SgTmdSkBTonVHkUWGT3o6RmFK9d5mT9JRit9T jCW80KC4s35/ki Message-ID: <466CC806.7020500@gmx.de> Date: Mon, 11 Jun 2007 05:56:54 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Martin Duerst Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <465D9142.9050506@gmx.de> <6.0.0.20.2.20070610165356.0a69cec0@localhost> In-Reply-To: <6.0.0.20.2.20070610165356.0a69cec0@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Felix Sasaki , Richard Ishida , Apps Discuss , Mark Nottingham , "ietf-http-wg@w3.org Group" , Paul Hoffman X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Martin Duerst wrote: > At 23:59 07/05/30, Julian Reschke wrote: >> Paul Hoffman wrote: >>> Serious question, not a gratuitous opening of a big can-o-worms: would the WG also consider extensions to HTTP that would go into different documents? That is, is the WG only for the revision of the base spec, or also open to ( animated && lengthy && contentious ) discussion of other documents as well? >> I guess the idea was that the more we restrict the scope of what we want to do, the easier it'll be to gather the right group of people to do it. >> >> For instance, RFC2617 needs a revision badly as well (for instance, wrt to I18N of usernames and passwords, and, as far as I can recall, certain problems with the definition of Digest Auth). IMHO; this should occur in a separate working group. > > There are some i18n-related fixes needed in RFC 2616 as well. > > The two main ones I know of are: > > - RFC 2616 prescribes that headers containing non-ASCII have to use > either iso-8859-1 or RFC 2047. This is unnecessarily complex and > not necessarily followed. At the least, new extensions should be > allowed to specify that UTF-8 is used. We have talked about this, but it's currently not on the issues list. I think it should be. > - RFC 2616 prescribes a default of iso-8859-1 for the 'charset' > parameter for text/* mime types. At least in two very important > cases, this is not followed: For text/html, there is no default, > or put in other words, the default is whatever your browser is > set to. For text/xml and related types, the default is US-ASCII. > At a miminum, the spec should make sure the implementers get > an idea of this, rather than having to find out the hard way. Agreed. That issue is . Best regards, Julian From discuss-bounces@apps.ietf.org Tue Jun 12 07:31:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy4aa-0000rM-T1; Tue, 12 Jun 2007 07:31:08 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hy4aY-0000fW-Mz for discuss-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 07:31:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy4aY-0000dg-Ce for discuss@apps.ietf.org; Tue, 12 Jun 2007 07:31:06 -0400 Received: from mxout-03.mxes.net ([216.86.168.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy4aW-0005e8-4J for discuss@apps.ietf.org; Tue, 12 Jun 2007 07:31:06 -0400 Received: from [127.0.0.1] (unknown [216.145.54.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id AD5305193C; Tue, 12 Jun 2007 07:31:01 -0400 (EDT) In-Reply-To: <20070608081032.GA12039@nic.fr> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@[10.1.110.5]> <46682BC9.9050504@gmx.de> <46682E06.7030603@cs.utk.edu> <46682FC5.5030204@gmx.de> <20070608081032.GA12039@nic.fr> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8FEE5444-50F1-4575-9AA3-626C2A03474C@mnot.net> Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: RFC2616 vs RFC2617, was: Straw-man charter for http-bis Date: Tue, 12 Jun 2007 21:30:57 +1000 To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Apps Discuss , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On 08/06/2007, at 6:10 PM, Stephane Bortzmeyer wrote: > > On Thu, Jun 07, 2007 at 06:18:13PM +0200, > Julian Reschke wrote > a message of 14 lines which said: > >> In the wild, most authentication isn't using RFC2617 anyway. > > Any data here? IMHO, this assertion is not true, unless you limit to > big e-commerce Web sites. For instance, HTTP-based Web services use > 2617. My experience is that it isn't adequate for even those purposes, in many cases. -- Mark Nottingham http://www.mnot.net/ From discuss-bounces@apps.ietf.org Tue Jun 12 07:56:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy4yv-0001YS-I4; Tue, 12 Jun 2007 07:56:17 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hy4yu-0001X7-9W for discuss-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 07:56:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy4yt-0001Wv-Vt for discuss@apps.ietf.org; Tue, 12 Jun 2007 07:56:16 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy4yr-0002YZ-Vu for discuss@apps.ietf.org; Tue, 12 Jun 2007 07:56:15 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id ECC141C0098; Tue, 12 Jun 2007 13:56:12 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id E6D971C0095; Tue, 12 Jun 2007 13:56:09 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id D82D458ECE0; Tue, 12 Jun 2007 13:56:09 +0200 (CEST) Date: Tue, 12 Jun 2007 13:56:09 +0200 From: Stephane Bortzmeyer To: Mark Nottingham Subject: Re: RFC2616 vs RFC2617, was: Straw-man charter for http-bis Message-ID: <20070612115609.GA12826@nic.fr> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@[10.1.110.5]> <46682BC9.9050504@gmx.de> <46682E06.7030603@cs.utk.edu> <46682FC5.5030204@gmx.de> <20070608081032.GA12039@nic.fr> <8FEE5444-50F1-4575-9AA3-626C2A03474C@mnot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8FEE5444-50F1-4575-9AA3-626C2A03474C@mnot.net> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Apps Discuss , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Tue, Jun 12, 2007 at 09:30:57PM +1000, Mark Nottingham wrote a message of 19 lines which said: > My experience is that it isn't adequate for even those purposes, in > many cases. More elaborate comments are welcome. Specially if we embark on a revision of 2617 :-) From discuss-bounces@apps.ietf.org Wed Jun 13 08:28:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyRxb-0004Do-39; Wed, 13 Jun 2007 08:28:27 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HyEj7-00014Q-HD for discuss-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 18:20:37 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HyEj7-00014I-7u for discuss@apps.ietf.org; Tue, 12 Jun 2007 18:20:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyEes-0000er-6U for discuss@apps.ietf.org; Tue, 12 Jun 2007 18:16:14 -0400 Received: from smtp.qbik.com ([210.55.214.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyEeq-0002sR-H6 for discuss@apps.ietf.org; Tue, 12 Jun 2007 18:16:14 -0400 Received: From spunky.qbik.com (unverified [192.168.0.3]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v6.2.1 (Build 1134)) with SMTP id <0009324820@smtp.qbik.com>; Wed, 13 Jun 2007 10:16:29 +1200 Received: From [192.168.0.33] (unverified [192.168.0.33]) by SMTP Server [192.168.0.3] (WinGate SMTP Receiver v) with SMTP id <0000537528@spunky.qbik.com>; Wed, 13 Jun 2007 10:16:27 +1200 Message-ID: <466F1B3B.3040409@qbik.com> Date: Wed, 13 Jun 2007 10:16:27 +1200 From: Adrien de Croy Organization: Qbik New Zealand Limited User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Mark Nottingham Subject: Re: RFC2616 vs RFC2617, was: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@[10.1.110.5]> <46682BC9.9050504@gmx.de> <46682E06.7030603@cs.utk.edu> <46682FC5.5030204@gmx.de> <20070608081032.GA12039@nic.fr> <8FEE5444-50F1-4575-9AA3-626C2A03474C@mnot.net> In-Reply-To: <8FEE5444-50F1-4575-9AA3-626C2A03474C@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-TMDA-Confirmed: Tue, 12 Jun 2007 18:20:37 -0400 X-Mailman-Approved-At: Wed, 13 Jun 2007 08:28:26 -0400 Cc: Apps Discuss , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org my experience also is that it is extremely rare to encounter public web servers that use any HTTP auth mechanism. NTLM and Basic auth is often used for intranets, and proxy access. I've never seen an instance of Digest auth. Seems to me that the issue of securing communications and authenticating or identifying parties are closely aligned, why not just have some form of auth built into TLS, then we could use it for any protocol that can use TLS, instead of having to implement separate auth schemes for every higher protocol. Mark Nottingham wrote: > > > On 08/06/2007, at 6:10 PM, Stephane Bortzmeyer wrote: > >> >> On Thu, Jun 07, 2007 at 06:18:13PM +0200, >> Julian Reschke wrote >> a message of 14 lines which said: >> >>> In the wild, most authentication isn't using RFC2617 anyway. >> >> Any data here? IMHO, this assertion is not true, unless you limit to >> big e-commerce Web sites. For instance, HTTP-based Web services use >> 2617. > > My experience is that it isn't adequate for even those purposes, in > many cases. > > -- > Mark Nottingham http://www.mnot.net/ > > From discuss-bounces@apps.ietf.org Thu Jun 14 03:50:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyk5k-0005Ei-TV; Thu, 14 Jun 2007 03:50:04 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hyk5k-0005Ed-7l for discuss-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 03:50:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyk5j-0005ES-3n for discuss@apps.ietf.org; Thu, 14 Jun 2007 03:50:03 -0400 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyk5h-0001Az-Df for discuss@apps.ietf.org; Thu, 14 Jun 2007 03:50:02 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id EBBD5240828; Thu, 14 Jun 2007 09:49:55 +0200 (CEST) Received: by fetiche (Postfix, from userid 1000) id 43F741818D; Thu, 14 Jun 2007 09:40:19 +0200 (CEST) Date: Thu, 14 Jun 2007 09:40:19 +0200 From: Stephane Bortzmeyer To: Adrien de Croy Subject: Re: RFC2616 vs RFC2617, was: Straw-man charter for http-bis Message-ID: <20070614074019.GA3013@laperouse.bortzmeyer.org> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@[10.1.110.5]> <46682BC9.9050504@gmx.de> <46682E06.7030603@cs.utk.edu> <46682FC5.5030204@gmx.de> <20070608081032.GA12039@nic.fr> <8FEE5444-50F1-4575-9AA3-626C2A03474C@mnot.net> <466F1B3B.3040409@qbik.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <466F1B3B.3040409@qbik.com> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Apps Discuss , "ietf-http-wg@w3.org Group" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Wed, Jun 13, 2007 at 10:16:27AM +1200, Adrien de Croy wrote a message of 38 lines which said: > my experience also is that it is extremely rare to encounter public > web servers that use any HTTP auth mechanism. We do not live in the same world, then. I worked today on a program (a del.icio.us link checker) which use it. Many Web APIs use this mechanism. Unless if, by "Web servers" , you mean only "Web servers for interactive human usage". From discuss-bounces@apps.ietf.org Thu Jun 14 07:01:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyn5I-00035F-Bq; Thu, 14 Jun 2007 07:01:48 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hyn5G-000355-P7 for discuss-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 07:01:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyn5G-00034x-Fh for discuss@apps.ietf.org; Thu, 14 Jun 2007 07:01:46 -0400 Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyn5F-0008PB-3W for discuss@apps.ietf.org; Thu, 14 Jun 2007 07:01:46 -0400 Received: from pc6 (1Cust10.tnt2.lnd4.gbr.da.uu.net [62.188.131.10]) by galaxy.systems.pipex.net (Postfix) with SMTP id CB93DE000B5B; Thu, 14 Jun 2007 12:01:37 +0100 (BST) Message-ID: <031901c7ae6a$68e12360$0601a8c0@pc6> From: "tom.petch" To: "Adrien de Croy" References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net><6AE049B9045C00064222693F@[10.1.110.5]><46682BC9.9050504@gmx.de> <46682E06.7030603@cs.utk.edu><46682FC5.5030204@gmx.de> <20070608081032.GA12039@nic.fr><8FEE5444-50F1-4575-9AA3-626C2A03474C@mnot.net> <466F1B3B.3040409@qbik.com> Subject: Re: RFC2616 vs RFC2617, was: Straw-man charter for http-bis Date: Thu, 14 Jun 2007 11:29:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Apps Discuss , ietf-http-wg@w3.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Tom Petch ----- Original Message ----- From: "Adrien de Croy" To: "Mark Nottingham" Cc: "Apps Discuss" ; Sent: Wednesday, June 13, 2007 12:16 AM Subject: Re: RFC2616 vs RFC2617, was: Straw-man charter for http-bis > > my experience also is that it is extremely rare to encounter public web > servers that use any HTTP auth mechanism. > > NTLM and Basic auth is often used for intranets, and proxy access. > > I've never seen an instance of Digest auth. > > Seems to me that the issue of securing communications and authenticating > or identifying parties are closely aligned, why not just have some form > of auth built into TLS, then we could use it for any protocol that can > use TLS, instead of having to implement separate auth schemes for every > higher protocol. > TLS can do that but it does not gel with the way in which (many) organisations are structured. Those responsible for security, for security credentials and their maintenance, do not want to be ferreting around in the depths of a network stack, they prefer working at application and database level, a point that has already been alluded to in this thread. The solution I like to this is channel bindings, as promoted by Nico Williams, where a weakly authenticated tunnel is set up and then stronger authentication - which can rely on the strong encryption which is now in place - is performed via it, eg at application level in the stack. > > Mark Nottingham wrote: > > > > On 08/06/2007, at 6:10 PM, Stephane Bortzmeyer wrote: > > > >> On Thu, Jun 07, 2007 at 06:18:13PM +0200, > >> Julian Reschke wrote > >> a message of 14 lines which said: > >> > >>> In the wild, most authentication isn't using RFC2617 anyway. > >> > >> Any data here? IMHO, this assertion is not true, unless you limit to > >> big e-commerce Web sites. For instance, HTTP-based Web services use > >> 2617. > > > > My experience is that it isn't adequate for even those purposes, in > > many cases. > > > > -- > > Mark Nottingham http://www.mnot.net/ From discuss-bounces@apps.ietf.org Thu Jun 14 07:14:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HynHz-00026S-N4; Thu, 14 Jun 2007 07:14:55 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HynHx-00026E-RF for discuss-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 07:14:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HynHv-00025t-Po for discuss@apps.ietf.org; Thu, 14 Jun 2007 07:14:53 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HynHu-0003I2-In for discuss@apps.ietf.org; Thu, 14 Jun 2007 07:14:51 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 751421EE192; Thu, 14 Jun 2007 07:14:49 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cv0YLJmNg1T4; Thu, 14 Jun 2007 07:13:51 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 7514F1EE152; Thu, 14 Jun 2007 07:13:42 -0400 (EDT) Message-ID: <467122CE.2090501@cs.utk.edu> Date: Thu, 14 Jun 2007 07:13:18 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: "tom.petch" Subject: Re: RFC2616 vs RFC2617, was: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net><6AE049B9045C00064222693F@[10.1.110.5]><46682BC9.9050504@gmx.de> <46682E06.7030603@cs.utk.edu><46682FC5.5030204@gmx.de> <20070608081032.GA12039@nic.fr><8FEE5444-50F1-4575-9AA3-626C2A03474C@mnot.net> <466F1B3B.3040409@qbik.com> <031901c7ae6a$68e12360$0601a8c0@pc6> In-Reply-To: <031901c7ae6a$68e12360$0601a8c0@pc6> X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Adrien de Croy , Apps Discuss , ietf-http-wg@w3.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >> >> Seems to me that the issue of securing communications and authenticating >> or identifying parties are closely aligned, why not just have some form >> of auth built into TLS, then we could use it for any protocol that can >> use TLS, instead of having to implement separate auth schemes for every >> higher protocol. >> >> > TLS can do that but it does not gel with the way in which (many) organisations > are structured. Those responsible for security, for security credentials and > their maintenance, do not want to be ferreting around in the depths of a network > stack, they prefer working at application and database level, a point that has > already been alluded to in this thread. how exactly does sending TLS credentials involve ferreting around in the depths of a network stack? From discuss-bounces@apps.ietf.org Thu Jun 14 14:09:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hytl6-00004x-V2; Thu, 14 Jun 2007 14:09:24 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hytl5-0008Ji-9t for discuss-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 14:09:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hytl4-0008Iz-Vd for discuss@apps.ietf.org; Thu, 14 Jun 2007 14:09:22 -0400 Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hytl3-0007xt-MR for discuss@apps.ietf.org; Thu, 14 Jun 2007 14:09:22 -0400 Received: from pc6 (1Cust107.tnt13.lnd4.gbr.da.uu.net [62.188.142.107]) by galaxy.systems.pipex.net (Postfix) with SMTP id BE812E000215; Thu, 14 Jun 2007 19:09:15 +0100 (BST) Message-ID: <017001c7aea6$254a9f00$0601a8c0@pc6> From: "tom.petch" To: "Keith Moore" References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net><6AE049B9045C00064222693F@[10.1.110.5]><46682BC9.9050504@gmx.de> <46682E06.7030603@cs.utk.edu><46682FC5.5030204@gmx.de> <20070608081032.GA12039@nic.fr><8FEE5444-50F1-4575-9AA3-626C2A03474C@mnot.net> <466F1B3B.3040409@qbik.com> <031901c7ae6a$68e12360$0601a8c0@pc6> <467122CE.2090501@cs.utk.edu> Subject: Re: RFC2616 vs RFC2617, was: Straw-man charter for http-bis Date: Thu, 14 Jun 2007 19:03:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Adrien de Croy , Apps Discuss , ietf-http-wg@w3.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org ----- Original Message ----- From: "Keith Moore" To: "tom.petch" Cc: "Adrien de Croy" ; "Apps Discuss" ; Sent: Thursday, June 14, 2007 1:13 PM Subject: Re: RFC2616 vs RFC2617, was: Straw-man charter for http-bis > >> > >> Seems to me that the issue of securing communications and authenticating > >> or identifying parties are closely aligned, why not just have some form > >> of auth built into TLS, then we could use it for any protocol that can > >> use TLS, instead of having to implement separate auth schemes for every > >> higher protocol. > >> > >> > > TLS can do that but it does not gel with the way in which (many) organisations > > are structured. Those responsible for security, for security credentials and > > their maintenance, do not want to be ferreting around in the depths of a network > > stack, they prefer working at application and database level, a point that has > > already been alluded to in this thread. > > how exactly does sending TLS credentials involve ferreting around in the > depths of a network stack? > It doesn't:-) Those responsible for the creation and maintenance of security credentials - which I see as the major ongoing work of security - prefer to do at an application level, using appropriate databases, which are somewhat removed from the lower layers in which TLS sits. So TLS has a different set of credentials or none, which is the problem that channel binding overcomes. Tom Petch From discuss-bounces@apps.ietf.org Thu Jun 14 16:42:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyw9Z-0000Mq-Qr; Thu, 14 Jun 2007 16:42:49 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hyw9X-0000Mg-RX for discuss-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 16:42:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyw9X-0000MY-Hz for discuss@apps.ietf.org; Thu, 14 Jun 2007 16:42:47 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyw9W-00061x-BG for discuss@apps.ietf.org; Thu, 14 Jun 2007 16:42:47 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 436751EE236; Thu, 14 Jun 2007 16:42:45 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fb4DTV1JCw+O; Thu, 14 Jun 2007 16:41:47 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id E3A961EE233; Thu, 14 Jun 2007 16:19:42 -0400 (EDT) Message-ID: <4671A2C8.6050509@cs.utk.edu> Date: Thu, 14 Jun 2007 16:19:20 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: "tom.petch" Subject: Re: RFC2616 vs RFC2617, was: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net><6AE049B9045C00064222693F@[10.1.110.5]><46682BC9.9050504@gmx.de> <46682E06.7030603@cs.utk.edu><46682FC5.5030204@gmx.de> <20070608081032.GA12039@nic.fr><8FEE5444-50F1-4575-9AA3-626C2A03474C@mnot.net> <466F1B3B.3040409@qbik.com> <031901c7ae6a$68e12360$0601a8c0@pc6> <467122CE.2090501@cs.utk.edu> <017001c7aea6$254a9f00$0601a8c0@pc6> In-Reply-To: <017001c7aea6$254a9f00$0601a8c0@pc6> X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Adrien de Croy , Apps Discuss , ietf-http-wg@w3.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >> how exactly does sending TLS credentials involve ferreting around in the >> depths of a network stack? >> > > It doesn't:-) Those responsible for the creation and maintenance of security > credentials - which I see as the major ongoing work of security - prefer to do > at an application level, using appropriate databases, which are > somewhat removed from the lower layers in which TLS sits. So TLS has a > different set of credentials or none, which is the problem that channel binding > overcomes. maybe what I think of as "application level" is different than how you think of this term, but I've never heard of a client application that uses TLS where TLS wasn't being called by the application, and where the application wasn't in a position to supply credentials via TLS to the server. I'm not trying to be picky here. Rather I think there's probably an important principle here that needs to be teased out. Keith From discuss-bounces@apps.ietf.org Fri Jun 15 11:03:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzDKJ-00006K-Hv; Fri, 15 Jun 2007 11:03:03 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HyjJw-00046Y-68 for discuss-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 03:00:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyjJv-00044n-PW for discuss@apps.ietf.org; Thu, 14 Jun 2007 03:00:39 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyjJv-0003Px-Dn for discuss@apps.ietf.org; Thu, 14 Jun 2007 03:00:39 -0400 Received: from [127.0.0.1] (socks2.corp.yahoo.com [216.145.54.7]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l5E70QHq065021 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Jun 2007 00:00:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=in-reply-to:references:mime-version:content-type:message-id:cc: content-transfer-encoding:from:subject:date:to:x-mailer; b=ef8z4+LfntABOSfdGHYU2FzWUfRwmKQUdXJH4cUaq8CJvT9k8/+FbOBEcr/1hCxM In-Reply-To: <466882A9.5010303@cs.utk.edu> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@[10.1.110.5]> <46682BC9.9050504@gmx.de> <46682E06.7030603@cs.utk.edu> <46682FC5.5030204@gmx.de> <466882A9.5010303@cs.utk.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6C2C0C9F-DB6E-402E-983D-1C47CDDC5761@yahoo-inc.com> Content-Transfer-Encoding: 7bit From: Mark Nottingham Subject: Re: RFC2616 vs RFC2617, was: Straw-man charter for http-bis Date: Thu, 14 Jun 2007 17:00:24 +1000 To: Keith Moore X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -15.0 (---------------) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 X-Mailman-Approved-At: Fri, 15 Jun 2007 11:03:01 -0400 Cc: Paul Hoffman , "ietf-http-wg@w3.org Group" , Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Since discussion has veered towards "what's wrong with Digest?", a few more issues, FWIW; - Forced timeout: it's important to be able to bound login state by time. While you can do this by keeping state on the server, this is impractical on massively distributed services (e.g., Yahoo!). While the opaque field of Digest can be used to transport a cryptographically signed timeout date, client implementation of Opaque is spotty AFAIK. - Dictionary attacks: Because an analogue of the password is on the wire, it's possible to make dictionary attacks against poorly chosen passwords. Again, this can be mitigated by forcing users to choose good passwords, but that is difficult when dealing with large numbers of consumers. - Downgrade attacks: Never mind intermediaries; imagine a pool of thousands of servers serving a site which use Digest auth. If one is compromised, and the browser has stored credentials, it can perform a downgrade attack by requesting Basic authentication. There's a common thread through these that I don't think has surfaced in discussions much yet; the idea that, for some kinds of installations, it's very desirable to limit the number of servers that need to know the password to a small subset of the total set of deployed servers. Doing so makes the risk profile much more manageable and assures proper resource utilisation (servers doing password verification means that there's less resource for doing what they're supposed to), and is commonly seen on large Web sites by use of cookies as tokens + a dedicated 'login' hostname. Again, digest has the potential for cross-domain authentication, but it isn't widely implemented, probably because people feel there are security issues in allowing it in an unmitigated fashion. Cookies are also attractive because when they're used, the server doesn't need to trust that the implementation performs correctly; besides scoping issues (which have been mostly worked out), cookies generally either work or they don't. Additionally, it's not clear whether more than one credential is allowed at a time (IIRC they aren't), which limits its usefulness compared to Cookies. Cheers, On 2007/06/08, at 8:11 AM, Keith Moore wrote: > > Julian Reschke wrote: >> Keith Moore wrote: >>> no. deprecate 2617. deprecate the framework that is in 2616. HTTP >>> security needs a clean slate approach. >> >> I personally have no problem with this. In the wild, most >> authentication isn't using RFC2617 anyway. >> >> However, my understanding is that the IESG doesn't allow RFC2616bis >> not to discuss authentication in *some* manner. > I'm certain that there will have to be a good answer to the > authentication question before 2616bis will be allowed to get any kind > of standardization status. (it could probably be in a separate > document). >> BTW: does the framework really require fixing? > I am pretty sure that it does. I think sites will continue to > insist on > being in control of the look and feel of the username/password dialog. > I also think that the phishing concerns have to be dealt with. The > two > of these together make for an interesting set of constraints. > > Keith > > -- Mark Nottingham mnot@yahoo-inc.com From discuss-bounces@apps.ietf.org Fri Jun 15 11:03:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzDKJ-00006P-LY; Fri, 15 Jun 2007 11:03:03 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hywmw-0007FB-E9 for discuss-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 17:23:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hywmw-0007Et-49 for discuss@apps.ietf.org; Thu, 14 Jun 2007 17:23:30 -0400 Received: from smtp.qbik.com ([210.55.214.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hywmt-0006Yn-3I for discuss@apps.ietf.org; Thu, 14 Jun 2007 17:23:29 -0400 Received: From spunky.qbik.com (unverified [192.168.0.3]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v6.2.1 (Build 1134)) with SMTP id <0009335685@smtp.qbik.com>; Fri, 15 Jun 2007 09:20:18 +1200 Received: From [192.168.0.33] (unverified [192.168.0.33]) by SMTP Server [192.168.0.3] (WinGate SMTP Receiver v) with SMTP id <0000539578@spunky.qbik.com>; Fri, 15 Jun 2007 09:20:17 +1200 Message-ID: <4671B111.9000508@qbik.com> Date: Fri, 15 Jun 2007 09:20:17 +1200 From: Adrien de Croy Organization: Qbik New Zealand Limited User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Keith Moore Subject: Re: RFC2616 vs RFC2617, was: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net><6AE049B9045C00064222693F@[10.1.110.5]><46682BC9.9050504@gmx.de> <46682E06.7030603@cs.utk.edu><46682FC5.5030204@gmx.de> <20070608081032.GA12039@nic.fr><8FEE5444-50F1-4575-9AA3-626C2A03474C@mnot.net> <466F1B3B.3040409@qbik.com> <031901c7ae6a$68e12360$0601a8c0@pc6> <467122CE.2090501@cs.utk.edu> <017001c7aea6$254a9f00$0601a8c0@pc6> <4671A2C8.6050509@cs.utk.edu> In-Reply-To: <4671A2C8.6050509@cs.utk.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-Mailman-Approved-At: Fri, 15 Jun 2007 11:03:01 -0400 Cc: Apps Discuss , ietf-http-wg@w3.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org The reason I raised it is that security and authentication / identification are 2 concepts that go hand in hand more often than not. we have a plethora of auth schemes in use on the net - one per application protocol. They sometimes are similar (i.e. SASL ones), but often are not. TLS is a protocol that provides security of communications, and allows for mutual identification through certificates. So it would make sense to solve both problems at the same time, instead of one with TLS, and the other with a horde of higher level authentication protocols. Then it gets designed and debugged once, instead of once per protocol, with obvious improvements in reliability of implementation. Adrien Keith Moore wrote: > >>> how exactly does sending TLS credentials involve ferreting around in the >>> depths of a network stack? >>> >>> >> It doesn't:-) Those responsible for the creation and maintenance of security >> credentials - which I see as the major ongoing work of security - prefer to do >> at an application level, using appropriate databases, which are >> somewhat removed from the lower layers in which TLS sits. So TLS has a >> different set of credentials or none, which is the problem that channel binding >> overcomes. >> > maybe what I think of as "application level" is different than how you > think of this term, but I've never heard of a client application that > uses TLS where TLS wasn't being called by the application, and where the > application wasn't in a position to supply credentials via TLS to the > server. > > I'm not trying to be picky here. Rather I think there's probably an > important principle here that needs to be teased out. > > Keith > > > From discuss-bounces@apps.ietf.org Fri Jun 15 11:03:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzDKJ-00006K-Hv; Fri, 15 Jun 2007 11:03:03 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HyjJw-00046Y-68 for discuss-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 03:00:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyjJv-00044n-PW for discuss@apps.ietf.org; Thu, 14 Jun 2007 03:00:39 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyjJv-0003Px-Dn for discuss@apps.ietf.org; Thu, 14 Jun 2007 03:00:39 -0400 Received: from [127.0.0.1] (socks2.corp.yahoo.com [216.145.54.7]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.6/y.rout) with ESMTP id l5E70QHq065021 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Jun 2007 00:00:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=in-reply-to:references:mime-version:content-type:message-id:cc: content-transfer-encoding:from:subject:date:to:x-mailer; b=ef8z4+LfntABOSfdGHYU2FzWUfRwmKQUdXJH4cUaq8CJvT9k8/+FbOBEcr/1hCxM In-Reply-To: <466882A9.5010303@cs.utk.edu> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@[10.1.110.5]> <46682BC9.9050504@gmx.de> <46682E06.7030603@cs.utk.edu> <46682FC5.5030204@gmx.de> <466882A9.5010303@cs.utk.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6C2C0C9F-DB6E-402E-983D-1C47CDDC5761@yahoo-inc.com> Content-Transfer-Encoding: 7bit From: Mark Nottingham Subject: Re: RFC2616 vs RFC2617, was: Straw-man charter for http-bis Date: Thu, 14 Jun 2007 17:00:24 +1000 To: Keith Moore X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -15.0 (---------------) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 X-Mailman-Approved-At: Fri, 15 Jun 2007 11:03:01 -0400 Cc: Paul Hoffman , "ietf-http-wg@w3.org Group" , Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Since discussion has veered towards "what's wrong with Digest?", a few more issues, FWIW; - Forced timeout: it's important to be able to bound login state by time. While you can do this by keeping state on the server, this is impractical on massively distributed services (e.g., Yahoo!). While the opaque field of Digest can be used to transport a cryptographically signed timeout date, client implementation of Opaque is spotty AFAIK. - Dictionary attacks: Because an analogue of the password is on the wire, it's possible to make dictionary attacks against poorly chosen passwords. Again, this can be mitigated by forcing users to choose good passwords, but that is difficult when dealing with large numbers of consumers. - Downgrade attacks: Never mind intermediaries; imagine a pool of thousands of servers serving a site which use Digest auth. If one is compromised, and the browser has stored credentials, it can perform a downgrade attack by requesting Basic authentication. There's a common thread through these that I don't think has surfaced in discussions much yet; the idea that, for some kinds of installations, it's very desirable to limit the number of servers that need to know the password to a small subset of the total set of deployed servers. Doing so makes the risk profile much more manageable and assures proper resource utilisation (servers doing password verification means that there's less resource for doing what they're supposed to), and is commonly seen on large Web sites by use of cookies as tokens + a dedicated 'login' hostname. Again, digest has the potential for cross-domain authentication, but it isn't widely implemented, probably because people feel there are security issues in allowing it in an unmitigated fashion. Cookies are also attractive because when they're used, the server doesn't need to trust that the implementation performs correctly; besides scoping issues (which have been mostly worked out), cookies generally either work or they don't. Additionally, it's not clear whether more than one credential is allowed at a time (IIRC they aren't), which limits its usefulness compared to Cookies. Cheers, On 2007/06/08, at 8:11 AM, Keith Moore wrote: > > Julian Reschke wrote: >> Keith Moore wrote: >>> no. deprecate 2617. deprecate the framework that is in 2616. HTTP >>> security needs a clean slate approach. >> >> I personally have no problem with this. In the wild, most >> authentication isn't using RFC2617 anyway. >> >> However, my understanding is that the IESG doesn't allow RFC2616bis >> not to discuss authentication in *some* manner. > I'm certain that there will have to be a good answer to the > authentication question before 2616bis will be allowed to get any kind > of standardization status. (it could probably be in a separate > document). >> BTW: does the framework really require fixing? > I am pretty sure that it does. I think sites will continue to > insist on > being in control of the look and feel of the username/password dialog. > I also think that the phishing concerns have to be dealt with. The > two > of these together make for an interesting set of constraints. > > Keith > > -- Mark Nottingham mnot@yahoo-inc.com From discuss-bounces@apps.ietf.org Fri Jun 15 11:03:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzDKJ-00006P-LY; Fri, 15 Jun 2007 11:03:03 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hywmw-0007FB-E9 for discuss-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 17:23:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hywmw-0007Et-49 for discuss@apps.ietf.org; Thu, 14 Jun 2007 17:23:30 -0400 Received: from smtp.qbik.com ([210.55.214.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hywmt-0006Yn-3I for discuss@apps.ietf.org; Thu, 14 Jun 2007 17:23:29 -0400 Received: From spunky.qbik.com (unverified [192.168.0.3]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v6.2.1 (Build 1134)) with SMTP id <0009335685@smtp.qbik.com>; Fri, 15 Jun 2007 09:20:18 +1200 Received: From [192.168.0.33] (unverified [192.168.0.33]) by SMTP Server [192.168.0.3] (WinGate SMTP Receiver v) with SMTP id <0000539578@spunky.qbik.com>; Fri, 15 Jun 2007 09:20:17 +1200 Message-ID: <4671B111.9000508@qbik.com> Date: Fri, 15 Jun 2007 09:20:17 +1200 From: Adrien de Croy Organization: Qbik New Zealand Limited User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Keith Moore Subject: Re: RFC2616 vs RFC2617, was: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net><6AE049B9045C00064222693F@[10.1.110.5]><46682BC9.9050504@gmx.de> <46682E06.7030603@cs.utk.edu><46682FC5.5030204@gmx.de> <20070608081032.GA12039@nic.fr><8FEE5444-50F1-4575-9AA3-626C2A03474C@mnot.net> <466F1B3B.3040409@qbik.com> <031901c7ae6a$68e12360$0601a8c0@pc6> <467122CE.2090501@cs.utk.edu> <017001c7aea6$254a9f00$0601a8c0@pc6> <4671A2C8.6050509@cs.utk.edu> In-Reply-To: <4671A2C8.6050509@cs.utk.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-Mailman-Approved-At: Fri, 15 Jun 2007 11:03:01 -0400 Cc: Apps Discuss , ietf-http-wg@w3.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org The reason I raised it is that security and authentication / identification are 2 concepts that go hand in hand more often than not. we have a plethora of auth schemes in use on the net - one per application protocol. They sometimes are similar (i.e. SASL ones), but often are not. TLS is a protocol that provides security of communications, and allows for mutual identification through certificates. So it would make sense to solve both problems at the same time, instead of one with TLS, and the other with a horde of higher level authentication protocols. Then it gets designed and debugged once, instead of once per protocol, with obvious improvements in reliability of implementation. Adrien Keith Moore wrote: > >>> how exactly does sending TLS credentials involve ferreting around in the >>> depths of a network stack? >>> >>> >> It doesn't:-) Those responsible for the creation and maintenance of security >> credentials - which I see as the major ongoing work of security - prefer to do >> at an application level, using appropriate databases, which are >> somewhat removed from the lower layers in which TLS sits. So TLS has a >> different set of credentials or none, which is the problem that channel binding >> overcomes. >> > maybe what I think of as "application level" is different than how you > think of this term, but I've never heard of a client application that > uses TLS where TLS wasn't being called by the application, and where the > application wasn't in a position to supply credentials via TLS to the > server. > > I'm not trying to be picky here. Rather I think there's probably an > important principle here that needs to be teased out. > > Keith > > > From discuss-bounces@apps.ietf.org Fri Jun 15 15:25:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzHPy-0001PM-3K; Fri, 15 Jun 2007 15:25:10 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HzHPw-0001PA-OE for discuss-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 15:25:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzHPw-0001P1-Ec for discuss@apps.ietf.org; Fri, 15 Jun 2007 15:25:08 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzHOs-0006Uw-8y for discuss@apps.ietf.org; Fri, 15 Jun 2007 15:24:03 -0400 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5FJO0u7015593 for ; Fri, 15 Jun 2007 19:24:01 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JJO00L01Z20NU00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for discuss@apps.ietf.org; Fri, 15 Jun 2007 13:24:00 -0600 (MDT) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JJO006ACZ7O3K60@mail-amer.sun.com>; Fri, 15 Jun 2007 13:23:52 -0600 (MDT) Date: Fri, 15 Jun 2007 12:23:48 -0700 From: Chris Newman Subject: Re: RFC2616 vs RFC2617, was: Straw-man charter for http-bis In-reply-to: <4671A2C8.6050509@cs.utk.edu> To: Keith Moore , "tom.petch" Message-id: <80C579AD5E3A190D8C4C55FD@446E7922C82D299DB29D899F> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@[10.1.110.5]> <46682BC9.9050504@gmx.de> <46682E06.7030603@cs.utk.edu> <46682FC5.5030204@gmx.de> <20070608081032.GA12039@nic.fr> <8FEE5444-50F1-4575-9AA3-626C2A03474C@mnot.net> <466F1B3B.3040409@qbik.com> <031901c7ae6a$68e12360$0601a8c0@pc6> <467122CE.2090501@cs.utk.edu> <017001c7aea6$254a9f00$0601a8c0@pc6> <4671A2C8.6050509@cs.utk.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Adrien de Croy , Apps Discuss , ietf-http-wg@w3.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Keith Moore wrote on 6/14/07 16:19 -0400: >>> how exactly does sending TLS credentials involve ferreting around in the >>> depths of a network stack? >>> >> >> It doesn't:-) Those responsible for the creation and maintenance of security >> credentials - which I see as the major ongoing work of security - prefer to >> do at an application level, using appropriate databases, which are >> somewhat removed from the lower layers in which TLS sits. So TLS has a >> different set of credentials or none, which is the problem that channel >> binding overcomes. > maybe what I think of as "application level" is different than how you > think of this term, but I've never heard of a client application that > uses TLS where TLS wasn't being called by the application, and where the > application wasn't in a position to supply credentials via TLS to the > server. > > I'm not trying to be picky here. Rather I think there's probably an > important principle here that needs to be teased out. TLS software stacks are starting to ossify into both operating systems and hardware devices. The TLS stacks are already hideously complex and I'm seeing increasing resistance to change in both the providers and consumers of TLS software. If you've ever looked closely at GSSAPI or the CMU SASL API, adding a generic authentication API to a TLS software stack would _greatly_ increase the API complexity. So much so that I'd personally choose to avoid using a TLS software stack that included such complexity. While I have no doubt that tightly coupling authentication and the security layer produces a more secure system in theory, I'm also skeptical that such a service can achieve all the requirements of both while having enough simplicity to be sustainable/maintainable/secure in practice. SSL/TLS has been around for years, is probably our most mature (and heavily used) security service beyond plaintext passwords and we're still finding deployed security holes in the software stacks. The TLS channel bindings concept decouples the security layer software from the authentication service software so they can evolve separately. I consider this such an important architecture/design improvement that it more than outweighs the slight impact on security from separating the two stacks (indeed as the separated systems are each simpler, I expect it will improve security in practice over a tightly-coupled design). The major problems involved with the security layer are related to hardening of cryptographic algorithms and I/O stack management. As it's a continuous service it has to be rock solid. Issues with bad APIs, configuration complexity and whatnot can largely be hidden by higher layers as long as the cryptography and I/O handling are solid. The major problems with authentication are centralized management and identity migration. Again and again I've seen customers ignore more advanced authentication algorithms if they fail to achieve the management/migration requirements. Although the authentication algorithms may be cool to geeks like us, they are of secondary importance in the real world. The primary skill sets needed to work on a security layer vs. an authentication service are thus almost completely disjoint. As a result I consider the architectural separation and channel bindings concept absolutely critical to producing a workable replacement for today's web-forms+passwords model. The management/migration/branding/usability requirements are the non-negotiable ones, the actual authentication algorithm used is irrelevant absent a solution to the primary requirements. - Chris From discuss-bounces@apps.ietf.org Fri Jun 15 17:58:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzJob-00086K-0f; Fri, 15 Jun 2007 17:58:45 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HzJoa-00086F-64 for discuss-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 17:58:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzJoZ-000867-So for discuss@apps.ietf.org; Fri, 15 Jun 2007 17:58:43 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzJoX-0004u4-Pm for discuss@apps.ietf.org; Fri, 15 Jun 2007 17:58:43 -0400 Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5FLwf5o002404 for ; Fri, 15 Jun 2007 21:58:41 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JJP0000153ZJV00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for discuss@apps.ietf.org; Fri, 15 Jun 2007 15:58:41 -0600 (MDT) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JJP009EG6DPQS00@mail-amer.sun.com>; Fri, 15 Jun 2007 15:58:41 -0600 (MDT) Date: Fri, 15 Jun 2007 14:58:38 -0700 From: Chris Newman Subject: Re: Straw-man charter for http-bis In-reply-to: <466CC26F.90603@cs.utk.edu> To: Keith Moore , Henrik Nordstrom Message-id: <342C5167F40AD28C4ED69C9B@[10.1.110.5]> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@[10.1.110.5]> <1181250794.24162.109.camel@henriknordstrom.net> <46696B98.1090201@cisco.com> <1181342059.4818.63.camel@henriknordstrom.net> <8DD2BD5A-9068-43C3-973E-382FAD2E0EA8@osafoundation.org> <1181532224.3389.47.camel@henriknordstrom.net> <466CC26F.90603@cs.utk.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Apps Discuss , Mark Nottingham , "ietf-http-wg@w3.org Group" , Eliot Lear X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Keith Moore wrote on 6/10/07 23:33 -0400: >>> Digest has a bad reputation particularly among Web App developers for >>> a number of reasons, some inherent to the design and specification, >>> some stemming from implementation and deployment choices. >>> >> >> Nearly all is implementation. >> > ah, but what's the reason for all of those implementation-imposed > constraints? I would speculate it's because the following mandatory pieces of a complete DIGEST-based solution were never written down: * Client UI requirements * How to store DIGEST H(A1) in a central authentication repository such as LDAP or RADIUS in an interoperable fashion * How web CGIs, PHP modules, etc. interface to the HTTP server's DIGEST support * How to tie the DIGEST identity to whatever real identity system happens to be deployed at the web site. From an IETF standards perspective, that means getting the LDAP directory entry and/or RADIUS/DIAMETER attributes for the user to the subsystem that needs that information. In practice this can also involve a SQL database with unspecified keys and attributes. * How a web page can securely associate branding with a DIGEST authentication UI in the browser * How to migrate an existing password repository using an arbitrary one-way-function to store password verifiers to one that's DIGEST compatible, and do so in a way that won't generate service calls from customers. Since implementations already have all this infrastructure for plaintext passwords (existing standards are sufficient due to plaintext simplicity), why should they waste time doing a one-off version of all this work if there aren't enough standards written for it to interoperate? Besides, DIGEST without TLS is now so weak in a 10-cents-per-windows-zombie-CPU-week world that I question the value of doing any of this work just for DIGEST. - Chris From discuss-bounces@apps.ietf.org Sun Jun 17 07:37:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzt4c-0000Zm-E8; Sun, 17 Jun 2007 07:37:38 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hzt4b-0000W0-5M for discuss-confirm+ok@megatron.ietf.org; Sun, 17 Jun 2007 07:37:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzt4a-0000Tz-PZ for discuss@apps.ietf.org; Sun, 17 Jun 2007 07:37:36 -0400 Received: from av8-2-sn3.vrr.skanova.net ([81.228.9.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hzt4a-0006hG-9Y for discuss@apps.ietf.org; Sun, 17 Jun 2007 07:37:36 -0400 Received: by av8-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 150EB39461; Sun, 17 Jun 2007 13:37:35 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av8-2-sn3.vrr.skanova.net (Postfix) with ESMTP id ECA3A38111; Sun, 17 Jun 2007 13:37:34 +0200 (CEST) Received: from henriknordstrom.net (81-233-163-21-no84.tbcn.telia.com [81.233.163.21]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 4666037E42; Sun, 17 Jun 2007 13:37:33 +0200 (CEST) Received: from [192.168.1.2] (henriknordstrom.net [192.168.1.2]) by henriknordstrom.net (8.12.11.20060308/8.12.8) with ESMTP id l5HBbWwq001562; Sun, 17 Jun 2007 13:37:32 +0200 Subject: Re: Straw-man charter for http-bis From: Henrik Nordstrom To: Chris Newman In-Reply-To: <342C5167F40AD28C4ED69C9B@[10.1.110.5]> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@[10.1.110.5]> <1181250794.24162.109.camel@henriknordstrom.net> <46696B98.1090201@cisco.com> <1181342059.4818.63.camel@henriknordstrom.net> <8DD2BD5A-9068-43C3-973E-382FAD2E0EA8@osafoundation.org> <1181532224.3389.47.camel@henriknordstrom.net> <466CC26F.90603@cs.utk.edu> <342C5167F40AD28C4ED69C9B@[10.1.110.5]> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-B8VGHf36WKgTnWUlst2I" Date: Sun, 17 Jun 2007 13:37:32 +0200 Message-Id: <1182080252.751.41.camel@henriknordstrom.net> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on henriknordstrom.net X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: Apps Discuss , Mark Nottingham , Keith Moore , "ietf-http-wg@w3.org Group" , Eliot Lear X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --=-B8VGHf36WKgTnWUlst2I Content-Type: text/plain Content-Transfer-Encoding: quoted-printable fre 2007-06-15 klockan 14:58 -0700 skrev Chris Newman: > I would speculate it's because the following mandatory pieces of a comple= te=20 > DIGEST-based solution were never written down: >=20 > * Client UI requirements Sure, but how much of this is the role of IETF? Since when do IETF specify client implementation besides what impacts the wire protocols? Also don't forget that HTTP has widespread use in many applications where there is no UI at all. > * How to store DIGEST H(A1) in a central authentication repository such a= s > LDAP or RADIUS in an interoperable fashion Many server implementations uses LDAP as H(A1) store already, with reasonable options for secure channels server<->backend. And RADIUS has Digest support, now at PROPOSED STANDARD level (July 2006) and circulated as a draft for quite some years before that. In RADIUS it's the RADIUS server being the Digest endpoint and the HTTP server just relays the Digest exchanges and getting told the user identity (and other RADIUS attributes) on successful authentication. SASL has had Digest support for quite some time, but is not entirely compatible with HTTP Digest. > * How web CGIs, PHP modules, etc. interface to the HTTP server's DIGEST s= upport As first point above, but server implementation. > * How to tie the DIGEST identity to whatever real identity system happens= to > be deployed at the web site. From an IETF standards perspective, that > means getting the LDAP directory entry and/or RADIUS/DIAMETER attribute= s for > the user to the subsystem that needs that information. In practice thi= s can > also involve a SQL database with unspecified keys and attributes. HTTP is no different here than any other protocol in this regard. IPSec, TLS, PPP, FTP, SMTP, SNMP, BGP, IMAP, etc etc.. all have similar needs in identification of the involved parties, and all fight the same integration problems more or less. But in several of those areas the problems discussed regarding HTTP authentication is more accepted as "how things work" and not considered such big problem.. But it's also true that the use of plaintext is very common due to much the same reasons in integration and migration. > * How a web page can securely associate branding with a DIGEST authentica= tion > UI in the browser Yes. > * How to migrate an existing password repository using an arbitrary > one-way-function to store password verifiers to one that's DIGEST compa= tible, > and do so in a way that won't generate service calls from customers. The simple fact that there is some migration is usually sufficient to stop such project even at the planning stage. But it's unavoidable in order to get away from plain-text exchanges. It's not a very hard migration, especially not if the password backend already periodically expires passwords. But it requires the backend to support Digest (or whatever scheme is used), and for password storage security reasons to be configured with the realm details.. > Since implementations already have all this infrastructure for plaintext=20 > passwords (existing standards are sufficient due to plaintext simplicity)= , why=20 > should they waste time doing a one-off version of all this work if there = aren't=20 > enough standards written for it to interoperate? Even with standards chances are high the needed support would not be enabled by default, or even implemented. > Besides, DIGEST without TLS=20 > is now so weak in a 10-cents-per-windows-zombie-CPU-week world that I que= stion=20 > the value of doing any of this work just for DIGEST. I wouldn't say Digest is that weak. Sure, it's possible to perform a offline brute-force password guessing attack based on the exchanges, and due to all the legacy crap it's possible for a man in the middle to downgrade Digest slightly if the client and server is willing to. But yes, there is a need for a stronger replacement. Especially one without all the compatibility fallbacks crap. But more importantly there is a need for a robust framework where new schemes can be plugged in more easily, and most importantly a way to make HTTP authentication more visually and functionality attractive in the browser world. Even if IETF comes up with the technically most secure authentication scheme it's unlikely to gain widespread foothold as "the" HTTP authentication scheme and there will always be major vendors doing their own thing I am afraid. Regards Henrik --=-B8VGHf36WKgTnWUlst2I Content-Type: application/pgp-signature; name=signature.asc Content-Description: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad meddelandedel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iQCVAwUARnUc+UNPQ5Kbx8daAQLsjgP+NWMwFgqmZj1ESJOSPTuY7z18x20pRnHV mUMWmAkzZjhZheEkUzIv8rf8h+1QJu9wEKNc2Jx5refpQlKr0yrC8hPWiMCoBPfu 3mzlIp1v7wjC3hmAj9nZvC+uQmRtGX07Gyfm9UF2aJmdaUDjI2bP3vGMqFnoObHD ruGDXsbHArM= =FrwA -----END PGP SIGNATURE----- --=-B8VGHf36WKgTnWUlst2I-- From discuss-bounces@apps.ietf.org Sun Jun 17 11:08:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzwMN-0002JQ-2O; Sun, 17 Jun 2007 11:08:11 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HzwMM-0002JK-Pw for discuss-confirm+ok@megatron.ietf.org; Sun, 17 Jun 2007 11:08:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzwMM-0002J7-GM for discuss@apps.ietf.org; Sun, 17 Jun 2007 11:08:10 -0400 Received: from sparkle.rodents.montreal.qc.ca ([216.46.5.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzwMI-0001JB-FY for discuss@apps.ietf.org; Sun, 17 Jun 2007 11:08:10 -0400 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id LAA10876; Sun, 17 Jun 2007 11:08:02 -0400 (EDT) From: der Mouse Message-Id: <200706171508.LAA10876@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Sun, 17 Jun 2007 11:02:47 -0400 (EDT) To: discuss@apps.ietf.org Subject: Re: Straw-man charter for http-bis In-Reply-To: <1182080252.751.41.camel@henriknordstrom.net> References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@[10.1.110.5]> <1181250794.24162.109.camel@henriknordstrom.net> <46696B98.1090201@cisco.com> <1181342059.4818.63.camel@henriknordstrom.net> <8DD2BD5A-9068-43C3-973E-382FAD2E0EA8@osafoundation.org> <1181532224.3389.47.camel@henriknordstrom.net> <466CC26F.90603@cs.utk.edu> <342C5167F40AD28C4ED69C9B@[10.1.110.5]> <1182080252.751.41.camel@henriknordstrom.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > Since when do IETF specify client implementation besides what impacts > the wire protocols? "grep API" in the RFC index returns 27 lines of hits: to list just the RFC numbers I see in that list (without searching out the RFC numbers for the lines that don't begin a listing), 1509 1961 1964 2025 2292 2367 2478 2614 2628 2744 2771 2783 2853 3338 3542 3867 4401 4462 4584 4752. (2292 particularly irritates me, though for non-IETF reasons.) /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From discuss-bounces@apps.ietf.org Sun Jun 17 11:17:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzwUw-0004qt-Gl; Sun, 17 Jun 2007 11:17:02 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HzwUu-0004qm-Qf for discuss-confirm+ok@megatron.ietf.org; Sun, 17 Jun 2007 11:17:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzwUu-0004qe-HC for discuss@apps.ietf.org; Sun, 17 Jun 2007 11:17:00 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzwUt-00044S-V7 for discuss@apps.ietf.org; Sun, 17 Jun 2007 11:17:00 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 963FC1EE259; Sun, 17 Jun 2007 11:16:54 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orKt4J+1zj4g; Sun, 17 Jun 2007 11:16:52 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 5FE151EE251; Sun, 17 Jun 2007 11:16:39 -0400 (EDT) Message-ID: <46755041.4040401@cs.utk.edu> Date: Sun, 17 Jun 2007 11:16:17 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Henrik Nordstrom Subject: Re: Straw-man charter for http-bis References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net> <6AE049B9045C00064222693F@[10.1.110.5]> <1181250794.24162.109.camel@henriknordstrom.net> <46696B98.1090201@cisco.com> <1181342059.4818.63.camel@henriknordstrom.net> <8DD2BD5A-9068-43C3-973E-382FAD2E0EA8@osafoundation.org> <1181532224.3389.47.camel@henriknordstrom.net> <466CC26F.90603@cs.utk.edu> <342C5167F40AD28C4ED69C9B@[10.1.110.5]> <1182080252.751.41.camel@henriknordstrom.net> In-Reply-To: <1182080252.751.41.camel@henriknordstrom.net> X-Enigmail-Version: 0.95.0 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Apps Discuss , Mark Nottingham , Chris Newman , "ietf-http-wg@w3.org Group" , Eliot Lear X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >> I would speculate it's because the following mandatory pieces of a complete >> DIGEST-based solution were never written down: >> >> * Client UI requirements >> > > Sure, but how much of this is the role of IETF? > > Since when do IETF specify client implementation besides what impacts > the wire protocols? > Traditionally we try to not constrain client design more than necessary, but that doesn't mean we strictly limit ourselves to defining what happens on the wire. And to the extent that we have limited ourselves, if we're learning that this is not sufficient, that's a good reason for relaxing that limitation. > Also don't forget that HTTP has widespread use in many applications > where there is no UI at all. > IMHO it would be reasonable to define a profile of HTTP for use with interactive web browsers. >> * How web CGIs, PHP modules, etc. interface to the HTTP server's DIGEST support >> > > As first point above, but server implementation. > I don't see why we shouldn't describe these things if doing so helps acceptance and interoperability. Perhaps as informational rather than normative text, but we should make sure that there's a complete picture. These things are important to the success of an authentication system. A lot of our failings in the area of authentication have been due to failure to consider more than just the on-the-wire protocol - we haven't tried very hard to make our technology accessible to potential users. Keith From discuss-bounces@apps.ietf.org Mon Jun 18 05:52:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Du1-0002xN-Gd; Mon, 18 Jun 2007 05:52:05 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1I0Du0-0002xE-8D for discuss-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 05:52:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Dtz-0002x5-Pg for discuss@apps.ietf.org; Mon, 18 Jun 2007 05:52:03 -0400 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Dtz-0006MD-B3 for discuss@apps.ietf.org; Mon, 18 Jun 2007 05:52:03 -0400 Received: from pc6 (1Cust210.tnt9.lnd4.gbr.da.uu.net [62.188.138.210]) by astro.systems.pipex.net (Postfix) with SMTP id 825BEE0000D0; Mon, 18 Jun 2007 10:51:58 +0100 (BST) Message-ID: <01fe01c7b185$52f800a0$0601a8c0@pc6> From: "tom.petch" To: "Keith Moore" References: <392C98BA-E7B8-44ED-964B-82FC48162924@mnot.net><6AE049B9045C00064222693F@[10.1.110.5]><46682BC9.9050504@gmx.de> <46682E06.7030603@cs.utk.edu><46682FC5.5030204@gmx.de> <20070608081032.GA12039@nic.fr><8FEE5444-50F1-4575-9AA3-626C2A03474C@mnot.net> <466F1B3B.3040409@qbik.com> <031901c7ae6a$68e12360$0601a8c0@pc6> <467122CE.2090501@cs.utk.edu> <017001c7aea6$254a9f00$0601a8c0@pc6> <4671A2C8.6050509@cs.utk.edu> Subject: Re: RFC2616 vs RFC2617, was: Straw-man charter for http-bis Date: Mon, 18 Jun 2007 10:44:58 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Adrien de Croy , Apps Discuss , ietf-http-wg@w3.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org ----- Original Message ----- From: "Keith Moore" To: "tom.petch" Cc: "Adrien de Croy" ; "Apps Discuss" ; Sent: Thursday, June 14, 2007 10:19 PM Subject: Re: RFC2616 vs RFC2617, was: Straw-man charter for http-bis > > >> how exactly does sending TLS credentials involve ferreting around in the > >> depths of a network stack? > >> > > > > It doesn't:-) Those responsible for the creation and maintenance of security > > credentials - which I see as the major ongoing work of security - prefer to do > > at an application level, using appropriate databases, which are > > somewhat removed from the lower layers in which TLS sits. So TLS has a > > different set of credentials or none, which is the problem that channel binding > > overcomes. > maybe what I think of as "application level" is different than how you > think of this term, but I've never heard of a client application that > uses TLS where TLS wasn't being called by the application, and where the > application wasn't in a position to supply credentials via TLS to the > server. > > I'm not trying to be picky here. Rather I think there's probably an > important principle here that needs to be teased out. > It is good to be picky; it ensures I am thinking clearly (or not as the case may be). I think the problem arises at the receiving end, where TLS needs to validate credentials and where, as in the more secure organisations that I see, the credentials may be stored in a proprietary database (Active Directory, Domain Controller and other manufacturers' equivalents). I do not see the interface from TLS to this store so that whatever the incoming credentials need to be compared with can be obtained by TLS. Hence TLS gets its own set. Also, while I see no issue with the passing around of a certificate between application and TLS, I do see an exposure doing this with other forms of authentication eg passwords. (Certificates, like IPv6, are a good solution to a widespread problem that the world at large irritatingly refuses to adopt:-(. With channel bindings, TLS passes on a secure identifier of the channel which the application can then use to check that there is no Man In The Middle, so there are no such concerns there. Tom Petch > Keith > From discuss-bounces@apps.ietf.org Mon Jun 18 13:34:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0L7n-000215-Tz; Mon, 18 Jun 2007 13:34:47 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1I0L7m-00020o-Bh for discuss-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 13:34:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0L7m-00020f-25 for discuss@apps.ietf.org; Mon, 18 Jun 2007 13:34:46 -0400 Received: from an-out-0708.google.com ([209.85.132.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0L7j-00009A-Lw for discuss@apps.ietf.org; Mon, 18 Jun 2007 13:34:46 -0400 Received: by an-out-0708.google.com with SMTP id d26so366304and for ; Mon, 18 Jun 2007 10:34:42 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=a1R9m4r2L8oVYSCRP0xrxWgKbgKE1gjsUiXS541/vp9uLk/3UVhKx3Zqz82mUypqJWduxkkpoHpG2z5+8EvuehycPh/VCmaWjFwtLniu9gFc/CHgchUKfaz7g+pxopkJJBsA3AdfEMAyVxhMRoK8LZ2kTuIYDdgxDc8d4nrzNmk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gS3YhSb3M5c1l7IJ4ZyJ3JWdqDkXZFPi3XfXI9pSjoJS+wcF6iRN1P7bK3TGssj7P9+2+D8w12pZVztBFYdBq1N0qlVcGZUHVzmQYqjyyy8qukQmH8PYKHJYAIsDmvjBJ7h7QrLLEBL0eX0opny7HqobIctKxujc6vL25Nw+c/Y= Received: by 10.100.124.5 with SMTP id w5mr3674485anc.1182188082737; Mon, 18 Jun 2007 10:34:42 -0700 (PDT) Received: by 10.100.5.12 with HTTP; Mon, 18 Jun 2007 10:34:42 -0700 (PDT) Message-ID: <6bb028490706181034r78352061kda89f149d05620a2@mail.gmail.com> Date: Mon, 18 Jun 2007 10:34:42 -0700 From: "Markus Scherer" To: "Frank Ellermann" Subject: Re: Comments on Unicode Format for Network Interchange In-Reply-To: <462E9074.14BD@xyzzy.claranet.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6bb028490704231048s41deaf57q33ddb21fd0e76f17@mail.gmail.com> <462E9074.14BD@xyzzy.claranet.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: discuss@apps.ietf.org, Mark Davis X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Dear Frank, Sorry for the very late reply. I would like to point out that my main interest in the Net-Unicode internet-draft and in sending comments is with the discussion of Unicode normalization and versioning. I happily note that you didn't disagree with my suggestions in that area, except for one suggested text deletion (where I now mostly agree with you). As for the issues on line endings and signatures: On 4/24/07, Frank Ellermann wrote: > Markus Scherer wrote: > > > *** Suggested change: > > 2. Line-endings MUST be indicated by the sequence Carriage-Return > > (U+000D) followed by Line-Feed (U+000A), or by a single > > Carriage-Return (U+000D), or by a single Line-Feed (U+000A). > > -1F > > > Justification: We believe that single CR and LF are common because of > > implementation practice on a variety of platforms, and that it is both > > unrealistic and unnecessary to try to legislate them away. > > No, it causes havoc. > > > Applications already commonly handle all of CR, LF and CR+LF, and some > > support even more characters according to the Unicode Newline > > Guidelines. > > The draft isn't about arbitrary text or XML (where you'd also need NEL), > it's about telnet. It tries to extend ALPHA and DIGIT as used in some > syntax constructs for text in Internet protocols, it doesn't try to > introduce a new concept of "line" in these protocols. I didn't understand from the internet-draft that it was only geared towards telnet. If it is indeed only about telnet, then the end-of-line defininition is of course fine, and apologies for causing confusion. If it is not intended just for telnet, then I believe allowing several already-common forms of line endings is simply pragmatic. > > *** Suggested change: > > 4. The UTF-8 signature byte sequence (EF BB BF, UTF-8 encoding of > > U+FEFF, sometimes called Byte Order Mark ("BOM")), when it > > appears at the beginning of the text, SHOULD be deleted by the > > recipient. > > I don't think that works. The draft isn't about local text or XML > files, > it's about Internet protocols, especially telnet, over the wire. Fair enough, and I am not suggesting that Unicode signatures should be used there. My suggestion was intended to clarify the specification for when a Unicode signature is in fact included even when it is not legal, not recommended, or simply not necessary. I find it easier, in practice, to specify how to handle a situation than to just require that it not occur. > > If a Word Joiner is needed in the text, U+2060 WORD JOINER SHOULD > > be used instead of U+FEFF ZERO WIDTH NO-BREAK SPACE. > > Already covered by STD 63 (RFC 3629). Ok, thanks. > > *** Suggested change: > > 1. Control codes from both the "C0" (U+0000..U+001F, U+007F) > > and "C1" (U+0080..U+009F) ranges, > > with the exception of HT (09), LF (0A) and CR (0D), > > SHOULD NOT be used unless required by exceptional circumstances. > > > Justification: The sets of C0 and C1 control codes that should and > > should not be used should be defined explicitly, and with code point > > values. Only HT, LF and CR are very widely used. > > Makes sense, but HT can have surprising effects if it's "expanded" into > one or more spaces, that would need a "security consideration". Does Possible, although HT is rarely expanded to spaces in low-level processing. The most important point here is that the set of control codes be specified very explicitly. > DEL really belong to the C0 set ? Maybe avoiding these old terms is > clearer for readers today. I don't actually know if DEL is formally a C0 control code. I would be perfectly happy with specifying the control codes via Unicode code point ranges and not using the terms "C0" and "C1". (Although for charset old-timers these terms might be useful.) > > *** Suggested change: > > Remove points 2. and 3. > > See above. Try to edit a plain text file using LF as line-end with the > tool styling itself as "editor" on a Windows box, and you'll see what I > mean. IIRC there were some hot debates why the IETF ftp server sends > text files with (only) LF, in theory breaking the ABNF in these files. > This is a rathole, please just accept it as some IETF oddity. We're > not forced to use CRLF in local files if we hate it. Again, the importance of the line ending encoding is way below that of the normalization and versioning discussion. Here I was simply suggesting to allow what's already common practice - if not for telnet, then for many other text formats. > > *** Suggested change: > > Drop this second bullet and the following paragraph. > > No, folks need to know that Unicode is a moving target to some degree, > that only small and different subsets are supported by most devices, > and that it's horribly complex in comparison with ASCII or many legacy > charsets. The advantage is obvious, some disadvantages are not. I agree with you about not deleting the bullet ("The normalization specified here, NFC (see Section 3), performs...") and the following paragraph ("The NFC tables may be updated over time"), or not entirely. However, the last sentence of that paragraph, which reads The stability of the Net-Unicode format is thus guaranteed when any implementation that converts text into Net-Unicode format does not permit unassigned characters. should be deleted, because with a SHOULD for normalization the stability of the Net-Unicode format does not depend on normalization stability any more. > > Suggested change: Please add a reference for [RFC3629] UTF-8, a > > transformation format of ISO 10646 > > There is a RFC 3629 (STD 63) reference, it's in the first part with > the normative references. Thanks, and sorry for the oversight. Best regards, markus From discuss-bounces@apps.ietf.org Mon Jun 18 17:23:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Ogs-0005F7-P9; Mon, 18 Jun 2007 17:23:14 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1I0Ogr-0005Ey-GO for discuss-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 17:23:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Ogr-0005Eq-2s for discuss@apps.ietf.org; Mon, 18 Jun 2007 17:23:13 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Ogq-000106-Gt for discuss@apps.ietf.org; Mon, 18 Jun 2007 17:23:13 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1I0Ogj-0003pv-9x for discuss@apps.ietf.org; Mon, 18 Jun 2007 23:23:05 +0200 Received: from dialin-145-254-045-028.pools.arcor-ip.net ([145.254.45.28]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Jun 2007 23:23:05 +0200 Received: from nobody by dialin-145-254-045-028.pools.arcor-ip.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Jun 2007 23:23:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: discuss@apps.ietf.org From: Frank Ellermann Subject: Re: Comments on Unicode Format for Network Interchange Date: Mon, 18 Jun 2007 23:18:14 +0200 Organization: Lines: 99 Message-ID: <4676F696.321@xyzzy.claranet.de> References: <6bb028490704231048s41deaf57q33ddb21fd0e76f17@mail.gmail.com> <462E9074.14BD@xyzzy.claranet.de> <6bb028490706181034r78352061kda89f149d05620a2@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: dialin-145-254-045-028.pools.arcor-ip.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Markus Scherer wrote: > Sorry for the very late reply. No issue, I still have that "ping" dated 2007-03-29 sitting in my "Todos" folder and waiting for better times when nobody tries to update the core e-mail RfCs or similar emergencies... ;-) > I didn't understand from the internet-draft that it was only > geared towards telnet. > If it is indeed only about telnet, then the end-of-line defininition > is of course fine, and apologies for causing confusion. The "only" might be misleading, a bunch of other protocols used to be based on telnet, and inherited some features more or less clearly. I guess John has to explain in a new version of this I-D what exactly he's talking about (a long string of "updates RFCs x, y, z" in the header), and where he only proposes to update other protocols (like "whois") in the spirit of his I-D. Maybe 2821bis (SMTP) is an interesting example, at the moment it still "allows" control char.s in places where I'd prefer to get rid of them (as recommended in the "net-Unicode" I-D). Of course 2821bis will insist on CR LF for lineends. Just an example, it's the same issue for many IETF protocols. An IMO bad case is FTP, where "a" (= ascii text, and convert lineends for whatever passes as "local" convention) is the default. The "local" convention supported on my box is "only CR doesn't work as expected". And besides I rarely use FTP for text and get garbage when I forgot the "b" (binary). Fortunately I was never forced to grab a text file from an EBCDIC FTP server. :-) > If it is not intended just for telnet, then I believe > allowing several already-common forms of line endings is > simply pragmatic. It would cause havoc for some scripts I use (POP3, HTTP, SMTP, ident, whois, simple stuff). The SMTP and whois scripts fix a body LF to CR LF on the fly, but they'd break miserably if somebody thinks that a bare ASCII CR is a lineend. Let alone Latin-* NEL, or weirder scenarios. So it's not "only" telnet, but it still is about something you can completely ignore, unless you need to post a NetNews article with telnet to the NNTP port, or similar stunts. [BOM] > My suggestion was intended to clarify the specification for > when a Unicode signature is in fact included even when it is > not legal, not recommended, or simply not necessary. I find > it easier, in practice, to specify how to handle a situation > than to just require that it not occur. Okay, admittedly I don't like it if I get a mail where the body starts with a BOM, because my obsolete MUA treats UTF-8 as windows-1252 claiming that it's Latin-1. Something on the side of the sender could have silently removed this BOM. But the I-D is more general, it has no concept of "body" or SDU. Maybe it should mention the BOM issue in an example (?) For telnet it's IMO pointless, that's lines or rather control sequences plus text defining the content of a screen, the I-D can't say that a BOM should be silently removed when it would end up at the begin of a line. Ignoring BiDi, and besides the draft deprecates all control char.s, even HT, allowing only CR LF in this order. Is it your idea to eliminate BOM like the I-D eliminates SUB (= EOF on some platforms) ? If that's your point I think it's better solved in RFC 3629, that's already at STD. Otherwise the I-D could arguably also talk about non-characters, surrogates, overlong UTF-8, more-than-21-bits UTF-8, etc., all addressed in RFC 3629. > the last sentence of that paragraph, which reads > The stability of the Net-Unicode format is thus guaranteed > when any implementation that converts text into Net-Unicode > format does not permit unassigned characters. > should be deleted, because with a SHOULD for normalization the > stability of the Net-Unicode format does not depend on > normalization stability any more. I can't judge it, my last attempt to implement something in this direction ended again with giving up. IOW the SHOULD is wishful thinking as far as my scripts are concerned. Maybe I try it again with "level one" later, actually I was only curious what SASLPREP really does, in addition to its NFC part (it uses case sensitive NFKC plus tons of prohibited and mapped to nothing or mapped to space rules). Frank