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: secdir@core3.amsl.com
Delivered-To: secdir@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>
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
X-Mailman-Approved-At: Mon, 30 Nov 2009 00:43:14 -0800
Cc: ietf@ietf.org, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-melnikov-imap-keywords-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-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