Re: [stir] Review of: draft-ietf-stir-passport-05

Dave Crocker <dhc@dcrocker.net> Fri, 29 July 2016 23:59 UTC

Return-Path: <dhc@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 E641912D144 for <stir@ietfa.amsl.com>; Fri, 29 Jul 2016 16:59:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Level:
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8CpHOb89Z7A for <stir@ietfa.amsl.com>; Fri, 29 Jul 2016 16:59:38 -0700 (PDT)
Received: from simon.songbird.com (unknown [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A5F612B060 for <stir@ietf.org>; Fri, 29 Jul 2016 16:59:38 -0700 (PDT)
Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id u6U00MNE003665 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 29 Jul 2016 17:00:22 -0700
To: "Peterson, Jon" <jon.peterson@neustar.biz>
References: <07e0eb16-6758-cdf1-c571-1f1ed768e741@dcrocker.net> <D3C152B2.1A69BA%jon.peterson@neustar.biz> <b096b541-c8af-9617-c9d7-5a1beb5230e8@dcrocker.net> <D3C16040.1A6A09%jon.peterson@neustar.biz> <d66d91f0-9ea2-6295-e749-e48ea37b4892@dcrocker.net> <D3C19686.1A6A4E%jon.peterson@neustar.biz>
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Message-ID: <dd60178b-fa24-5099-166c-f8a0093cb668@dcrocker.net>
Date: Fri, 29 Jul 2016 16:59:30 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <D3C19686.1A6A4E%jon.peterson@neustar.biz>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/mBaJ8z-AgNiVKo1Vijmzgt3mNjI>
Cc: IETF STIR Mail List <stir@ietf.org>
Subject: Re: [stir] Review of: draft-ietf-stir-passport-05
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 29 Jul 2016 23:59:40 -0000

Jon,

On 7/29/2016 2:56 PM, Peterson, Jon wrote:
> The only thing JWT has to do with SIP is that JWT can be a container for a
> signed set of metadata and claims that might be useful in preventing
> impersonation in a SIP request. JWT was chosen not because it has any
> exclusive or special applicability to SIP, but instead because it could
> have applicability both to SIP and other protocols.

Sorry to be repetitious but I do not see that case made, discussed or 
agreed to in the working group record.

What I did see was a repeated claim that using JWT was simpler, which I 
suspect is quite simply wrong, if only because it requires more 
mechanism that directly adding the necessary information to a SIP header 
field. (cf, DKIM, of course.)


>> Note that during the wg session in Berlin there was /still/ question
>> about where to put the JWT information.
>
> Kind of. It was a question about the best syntax for transporting only

And there's the rub.  At this stage of the effort, after 3 years of wg 
effort, and given three major drafts in wg Last Call, something as basic 
as how to carry the necessary information for its primary use case is 
not settled yet.  That's quite troubling, both in general and, given the 
importance and urgency of that motivating use case, in particular.


>> The recording of that interim is not accessible and the very terse
>> summary text of the session show nothing about an intervention.
>
> The "intervention" is reflected in the summary text: "Chris Wendt
> introduced the verified token being discussed in the IP-NNI task force."

Sorry to belabor this but how does 'introducing' something equate to "a 
major intervention in the work last fall to the effect that we
need to build more generically for real-time communications rather than
just SIP. We're interested in getting this to work properly with WebRTC..."?


>  We made a decision there to
> try to merge these into the core proposal, as the summary reads "An open
> design team was formed to discuss finding a common way to address the
> signaling."

Ahh, so that's what that was intended to mean.

Except that while the word 'signaling' does show up in the messages at 
that time, it doesn't seem to apply to this point.


> You are absolutely correct that there were no submissions to the STIR
> mailing list immediately following the interim on Friday October 9. Not a
> single related email went out on Saturday the 10th, Sunday the 11th, or
> even Monday October 12th (which, incidentally, was Columbus Day). Then, on
> the 13th, the only mail that went out announced that the Doodle poll for
> the design team had (behind the scenes) resolved, and that its first
> meeting would be that coming Friday, the 16th. The day of that design call
> there were 44 messages sent to the list on related subjects.

So, I think I understand the general idea behind 'claims' in a larger 
context of transactions and reputations.  As a general model for making 
and maybe validating a variety of assertions /about/ an entity, it's 
probably a reasonable approach, although the pragmatics of its 
application at Internet scale are arguably unproven.

However the task of authenticating the proper use of an identifier in a 
field is a rather more constrained requirement.  And there are a number 
of operational examples, which happen not to require a general claims model.

Simply put, the task is to take an identifier, bind it to the object 
that is relevant (such as a SIP Invite), where the binding mechanism 
requires a basic demonstration of 'approval' of the identifier's use, 
from the authority responsible for administering the identifier.  That 
really is all there is to the required semantics.

Things only get complicated when the goal is made more general (which I 
don't see prompted by the working group charter.)


>> Nor do I see anything in the mailing list postings that /do/ show up
>> those several days later.
>
> I can imagine that since I had to annotate even the summary text of the
> interim meeting in order to show how it related to this topic, it might
> not be clear from the threads on encoding, the NNI and so on how they were
> salient to these decisions if you weren't participating in the WG at the
> time. Maybe looking at the design team minutes for Oct 16th would be
> clearer? It at least mentioned JWT explicitly.

I had already looked at those notes.  They didn't help.  There is 
nothing I saw that made this expanded scope obvious, nevermind justified.

>
> https://www.ietf.org/mail-archive/web/stir/current/msg02183.html
>
>> So I've no idea what you meant by "hard upon it."
>
> I understand you feel that progress should have been more immediate to
> justify my characterization.
>
>> Hence your explanation:
>>
>>      "we need to build more generically for real-time communications
>> rather than just SIP."
>>
>> does not seem to reflected in the wg record.
>
> Maybe you'll find the Oct 16th design team minutes clearer on this point.
> Or maybe they too would require more annotation to clarify the subject and
> thinking of the working group after the fact. The discussions that they
> reflect, anyway, were sufficient to drive consensus at the time.

Sorry.  I still don't see any discussion on the list for the specific 
requirement of other uses.  Lots of discussion about delegation -- 
including one suggesting a lack of requirement for a 'nicely engineered, 
convoluted, infinitely extensible, handles all corner cases certificate 
delegation model' -- but not for the expanded scope I am asking after.

So perhaps it was agreed to by the group in the same fashion that was 
apparently going to be expressed for the current draft during the Last 
Call, namely silence.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net