Re: [stir] current draft charter - ENUM and databases

Dave Crocker <dhc@dcrocker.net> Tue, 18 June 2013 15:44 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37BD21F9ACA for <stir@ietfa.amsl.com>; Tue, 18 Jun 2013 08:44:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.528
X-Spam-Level:
X-Spam-Status: No, score=-6.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYlPe7FkFs27 for <stir@ietfa.amsl.com>; Tue, 18 Jun 2013 08:44:01 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E161421F9AD5 for <stir@ietf.org>; Tue, 18 Jun 2013 08:44:01 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r5IFhfEU022003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 18 Jun 2013 08:43:45 -0700
Message-ID: <51C0801F.6090101@dcrocker.net>
Date: Tue, 18 Jun 2013 08:43:27 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: "Peterson, Jon" <jon.peterson@neustar.biz>
References: <CDE4E69C.21E90%jon.peterson@neustar.biz>
In-Reply-To: <CDE4E69C.21E90%jon.peterson@neustar.biz>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 18 Jun 2013 08:43:45 -0700 (PDT)
Cc: "stir@ietf.org" <stir@ietf.org>, Hadriel Kaplan <hadriel.kaplan@oracle.com>, Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Re: [stir] current draft charter - ENUM and databases
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stir>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Jun 2013 15:44:07 -0000

On 6/17/2013 5:47 PM, Peterson, Jon wrote:
> But at the end of the day I was also envisioning that this revisited
> identity system would still work for regular domain names per RFC4474, and
> that we'd probably even keep CID as an option for Identity-Info (or its
> successor). So I was anticipating there'd be diversity in the means by
> which credentials could be indicated by Identity-Info, and that having a
> "root" wouldn't be exclusive in that there are identifiers other than
> telephone numbers in the system too.



The task of the current effort is to be able to determine whether the 
value in the From header field is authorized for use.  This means 
checking with an authority for the assignment of the value.

(Forgive me, but on review I don't see any text in the draft charter 
that is as simple and direct as the above, in terms of stating the basic 
deliverable for this effort.)


For each type of data that can go in the From field, there's likely to 
be a different assignment authority and very possibly important 
differences in the mechanisms for doing queries, to determine 
authorization.

The desire for keeping things generic is understandinable; it's 
appealing.  But I doubt there's an existence proof for its working on 
something of this scale and criticality over the open Internet.

That is, take the current, known case and solve it as cleanly as 
possible.  Trying to solve possible future alternatives is almost 
certainly a distraction, of the type that will introduce complexity and 
delays.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net