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

Benjamin Kaduk <kaduk@mit.edu> Fri, 20 April 2018 00:31 UTC

Return-Path: <kaduk@mit.edu>
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 039AC12E89A; Thu, 19 Apr 2018 17:31:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 67CcMmK8_LyQ; Thu, 19 Apr 2018 17:31:39 -0700 (PDT)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 9651A126CB6; Thu, 19 Apr 2018 17:31:38 -0700 (PDT)
X-AuditID: 1209190c-155ff70000006461-15-5ad934e8d995
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 13.8D.25697.8E439DA5; Thu, 19 Apr 2018 20:31:37 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w3K0VWrE005283; Thu, 19 Apr 2018 20:31:33 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w3K0VRLn014934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Apr 2018 20:31:30 -0400
Date: Thu, 19 Apr 2018 19:31:27 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: "Das, Subir" <sdas@appcomsci.com>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-stir-rph@ietf.org" <draft-ietf-stir-rph@ietf.org>, Russ Housley <rhousley@vigilsec.com>, "stir-chairs@ietf.org" <stir-chairs@ietf.org>, "stir@ietf.org" <stir@ietf.org>
Message-ID: <20180420003125.GC54168@kduck.kaduk.org>
References: <152410229195.28672.4848182467373812893.idtracker@ietfa.amsl.com> <AAC987F0CC2C7845A9FBD8A36D52E12DCBD4702D@rrc-ats-exmb2.ats.atsinnovate.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <AAC987F0CC2C7845A9FBD8A36D52E12DCBD4702D@rrc-ats-exmb2.ats.atsinnovate.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDKsWRmVeSWpSXmKPExsUixG6nrvvS5GaUwbdvIhaT9nBazPgzkdni +Lq/LBYPb0hbPNuxntVi+dptTA5sHpe/TGTxWLLkJ5PHqjtfWAOYo7hsUlJzMstSi/TtErgy jhy4z17QqFYxc/189gbGFvkuRk4OCQETiYbjJ1i6GLk4hAQWM0lMWPeEEcLZyCgxbdcqNgjn KpPEzP75bCAtLAKqEjfXLGYEsdkEVCQaui8zg9giQPHvE+6DdTMLfGWUuHv1HViDsECYxNOf d1lBbF6gfeeerWSHmDoHaEVPM1RCUOLkzCcsIDazgLrEn3mXgKZyANnSEsv/cUCE5SWat84G W8YpECnRffogmC0qoCyxt+8Q+wRGwVlIJs1CMmkWwqRZSCYtYGRZxSibklulm5uYmVOcmqxb nJyYl5dapGuol5tZopeaUrqJERQJnJI8OxjPvPE6xCjAwajEw/th3Y0oIdbEsuLK3EOMkhxM SqK8xyYDhfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwljLdjBLiTUmsrEotyodJSXOwKInzLtq/ N0pIID2xJDU7NbUgtQgmK8PBoSTBqwiMeCHBotT01Iq0zJwShDQTByfIcB6g4ZeNQYYXFyTm FmemQ+RPMSpKifO+B0kIgCQySvPgekGJSiJ7f80rRnGgV4R5A0FW8ACTHFz3K6DBTECDDVRu gAwuSURISTUwLnPf2iKt8Eru1xehWeHLtrnl3ikWjGE/eilAaMLqlHs3DVif74h84f5sulJd VHgst0fmtSXzZ7+dEG8h3NT2Mil2s8gBl+lvkiuyTl9Ub4z+4Sl+5tIF88tHdOdvVZLe2fBE h+WbkELT8vb5xyob+54o9Af9utPq6CwrYdTUWvVrzrHdDMKrlFiKMxINtZiLihMBpA+5ty8D AAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/0c5LEoGzlrCQrJf-obxaiXfijRs>
Subject: Re: [stir] Benjamin Kaduk's No Objection on draft-ietf-stir-rph-03: (with COMMENT)
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.22
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: <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, 20 Apr 2018 00:31:41 -0000

On Thu, Apr 19, 2018 at 06:16:47PM +0000, Das, Subir wrote:
> Hello Benjamin,
> Thanks for your review and comments. Please see the answers inline. 
> 
> Regards,
> -Subir 
> 
> -----Original Message-----
> From: Benjamin Kaduk <kaduk@mit.edu>; 
> Sent: Wednesday, April 18, 2018 9:45 PM
> To: The IESG <iesg@ietf.org>;
> Cc: draft-ietf-stir-rph@ietf.org; Russ Housley <rhousley@vigilsec.com>;; stir-chairs@ietf.org; rhousley@vigilsec.com; stir@ietf.org
> 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 https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-stir-rph/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 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.
> 
> SD>Thanks. 
> 
> 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. 

Ah, I see.  (I will confess that the "namespace"."priority value"
was the one that confused me the most when I first saw it;
'Resource-Priority' header did not bother me too much.  But there is
no need to change anything just on my personal experience.)

> 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'."

Okay, thanks.

> 
> 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.

Maybe

Using extensions to PASSporT tokens with a "ppt" value of "rph"
requires knowledge of the authentication, authorization, and
reputation of the signer to attest to the identity being asserted,
including validating the digital signature and the associated
certificate chain to a trust anchor, The following considerations
should be recognized when using PASSporT extensions with a "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 proper
authorization.  Before signing tokens, the signer MUST have a secure
method for authentication of the end user or the device being
granted a token.

-Benjamin