Re: [stir] current draft charter
"Richard Shockey" <richard@shockey.us> Thu, 13 June 2013 17:51 UTC
Return-Path: <richard@shockey.us>
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 9833521F9A0C for <stir@ietfa.amsl.com>; Thu, 13 Jun 2013 10:51:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.988
X-Spam-Level:
X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 pSgkLIK2DE5M for <stir@ietfa.amsl.com>; Thu, 13 Jun 2013 10:51:25 -0700 (PDT)
Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 16F5C21F99F7 for <stir@ietf.org>; Thu, 13 Jun 2013 10:51:25 -0700 (PDT)
Received: (qmail 9153 invoked by uid 0); 13 Jun 2013 17:49:38 -0000
Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy6.bluehost.com with SMTP; 13 Jun 2013 17:49:38 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=SvEEMjRXELV3vrxzl4/kn/53yyMsGeFW4YwVP+SljEc=; b=J0HkD14SvfN4Bp32b2xAIbEvFUFVh5STXYP8+B/Qv622VmAmQmIHnTAUxy+6wtw9dTxGnsvFuiwLGH2VfStWMpA29ISylLLVH4qz8MHFeT3K4L0yJQZiLuG7tAzF8xXo;
Received: from [72.66.111.124] (port=52063 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from <richard@shockey.us>) id 1UnBeU-00043n-0F for stir@ietf.org; Thu, 13 Jun 2013 11:49:38 -0600
From: Richard Shockey <richard@shockey.us>
To: stir@ietf.org
References: <CDDF354D.DD9A%york@isoc.org> <1E0475FDD84F0C42A9F46570BB946FD94121FCFA@PACDCEXMB01.cable.comcast.com> <BEBF7B2F-997E-4428-B6CE-2F77B5F910E4@brianrosen.net> <02cf01ce6854$8ab396d0$a01ac470$@shockey.us> <246D5AB0-138A-4663-9DD1-01CE79F7FB0D@brianrosen.net>
In-Reply-To: <246D5AB0-138A-4663-9DD1-01CE79F7FB0D@brianrosen.net>
Date: Thu, 13 Jun 2013 13:49:34 -0400
Message-ID: <002c01ce685e$5e6f9ab0$1b4ed010$@shockey.us>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQHurB+rPvBwdWSMpuU+7zbFbFufQwKXAQNEAepiKvIBXaTXRAGgx24rmLdggrA=
Content-Language: en-us
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 72.66.111.124 authed with richard@shockey.us}
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 17:51:30 -0000
-----Original Message----- From: stir-bounces@ietf.org [mailto:stir-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Thursday, June 13, 2013 12:52 PM To: Richard Shockey Cc: 'Wendt, Chris'; 'Dan York'; 'Peterson, Jon'; 'Hadriel Kaplan'; stir@ietf.org; 'Dave Crocker'; 'Stephen Farrell'; 'Henning Schulzrinne' Subject: Re: [stir] current draft charter 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. [RS> ] I agree. No argument there. 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. [RS> ] [RS> ] <sigh> but the practical issues of deployment are and that still is related which to what Chris and certainly Penn will constantly point out. What are the optimal structures for the databases and query mechanisms that do not necessarily require a 3 -7 year product cycle. That may actually be the national numbering databases where they exist. Focusing on one or two national use cases is in fact useful and as Penn correctly points out some LOST like structure over time could work for internationalizing the system. One thing would help is more data. It would be nice to hear from the Dutch COIN people, for instance since the structure of their LNP DB closely follows that of North American real time models. So is Ireland and ComReg I haven't monitored that stuff in years. 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. [RS> ] [RS> ] You are really going to have to re explain that what you mean ENUM like delegation does not map into number delegation. Granted that having dealt with ENUM for as many years as I have may have totally dulled my synapses but you need to walk through that more carefully. Ok so walk me through how the Canadian NANP will be separated from the US NANP and individual Public Safety numbers will the separated from both. 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 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