Re: [stir] current draft charter
Brian Rosen <br@brianrosen.net> Thu, 13 June 2013 16:52 UTC
Return-Path: <br@brianrosen.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 3DA3521F99C1 for <stir@ietfa.amsl.com>; Thu, 13 Jun 2013 09:52:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.395
X-Spam-Level:
X-Spam-Status: No, score=-100.395 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
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 sgg9ZPeIfID1 for <stir@ietfa.amsl.com>; Thu, 13 Jun 2013 09:52:16 -0700 (PDT)
Received: from mm2.idig.net (unknown [70.33.247.98]) by ietfa.amsl.com (Postfix) with ESMTP id 0421821F963C for <stir@ietf.org>; Thu, 13 Jun 2013 09:52:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brianrosen.net; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=mN+uKXwGSg8As/pKvpnAn12zg+s6NbFzAesqMDN7cfo=; b=isL8C4t5ehdLPoQoT9OhUuXZP7AZfHsR9C/5BOdMx/FC2fv1su9ucEJuNQyw/AQraeHo/xey2gi25V4HRRBmEjE8WRXCt0+/j+YhBbuPzkm/kYOFAPVNPpO3zfNdOqLHzAY3QHy9jc1A/cNKrmdgLPxnfU1V3PQTeFNN9k+xZ1o=;
Received: from neustargw.va.neustar.com ([209.173.53.233]:42693 helo=[10.33.193.6]) by mm2.idig.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from <br@brianrosen.net>) id 1UnAkW-0003R6-Ms; Thu, 13 Jun 2013 12:51:49 -0400
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Brian Rosen <br@brianrosen.net>
In-Reply-To: <02cf01ce6854$8ab396d0$a01ac470$@shockey.us>
Date: Thu, 13 Jun 2013 12:51:46 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <246D5AB0-138A-4663-9DD1-01CE79F7FB0D@brianrosen.net>
References: <CDDF354D.DD9A%york@isoc.org> <1E0475FDD84F0C42A9F46570BB946FD94121FCFA@PACDCEXMB01.cable.comcast.com> <BEBF7B2F-997E-4428-B6CE-2F77B5F910E4@brianrosen.net> <02cf01ce6854$8ab396d0$a01ac470$@shockey.us>
To: Richard Shockey <richard@shockey.us>
X-Mailer: Apple Mail (2.1503)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - mm2.idig.net
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Get-Message-Sender-Via: mm2.idig.net: authenticated_id: br@brianrosen.net
Cc: "'Wendt, Chris'" <Chris_Wendt@cable.comcast.com>, 'Dan York' <york@isoc.org>, "'Peterson, Jon'" <jon.peterson@neustar.biz>, 'Hadriel Kaplan' <hadriel.kaplan@oracle.com>, stir@ietf.org, 'Dave Crocker' <dcrocker@bbiw.net>, 'Stephen Farrell' <stephen.farrell@cs.tcd.ie>, 'Henning Schulzrinne' <hgs@cs.columbia.edu>
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 16:52:25 -0000
This particular effort is aimed at trying to do something about robocalling, vishing and swatting in a relatively short time frame. To many of us, that seems doable. Re-doing how routing of telephone number based identities work is the charter of TERQ. It probably can't be done relatively quickly, no matter what mechanisms are used. Restricting charter is a time-honored way of getting stuff done. I'll take that path without any qualms. I'm not interested in re-doing routing of telephone number identities as part of this work. The point of asserting that it takes someone like Neustar to handle a database like what is being described is that a DNS based tree doesn't map into the way number delegation works - so the entire tree has to be handled by one entity - you can't delegate part of it to someone else, especially when porting is considered. I was trying to contrast that with the model I've described where cert delegation follows number delegation. That doesn't require a monolithic database. Brian On Jun 13, 2013, at 12:39 PM, Richard Shockey <richard@shockey.us> wrote: > > > -----Original Message----- > From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of > Brian Rosen > Sent: Thursday, June 13, 2013 10:08 AM > To: Wendt, Chris > Cc: Dan York; Peterson, Jon; Hadriel Kaplan; stir@ietf.org; Dave Crocker; > Henning Schulzrinne; Stephen Farrell > Subject: Re: [stir] current draft charter > > The IETF is starting a new effort on routing, see the TERQ work. If you > have ideas on routing, that would be the place to bring them. > [RS> ] > [RS> ] Wait a second.. You are demonstrating a profound misunderstanding of > what a service provider has in place or are capable of actually implementing > within a reasonable time frame. It is not utterly unreasonable to at least > consider that the issues of number resolution for TN Source Authentication > or Routing would be somewhat similar. There is infrastructure and > technology in place. Dismissing that question out of hand is absurd. > Frankly the way the IETF works these days the chances of TERQ actually > deploying before the End of Ages is debatable. You know the timelines as > well as anyone ... 4 years for a RFC then 2 years for it to show up on > carrier requirements, regression testing .. vendor selection. Get a grip. > > > I think the problem we have here is trying to decide who is a "good guy". > Most of the service providers who would would call "pink" in this context > would claim they are good guys. Trying to create a mechanism to separate > good guys from bad guys is very hard. > > I'm not sure why protecting TNs individually is more complex then the view > you have of routing, especially because we have tried what you are > suggesting, although we did not have DNSSEC. Dealing with the privacy > issues, just to start, would be the first real barrier. > > Let's say we got beyond that. We then need someone, probably someone like > Neustar, to maintain a per country portion of the database. How would it do > that? > > [RS> ] OH PLEASE.. I love a good global domination strategy as much as the > next red blooded capitalist but these endless references to ..."somelike > NeuStar" are becoming tedious and inappropriate. > > > Basically, every time a number was delegated, it would change the domain of > the entry to reflect the delegation. That could work. What it means is > that delegation of any kind has to be recorded in the new database. If you > note, certs follow delegation, with you inserting "domain" in the middle > (domain follows delegation). The twist is that instead of a 2nd level > reseller issuing a cert to a 3rd level reseller, the 2nd level reseller goes > to the new database and has them effectively do the same thing. > > Having databases that associate a domain with a TN might help things like > finding a cert, but it doesn't affect the basic issue of how you avoid > spoofing. Do you think the approach we have suggested here (signing of > From/To/Time/Session Id) with a cert traceable to the identity is > appropriate? > > If you are "simply" suggesting the cert is located via DANE in the domain of > the caller, then for user@domain, I think we're probably saying the same > thing. Where we seem to differ is that you suggest we have a DNS entry for > the TN that has the domain in it, and then you use that to find the cert > used for signing. In the basic case, we're suggesting a URI to the cert in > the signaling, which seems simpler. What matters however is how the DNS > tree for the TNs is maintained. > > So, my response is the same as I have given before: the privacy and > operational issues of putting per TN information in the public DNS are > overwhelming. We have tried it, and it has failed. > > Unlike Hadriel, you really do want to disclose domain with TN. That has > been a non-starter for many carriers. > > Brian > > > On Jun 13, 2013, at 9:37 AM, "Wendt, Chris" <Chris_Wendt@cable.comcast.com> > wrote: > >> Hi Folks, >> >> I believe it couldn't be a better time to start discussing public routing. > While this is a little beyond the scope of protecting caller-id, I think the > effort is highly complimentary, and solving both together will provide a > better path to get things implemented in service provider networks. >> >> IP communications is evolving whether you want to get on the train or not. > I applaud Henning's efforts to push the ball forward. >> >> Moving more to an internet model for routing is inevitable, IMHO. There > is questions about how relevant TN is or will be in the near future. For > the sake of having any chance of success, let's simplify the effort and > focus on the future. There will be a transition process to get there, no > doubt, but let's focus on the end goal, and not focus on fixing problems of > the past. We are already in a world of multiple private peering > arrangements, LCR, and managing multiple egress points anyway, so the > transition should not be that difficult. >> >> I believe a common routing mechanism for both user@domain and TN/e164 > based identities should be the focus. Treat both as first class citizens > for IP communications. >> >> Use DNS and domain based routing for all. Use DNSEC to validate and > cryptographically associate TN/caller-id with a domain (for good guys) and > do domain routing from there. >> Forget about trying to protect TN's individually, that is too complex. >> >> It's up to the consumer service providers to enforce and block bad things > from bad domains. >> It's up to wholesale/trunking providers to allow customers to assert their > own domain, or be responsible for asserting domains on their behalf at the > risk of being considered a "bad guy". >> >> This is high level, and perhaps a sunny day view of the world, but I don't > think unrealistic. Frankly, if there is any chance of a common federated > communications system continuing to be relevant, I believe a simple approach > that matches the internet model is the only choice. >> >> You should see more concrete opinions from Comcast in the future, but I > wanted to take the opportunity to express these thoughts and would love > feedback on why this should or should not be the model going forward. >> >> If there is agreement, I believe some of this should be addressed in the > charter, because I think some of the assumptions may not enable this path. >> >> -Chris >> >> >> >> >> On Jun 13, 2013, at 8:51 AM, Dan York <york@isoc.org> wrote: >> >>> Hadriel, >>> >>> On 6/12/13 5:38 PM, "Hadriel Kaplan" <hadriel.kaplan@oracle.com> wrote: >>> >>>> That begs the question of what issues you think made Public ENUM >>>> fail, and why we won't hit the same issues in whatever model we choose. >>> >>> Since you addressed this question to me, I feel compelled to >>> answer... but in the meantime both Brian and Jon have given much more >>> detailed answers with which I mostly agree. >>> >>> I saw security/privacy issues as the main issues that made Public >>> ENUM not work, i.e. Brian's points 4, 5 and 6: >>> >>>> 4. Any public database that was able to show any information about a >>>> telephone number was considered a privacy issue, requiring a lot of >>>> "sign off", which never happened. >>>> 5. Everyone objected to being able to determine what numbers were "live" >>>> 6. Carriers objected to a public database that told competitors what >>>> numbers they controlled >>> >>> >>> The potential for spam was also high. Five or six years ago there >>> was at least one tool circulating around that would walk an ENUM >>> tree, generate a list of all potential phone numbers and then send >>> SIP INVITEs to all of those numbers. I remember either seeing a >>> video or reading about how someone did this with all the public ENUM >>> numbers published for Germany (at that time). So using Public ENUM >>> could be a fantastic way to potentially get yourself on the calling lists > for telemarketers. >>> >>> Ideally, I think a public service *would* be a useful way to enable >>> ubiquitous usage. I'm just not sure how to get there without also >>> opening a solution up to these same kind of security/privacy issues. >>> >>> Dan >>> >>> -- >>> Dan York >>> Senior Content Strategist, Internet Society >>> york@isoc.org <mailto:york@isoc.org> +1-802-735-1624 >>> Jabber: york@jabber.isoc.org <mailto:york@jabber.isoc.org> >>> Skype: danyork http://twitter.com/danyork >>> >>> http://www.internetsociety.org/deploy360/ >>> >>> _______________________________________________ >>> stir mailing list >>> stir@ietf.org >>> https://www.ietf.org/mailman/listinfo/stir >> >> _______________________________________________ >> stir mailing list >> stir@ietf.org >> https://www.ietf.org/mailman/listinfo/stir > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir >
- [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter Stephen Farrell
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter philippe.fouquart
- Re: [stir] current draft charter Wilhelm Wimmreuter
- Re: [stir] current draft charter Stephen Farrell
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter Henning Schulzrinne
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter Dan York
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter Brian Rosen
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter Dan York
- Re: [stir] current draft charter Wendt, Chris
- Re: [stir] current draft charter Brian Rosen
- Re: [stir] current draft charter - ENUM and datab… Richard Shockey
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter Wendt, Chris
- Re: [stir] current draft charter Richard Shockey
- Re: [stir] current draft charter Brian Rosen
- Re: [stir] current draft charter Richard Shockey
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter Richard Shockey
- Re: [stir] current draft charter Brian Rosen
- Re: [stir] current draft charter Richard Shockey
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter - ENUM and datab… Henning Schulzrinne
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter - ENUM and datab… Hadriel Kaplan
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter DOLLY, MARTIN C
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter - ENUM and datab… Henning Schulzrinne
- Re: [stir] current draft charter Henning Schulzrinne
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter DOLLY, MARTIN C
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter DOLLY, MARTIN C
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter - ENUM and datab… Hadriel Kaplan
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter - ENUM and datab… Peterson, Jon
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter - ENUM and datab… Henning Schulzrinne
- Re: [stir] current draft charter Henning Schulzrinne
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter Michael Hammer
- Re: [stir] current draft charter Richard Shockey
- Re: [stir] current draft charter Richard Shockey
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter Dave Crocker
- [stir] Nature vs. nurture -- semantics vs. encodi… Dave Crocker
- Re: [stir] current draft charter Dan York
- Re: [stir] current draft charter Michael Hammer
- Re: [stir] current draft charter - ENUM and datab… Hadriel Kaplan
- [stir] Not just "called party" - Re: current draf… Dan York
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] current draft charter Michael Hammer
- Re: [stir] current draft charter Peterson, Jon
- Re: [stir] Not just "called party" - Re: current … Michael Hammer
- Re: [stir] current draft charter - ENUM and datab… Richard Shockey
- Re: [stir] current draft charter DOLLY, MARTIN C
- Re: [stir] current draft charter Michael Hammer
- Re: [stir] current draft charter - ENUM and datab… Hadriel Kaplan
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] Not just "called party" - Re: current … Peterson, Jon
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter - ENUM and datab… Peterson, Jon
- Re: [stir] current draft charter - ENUM and datab… Michael Hammer
- Re: [stir] Not just "called party" - Re: current … Hadriel Kaplan
- Re: [stir] current draft charter Dan York
- Re: [stir] current draft charter Michael Hammer
- Re: [stir] current draft charter Paul Kyzivat
- Re: [stir] Not just "called party" - Re: current … Dan York
- Re: [stir] current draft charter - ENUM and datab… Hadriel Kaplan
- Re: [stir] current draft charter - ENUM and datab… Richard Shockey
- Re: [stir] current draft charter Hadriel Kaplan
- Re: [stir] current draft charter - ENUM and datab… Peterson, Jon
- Re: [stir] Not just "called party" - Re: current … Henning Schulzrinne
- Re: [stir] current draft charter - ENUM and datab… Henning Schulzrinne
- Re: [stir] current draft charter - ENUM and datab… Henning Schulzrinne
- Re: [stir] current draft charter Henning Schulzrinne
- Re: [stir] current draft charter - ENUM and datab… Henning Schulzrinne
- Re: [stir] current draft charter philippe.fouquart
- Re: [stir] current draft charter - ENUM and datab… Richard Shockey
- Re: [stir] current draft charter Richard Shockey
- Re: [stir] current draft charter Dave Crocker
- Re: [stir] current draft charter Michael Hammer
- Re: [stir] current draft charter Richard Barnes
- Re: [stir] current draft charter - ENUM and datab… Dave Crocker
- Re: [stir] current draft charter philippe.fouquart
- Re: [stir] current draft charter philippe.fouquart
- Re: [stir] current draft charter - ENUM and datab… Hadriel Kaplan
- Re: [stir] current draft charter - ENUM and datab… Brian Rosen
- Re: [stir] current draft charter - ENUM and datab… Wendt, Chris
- Re: [stir] current draft charter - ENUM and datab… Michael Hammer
- Re: [stir] current draft charter - ENUM and datab… Hadriel Kaplan
- Re: [stir] current draft charter - ENUM and datab… Peterson, Jon
- Re: [stir] current draft charter - ENUM and datab… Dave Crocker
- Re: [stir] current draft charter - ENUM and datab… Richard Shockey
- Re: [stir] current draft charter - ENUM and datab… Peterson, Jon
- Re: [stir] current draft charter - ENUM and datab… Henning Schulzrinne
- Re: [stir] current draft charter - ENUM and datab… Lee, Yiu
- Re: [stir] current draft charter - ENUM and datab… Michael Hammer
- Re: [stir] current draft charter - ENUM and datab… Dave Crocker
- Re: [stir] current draft charter - ENUM and datab… Lee, Yiu
- Re: [stir] current draft charter - ENUM and datab… Hadriel Kaplan
- Re: [stir] current draft charter - ENUM and datab… Lee, Yiu
- Re: [stir] current draft charter - ENUM and datab… Hadriel Kaplan
- Re: [stir] current draft charter - ENUM and datab… Wendt, Chris
- Re: [stir] current draft charter - ENUM and datab… Peterson, Jon
- Re: [stir] current draft charter - ENUM and datab… Lee, Yiu
- Re: [stir] current draft charter Wilhelm Wimmreuter