Re: [stir] current draft charter

Hadriel Kaplan <hadriel.kaplan@oracle.com> Thu, 13 June 2013 04:43 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 1F22421E804D for <stir@ietfa.amsl.com>; Wed, 12 Jun 2013 21:43:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.565
X-Spam-Level:
X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.033, 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 1QFxbgWvO0Aw for <stir@ietfa.amsl.com>; Wed, 12 Jun 2013 21:42:54 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9A29611E80BA for <stir@ietf.org>; Wed, 12 Jun 2013 21:42:54 -0700 (PDT)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5D4gl5Z018379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Jun 2013 04:42:48 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 r5D4gmof010372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Jun 2013 04:42:49 GMT
Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5D4gmsV011068; Thu, 13 Jun 2013 04:42:48 GMT
Received: from dhcp-amer-vpn-adc-anyconnect-10-154-151-252.vpn.oracle.com (/10.154.151.252) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 12 Jun 2013 21:42:48 -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: <CDDE3A21.1F6AF%jon.peterson@neustar.biz>
Date: Thu, 13 Jun 2013 00:42:47 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <F76054B1-1FFF-4F44-8E62-CDBD664574E4@oracle.com>
References: <CDDE3A21.1F6AF%jon.peterson@neustar.biz>
To: "Peterson, Jon" <jon.peterson@neustar.biz>
X-Mailer: Apple Mail (2.1508)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "stir@ietf.org" <stir@ietf.org>, Dave Crocker <dcrocker@bbiw.net>
Subject: Re: [stir] current draft charter
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: Thu, 13 Jun 2013 04:43:01 -0000

On Jun 12, 2013, at 6:01 PM, "Peterson, Jon" <jon.peterson@neustar.biz> wrote:

> It's always hard to say with any certainty why something failed. We can
> point to various causes and effects, one of which in this case certainly
> would be the difficulty of getting every world government to implement the
> system. ENUM was also designed from the start to empower end users to
> control how their numbers would be associated with Internet services, yet
> because of its built-in regulatory structures it required that empowerment
> to be driven by carriers with different interests.
> 
> But we don't even have to be asking ourselves about the relevance of
> public ENUM to the proposed work here in STIR unless we want to try to
> base everything on keying in the public DNS for telephone numbers. There
> are other models for this that don't have the liabilities I described
> above, anyway.

The liability you described above for ENUM is the same liability for caller-id: we need the carriers to agree to do this.  We don't need *all* of them to, at least not at the start, but we need a critical mass within at least one country, preferably more than one country.  Convincing just Enterprises to do it is neither necessary nor sufficient.


> Keying in private DNS is more viable, for example. I think
> a PKI is more viable.

In what way is DNS with DNSSEC/DANE *not* a PKI?

-hadriel