Re: [stir] current draft charter

Dave Crocker <dhc2@dcrocker.net> Thu, 13 June 2013 22:24 UTC

Return-Path: <dhc2@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 DDFC021F9B1C for <stir@ietfa.amsl.com>; Thu, 13 Jun 2013 15:24:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 J83LtCfnfWr8 for <stir@ietfa.amsl.com>; Thu, 13 Jun 2013 15:24:26 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id EB62621F8B21 for <stir@ietf.org>; Thu, 13 Jun 2013 15:24:26 -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 r5DMONCo003265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 13 Jun 2013 15:24:26 -0700
Message-ID: <51BA468F.5020105@dcrocker.net>
Date: Thu, 13 Jun 2013 15:24:15 -0700
From: Dave Crocker <dhc2@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: <CDDF4CE7.1F7EE%jon.peterson@neustar.biz>
In-Reply-To: <CDDF4CE7.1F7EE%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]); Thu, 13 Jun 2013 15:24:26 -0700 (PDT)
Cc: "stir@ietf.org" <stir@ietf.org>
Subject: Re: [stir] current draft charter
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: Thu, 13 Jun 2013 22:24:32 -0000

Jon, et al,


On 6/13/2013 10:25 AM, Peterson, Jon wrote:
> On 6/12/13 9:01 PM, "Dave Crocker" <dhc2@dcrocker.net> wrote:
>
>> On 6/12/2013 3:01 PM, Peterson, Jon wrote:
>>> 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. Keying in private DNS is more viable, for example. I
>>> think
>>> a PKI is more viable.
>>
>>
>> Other models?
>
> I just meant for example private DNS, or PKI, as it says up there.

1. The functional description that's been offered said that validation 
is to be permitted by entities such as callee-side enterprises and even 
callee UAs.  That precludes any sort of private service.  Whatever 
parameters must be obtained outside of the SIP headers -- such as public 
keys -- they need to be publicly accessible.

2. From one of your earlier notes, I gather that by "PKI" you mean the 
bushy (multi-root) system that operates for SSL/TLS web services?  You 
appear to be using PKI to mean a specific, integrated, operating 
credential service, so I would like to be clear about which specific one 
you mean; the one used by the Web seems to be it?


>> Is there a written description of the integrated query service that you
>> folks are considering, in terms of design, administration and operation?
>
> I wasn't talking about some kind of integrated query service, I was
> talking about where the keys should live. So, written descriptions would
> be CP/CPS sorts of things, if that's what you mean here?

I suspect you mean more than where they live, since they aren't much use 
if they can't be retrieved, and in fact retrieved publicly.

By "query service" I meant the term generically as a mechanism that 
askes for something and gets it. I didn't want to imply or constrain any 
details about the form of the request or what was returned; merely that 
it's in the service of performing validation.

Since the intent here is to develop a global validation service for 
SIP-based calls and since such a service will need to obtain some types 
of information to permit validation, it will need a mechanism for 
retrieving whatever that information is.  That's all I meant by query 
service.

While yes, one can imagine designing a service that permits packaging 
everything in-line with the SIP data, it's clear that that won't be 
sufficient, based on one or more of the documents -- and much of the 
message postings -- for this topic.  Hence, it needs a query service of 
some sort.


>> It would help to also hear where such a design has already been
>> successfully deployed.
>
> Do you think that is an issue for CAs/PKIs? Certainly they have some rough

The PKI service used for the web has the advantage of existing and being 
heavily used.  A base of experience is goodness, when considering 
out-sourcing a component of a new service.  Whether its characteristics 
suffice for the current project, I don't know.  Some times, rough edges 
cut thing and bleed them dry.


> edges, which is why we see the DNS (through DANE) potentially playing a

Ah yes, the great promise of DANE.  I'm sure it will yet deliver, as 
have all of the other promising efforts in the IETF.  Oh, no, this one 
really will.  No, honest, it will.  And I hope I'm serious.

That's not a criticism of DANE.  It's an attempt to raise a flag about 
relying on it.

One of the classic errors in a new project is creating a critical 
dependency on a parallel, independent project.  Sometimes it's 
necessary, but it's always extremely risky.  Extremely.  Always.


> role in their future. Or maybe it will be more like the SSL Observatory or

The 'maybe' -- and equivalent phrasings that you've used -- point up 
something that I've become confused about.  What I was told (rather 
forcefully offline) is that there is a solution already formulated. 
However what's been put forward on the list so far sounds more like some 
ideas, at least some of which are not yet close to being solid.

If there is in fact a concrete, detailed design already in hand, that 
attends to relevant security, privacy, scaling, deployment, 
administration and operations issues, let's hear it.

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net