Re: [stir] Benjamin Kaduk's No Objection on draft-ietf-stir-rph-03: (with COMMENT)

"Das, Subir" <> Thu, 19 April 2018 18:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CFAAC12DA15; Thu, 19 Apr 2018 11:17:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hMo03mzX_Qnf; Thu, 19 Apr 2018 11:17:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3554E12DA28; Thu, 19 Apr 2018 11:16:59 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id EE5DA69512A; Thu, 19 Apr 2018 14:15:03 -0400 (EDT)
X-Virus-Scanned: by SpamTitan at
Received: from (localhost []) by (Postfix) with ESMTP id 91641695123; Thu, 19 Apr 2018 14:15:03 -0400 (EDT)
Received: from ( []) by (Postfix) with ESMTPS id 74475695120; Thu, 19 Apr 2018 14:15:03 -0400 (EDT)
Received: from ( []) by (8.14.4/8.13.4) with ESMTP id w3JIGv2J023164; Thu, 19 Apr 2018 14:16:57 -0400
Received: from ([2002:c004:56a::c004:56a]) by ([fe80::fc05:b53:7f2b:84f9%18]) with mapi id 14.03.0389.001; Thu, 19 Apr 2018 14:16:57 -0400
From: "Das, Subir" <>
To: Benjamin Kaduk <>, The IESG <>
CC: "" <>, "Russ Housley" <>, "" <>, "" <>, "" <>
Thread-Topic: Benjamin Kaduk's No Objection on draft-ietf-stir-rph-03: (with COMMENT)
Thread-Index: AQHT14AKPiOjJFWsR0e2KEqxePTvUaQIWPCg
Date: Thu, 19 Apr 2018 18:16:47 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [stir] Benjamin Kaduk's No Objection on draft-ietf-stir-rph-03: (with COMMENT)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Secure Telephone Identity Revisited <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Apr 2018 18:17:03 -0000

Hello Benjamin,
Thanks for your review and comments. Please see the answers inline. 


-----Original Message-----
From: Benjamin Kaduk <> 
Sent: Wednesday, April 18, 2018 9:45 PM
To: The IESG <>
Cc:; Russ Housley <>om>;;;
Subject: Benjamin Kaduk's No Objection on draft-ietf-stir-rph-03: (with COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-stir-rph-03: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

Please refer to
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


I support Ben's discuss.

Thank you for working with the secdir reviewer to address those comments; I think it will really improve the document.


In a similar vein, I wonder if this document would be easier to read if it used less formal description terms for protocol elements that are currently referred to by using the actual protocol element (with quotes around the name).  For example, "SIP resource priority header" instead of "'Resource-Priority' header field", or "priority indicator" instead of "'namespace"."priority value"'.

SD> We can update like this but earlier recommendation was to be consistent with RFC 4412 and we followed that. 

I'm a little confused why the new registry created in Section 6.2 is tied to the "resource priority header" (rph) name, when the discussion in Section 5 has some potential envisioned use cases that are broader than resource priority.

SD> . You are correct that Section 5 leaves the possibility of adding new value but when defined, this will be a new  type and will be registered under the same ppt value 'rph'.   For use cases other than resource priority, a new 'ppt' needs to be defined.   We will make it clear in Section 5, 1st paragraph last sentence as follows:

" The specification of the "rph" claim could entail the optional presence of one or more such additional information fields applicable to 'Resource Priority'."

As Ben notes, there are some stale references.  Please double-check the referred section numbers as well; in particular "Section 10.1 of [4474bis]" does not exist in the only February-2017 verions of that draft.

Section 7.2 uses "authority" in a couple of different senses; it might be easier on the reader to refer to the authority (protocol
participant) as being "authoritative for the content of [stuff] that it signs".

SD>  How about the following? 

The use of extension to PASSporT tokens with "ppt" value "rph" based on the validation of the digital signature and the associated certificate requires consideration of the authentication, authorization, and  reputation of the signer to attest to the identity being asserted. The following considerations should be recognized when using PASSporT extension with "ppt" value of "rph":

o A signer is only allowed to sign the content of a 'SIP Resource-Priority’ header field for which it has the right authority.  The signer  that signs the token MUST have a secure method for authentication of the end user or the device.