Re: [secdir] secdir review of draft-melnikov-imap-keywords-06
John C Klensin <john-ietf@jck.com> Sat, 28 November 2009 22:13 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AADE63A67CF; Sat, 28 Nov 2009 14:13:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level:
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hC2MCtQ5epOY; Sat, 28 Nov 2009 14:13:37 -0800 (PST)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 2E3FF3A6358; Sat, 28 Nov 2009 14:13:37 -0800 (PST)
Received: from [127.0.0.1] (helo=p2) by bs.jck.com with esmtp (Exim 4.34) id 1NEVXj-000AtJ-Tx; Sat, 28 Nov 2009 17:13:28 -0500
Date: Sat, 28 Nov 2009 17:13:26 -0500
From: John C Klensin <john-ietf@jck.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>, Samuel Weiler <weiler@watson.org>
Subject: Re: [secdir] secdir review of draft-melnikov-imap-keywords-06
Message-ID: <8DA1A1011B7EFEC9DB984281@[192.168.1.110]>
In-Reply-To: <4B11964A.6@isode.com>
References: <alpine.BSF.2.00.0911091524400.76090@fledge.watson.org> <4B03AD81.9090103@isode.com> <alpine.BSF.2.00.0911281604410.72535@fledge.watson.org> <4B11964A.6@isode.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: ietf@ietf.org, secdir@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 28 Nov 2009 22:13:38 -0000
--On Saturday, November 28, 2009 9:29 PM +0000 Alexey Melnikov <alexey.melnikov@isode.com> wrote: >... >> I'm hearing "it's within the scope of the expert's judgement >> to require an IETF Consensus doc" and "In cases when an IMAP >> Keyword being registered is already deployed, Expert >> Reviewers should favour registering it over requiring >> perfect documentation." If I were an implementer who got >> told "you need a consensus doc", I'd be more than a little >> tempted to go ahead and deploy, then reapply for the >> registration. > > Well, if one works for Microsoft, Google, Mozilla, etc. (not > trying to pick on anybody), then one does it every time. > Hopefully Expert Review is low enough bar to tempt people (if > tempt is the right word here at all) to register. Sam, For whatever it is worth, the above exchange goes to the very root of the question of what we think our registration procedures and registries are for, at least when there isn't a scarcity of possible identifiers. One theory is that they should be designed to prevent garbage, or warn people against garbage by the fact that something isn't registered. I think we've seen ample evidence that theory doesn't work, with your comments and Alexey's above both constituting examples. The other is that the main purpose of registration is to provide sufficient information and documentation to promote interoperability by virtue of encouraging people to avoid using the same identifier for different purposes. I'm more optimistic about the second than the first, but it calls for a fairly low bar on registrations. Neither model has much to do with security: registration, no matter how high or low the threshold, won't prevent an attack if someone is inclined to misuse or reuse an identifier in a malicious way. Nor will non-registration help avoid someone finding out what an identifier looks like an attacking whatever it represents if one were inclined to do that... only the most dedicated believer in security through obscurity could believe that non-registration is helpful in that regard and it would be a stretch even then. john
- secdir review of draft-melnikov-imap-keywords-06 Samuel Weiler
- Re: secdir review of draft-melnikov-imap-keywords… Alexey Melnikov
- Re: [secdir] secdir review of draft-melnikov-imap… Samuel Weiler
- Re: [secdir] secdir review of draft-melnikov-imap… Alexey Melnikov
- Re: [secdir] secdir review of draft-melnikov-imap… John C Klensin
- Re: [secdir] secdir review of draft-melnikov-imap… Tero Kivinen
- Re: [secdir] secdir review of draft-melnikov-imap… Arnt Gulbrandsen