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

Hadriel Kaplan <hadriel.kaplan@oracle.com> Sat, 15 June 2013 19:06 UTC

Return-Path: <hadriel.kaplan@oracle.com>
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 8BFA521F9D9D for <stir@ietfa.amsl.com>; Sat, 15 Jun 2013 12:06:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.57
X-Spam-Level:
X-Spam-Status: No, score=-6.57 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
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 tJIFO8tzWvPj for <stir@ietfa.amsl.com>; Sat, 15 Jun 2013 12:06:29 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 051C121F9B22 for <stir@ietf.org>; Sat, 15 Jun 2013 12:06:28 -0700 (PDT)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5FJ6KKn024799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 15 Jun 2013 19:06:21 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5FJ6JM5021499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Jun 2013 19:06:20 GMT
Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5FJ6Ji7001734; Sat, 15 Jun 2013 19:06:19 GMT
Received: from dhcp-amer-vpn-adc-anyconnect-10-154-189-250.vpn.oracle.com (/10.154.189.250) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 15 Jun 2013 12:06:19 -0700
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Hadriel Kaplan <hadriel.kaplan@oracle.com>
In-Reply-To: <4758E6F6-EDA5-4A11-9E94-42C97C03118E@cs.columbia.edu>
Date: Sat, 15 Jun 2013 15:06:18 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <7D713C14-5B28-4BDB-8987-352CA00112EE@oracle.com>
References: <CDDE44D8.D939%york@isoc.org> <4758E6F6-EDA5-4A11-9E94-42C97C03118E@cs.columbia.edu>
To: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Apple Mail (2.1508)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: stir@ietf.org, Dan York <york@isoc.org>
Subject: Re: [stir] current draft charter - ENUM and databases
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Sat, 15 Jun 2013 19:06:35 -0000

On Jun 13, 2013, at 9:12 PM, Henning Schulzrinne <hgs@cs.columbia.edu> wrote:

> Also, I suspect there would be fewer concerns if the DNS-like database mainly referred to other databases, which can then be access-controlled as needed, and can evolve.

But that's just moving the problem around, isn't it?

I mean ultimately some of us might want to actually implement the signing and verification into our systems.  If it uses public-key signatures, then we need a standardized protocol by which our systems can query for a certificate signed by some authority we trust for a given E.164 number.  If DNS tells us "go look over at FOO": then what standardized protocol does FOO use that we need to implement? why should we trust it for this caller-id? and how does it avoid the privacy problems and ownership problems and so on?  How do you even know we can reach FOO, if it's not necessarily publicly reachable?

I mean all I've heard is this: 
Step-1) Some magic happens somewhere, to enable the caller to generate a HTTP URL anyone can use**
Step-2) You get the HTTP URL in SIP from the caller through some chain of providers
Step-3) You send a GET request to above URL
Step-4) Some more magic happens**
Step-5) You get back a magic certificate
Step-6) You trust the magic was real, and use the cert to verify
Step-7) Ta-da! You've now verified the caller-id!
Step-8) Profit.

**note: please contact the universal magician so we can make the magic stuff happen for you and everyone else.


> My general gut feeling is that we don't guess well on how public infrastructure evolves (or doesn't), so allowing for multiple outcomes and abstracting it, as well as allowing for functionality that gets better over time, might be more productive, as this allows for partial success, rather than just "exactly as planned" or "complete failure".

I agree - we (the IETF) don't guess well on those things; we do much better if there's an existing solution we're asked to improve or standardize.  ISTM usually IETF BOFs for new work are more successful if they can point to existing proprietary solutions and say "see, it's possible".  But I don't think we have that for this work, do we?  So I think we have to discuss how such a thing would be possible, to assure ourselves we're not going to be wasting time.


> Also, keeping scale in mind helps: In our case, the scale for "number-holding service providers" is currently a few thousand, not millions, so management solutions that don't scale to millions are acceptable to get started. The backend process today is pretty manual (faxes, web pages and proprietary APIs), so expectations are fairly low.

See, that matches up well with DNS too! The backend management/admin process is pretty manual afaict. ;)

-hadriel