Re: [Gen-art] COMPLETE Gen-ART review of draft-ietf-stir-rfc4474bis-14

"Vijay K.Gurbani" <vijay.gurbani@nokia-bell-labs.com> Mon, 06 February 2017 21:05 UTC

Return-Path: <vijay.gurbani@nokia-bell-labs.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7287D1294C0 for <gen-art@ietfa.amsl.com>; Mon, 6 Feb 2017 13:05:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 zngQk_v5ZY52 for <gen-art@ietfa.amsl.com>; Mon, 6 Feb 2017 13:05:40 -0800 (PST)
Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (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 5ADA1129482 for <gen-art@ietf.org>; Mon, 6 Feb 2017 13:05:39 -0800 (PST)
Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id E14CE1FCA91D2; Mon, 6 Feb 2017 21:05:35 +0000 (GMT)
Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id v16L5bx7014924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Feb 2017 21:05:38 GMT
Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id v16L5abE007176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Feb 2017 21:05:37 GMT
Received: from [135.185.238.154] (shoonya.ih.lucent.com [135.185.238.154]) by umail.lucent.com (8.13.8/TPES) with ESMTP id v16L5aFx016688; Mon, 6 Feb 2017 15:05:36 -0600 (CST)
To: "Peterson, Jon" <jon.peterson@neustar.biz>
References: <4a800ae0-b09f-675d-c287-81689b271f4d@nokia-bell-labs.com> <D4786999.1CB19F%jon.peterson@neustar.biz>
From: "Vijay K.Gurbani" <vijay.gurbani@nokia-bell-labs.com>
Message-ID: <dcca6b06-5bb8-6920-17a8-7b25a233bef3@nokia-bell-labs.com>
Date: Mon, 06 Feb 2017 15:05:35 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <D4786999.1CB19F%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/gen-art/x44K69tN9tG7lsUw6REVPEkLNQk>
Cc: General Area Review Team <gen-art@ietf.org>
Subject: Re: [Gen-art] COMPLETE Gen-ART review of draft-ietf-stir-rfc4474bis-14
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Feb 2017 21:05:42 -0000

On 01/24/2017 12:59 PM, Peterson, Jon wrote:
 > Hey Vijay,
 >
 > Took me a bit to get back to you here, sorry. Appreciate the notes.
 > Here's my thoughts.


Jon: No worries.  I must also apologize for the delay in getting back
to you.

More inline (please see to end).  I have re-arranged your comments so
that those we agree on appear at the end.

 >> Major:
 >>
 >> - S7.4 contains requirements for a credential system, and the draft
 >>  assumes that any credential system that works with the draft will
 >>  adhere to the five expectations outlined in the section.
 >>
 >>  My question is how do we ensure that these expectations are met?
 >>  Through IANA?  (But there is no subsection in the IANA registry
 >>  section corresponding to this.)  Through some form of domain expert
 >>  required to review a specification outlining the five expectations?
 >>  It seems to me that since the credential service is an integral part
 >>  of the system, some manner of review by the appropriate working
 >> group (or a designated expert) should take place.
 >
 > I don't think this is an IANA-like thing where failure to comply with
 > these requirements will result in something like a code point
 > overload.  The relevant text in 7.4 says "in order for a credential
 > system to work with this mechanism, its specification must detail"
 > the following points.  If the credential system doesn't do these
 > things, it won't work with the rfc4474bis mechanism.
 >
 > I think this is pretty typical of how requirements language like this
 > fits into our process - we may as part of a WGLC for a document ask
 > if it meets requirements given in a previous RFC, but it's not a
 > designated expert kind of thing. I imagine that any chartered
 > deliverable, say, to do a credential system might be held to that bar
 > - but we don't put text to that effect in RFCs I think.
 >
 > So in short I hear what you're saying but I think this one is fine.

OK; I wanted to at least raise the issue to make sure that it was
subjected to some thought.

 >> - S6.2.2, the 436 response case.  I am a big believer of protocols
 >>  imparting as much error information as they can, especially if the
 >>  protocol is as expressive as SIP.  Since this error code is
 >> repairable, why not provide information to the repairer on exactly
 >> which Identity header was 'bad'.  Something like:
 >>
 >>  436 Bad Identity Info
 >>  Warning: 399 https://biloxi.example.org/biloxi.cert is not
 >>  accessible
 >>
 >>  Or message/sipfrag could be used as well.
 >>
 >>  We do not have to make such debugging/error information propagation
 >>  mandatory (MUST), but we should at least alert the implementers to
 >>  it existence (SHOULD).
 >
 > I know that ATIS has been playing around with some Reason codes for
 > responses to give additional information, especially in provisional
 > responses. I can see the use of this, but I'm not sure at this stage
 > in rfc4474bis's lifecycle I really want to open this up to new
 > functionality along those lines. It seems to me that this could be
 > broken off as a modular chunk of future work.
 >
 > But how about this - I can put in some text to 6.2.2 to the effect
 > that future specifications could look at Warnings or Reason codes as
 > a means to disambiguate the source of errors etc?

Sure; that works for me.  I will defer to you if you feel, as you write
above, that you don't want to open up new functionality at this stage of
rfc4474bis.  But that said, I will appreciate your to-appear text in
S6.2.2.  I think that if protocols have primitives to aid in being
descriptive, then designers should make use of the said primitives.

 >> - S6.2.2, the 437 response case.  Same reasoning as above.  Example:
 >>
 >>  437 Unsupported credential
 >>  Warning: 399 https://biloxi.example.org/biloxi.cert
 >
 > I think a blanket statement about future work at the end of the
 > section could cover it.

OK.

 >> - S3: s/can issue them an identity/issues an identity/
 >
 > I like the original better. The organization could also issue them a
 > telephone number, say, instead of a SIP URI.

I don't think that my suggested change precludes issuance of other
forms of identity.  I think that "issues an identity" reads better
and is less colloquial; but if I cannot convince you (as the editor),
then no worries.  I'll leave it up to you.

That's it.  For the sake of completeness, I list below the changes
agreed upon.  Thanks for your time attending to my comments.

 >
 >>
 >> Minor:
 >>
 >> - S3: "baseline SIP" ==> What do you mean by this?  (I know what you
 >>  mean, of course, but others reading the document may not.)  Perhaps
 >>  the following substitution is better?
 >>
 >>  s/purposes of baseline SIP,/use of SIP as defined in [RFC 3261],/
 >
 > Good catch, done.

 >>
 >> Nits:
 >>
 >> - S1: "However, the recipient of a SIP request has no way to verify
 >>  that the From header field has been populated appropriately, in the
 >>  absence of some sort of cryptographic authentication mechanism."
 >>  Changing the order of the dependent clauses may lead to better
 >>  readability.  That is,
 >>  "However, in the absence of some sort of cryptographic
 >> authentication mechanism, the recipient of a SIP request has no way
 >> to verify that the From header field has been populated
 >> appropriately."
 >
 > Done.

 >> - S1: You may want to define what "swatting" is for those not well-
 >>  versed in ART terminology.
 >
 > The "as described in [RFC7340]" is there for people to read further
 > about those motivations; it does define swatting etc.

 >> - S1: "less spoofable" ... Merriam-Webster does not define
 >> "spoofable" as a word (online version).  Perhaps better to say "less
 >> amenable to spoofing" instead.  Something as the following suggested
 >> text:
 >>  "Ideally, a cryptographic approach to identity can provide a much
 >>  stronger assurance of identity than the Caller ID service used
 >>  by the public-switched telephone network today.  Such an approach
 >>  would also be less amenable to identity spoofing."
 >
 > Um... all right, I guess. Added "... and less vulnerable to spoofing"
 > to the end of the clause.

 >> - S3: s/through means entirely up to the authentication
 >> service,/through per-arranged means with the authentication service,/
 >
 > OK.

 >> - S3: s/credentials that will be trusted by relying parties to sign
 >> for telephone numbers are a key component of the
 >> architecture./credentials that will be trusted by relying parties to
 >> be authoritative for telephone numbers become a key component of the
 >> architecture./
 >
 > I think I like the original text here better.

 >> - S3: s/not so easy to/not as easy to/
 >
 > OK.

 >> - S3: s/ but this document does not mandate or specify a credential
 >>  system.  [I-D.ietf-stir-certificates] describes a credential system
 >>  compatible with this architecture./ but this document does not
 >> mandate or specify a particular credential system;
 >>  [I-D.ietf-stir-certificates] describes one credential system
 >> compatible with this architecture."
 >
 > OK.

 >> - S3 s/This is typically easier to deal with, as these identities are
 >>  issued to users by authorities over Internet domains./This is
 >>  typically easier to deal with as these identities are issued by
 >>  organizations that have authority over Internet domains./
 >
 > OK.

 >> - S3: s/prove in some fashion/proves/
 >
 > OK.

 >> - S6.2, Step 3: "The verifier must ensure that it possesses the
 >> proper keying material to validate the signature...".  Here, I
 >> believe that the verifier must ensure that it *has access to* to the
 >> proper keying material, more than the fact that it "possesses" it.
 >> Namely, the verifier needs to have access to the URI in the "info"
 >> parameter.  Whether or not it caches the certificate (thus making it
 >> "possess" it), is up to the policies of the verifier.
 >>
 >>  Summary: s/possesses/has access to/
 >
 > OK.

 >> - S7.1, first paragraph, first sentence.  With respect to my above
 >>  comment, s/have access to/possess/
 >>
 >>  The Authentication Service must not only have access to, but must
 >>  possess the private keying material.  Possession implies access, but
 >>  access may not imply possession.
 >
 > OK.

 >> - S7.1, second paragaph: s/For non-telephone number user parts/For
 >>  non-telephone number URIs/
 >
 > Um... I think the original is fine? The telephone number is in the
 > user part.
 >
 >>
 >> - S8, s/vet the identity/confirm the identity/
 >
 >
 > OK.


- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Nokia Networks
Email: vkg@bell-labs.com / vijay.gurbani@nokia-bell-labs.com
Web: https://www.bell-labs.com/usr/vijay.gurbani
Calendar: http://goo.gl/x3Ogq