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

"Vijay K.Gurbani" <> Mon, 06 February 2017 21:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7287D1294C0 for <>; Mon, 6 Feb 2017 13:05:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.901
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zngQk_v5ZY52 for <>; Mon, 6 Feb 2017 13:05:40 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5ADA1129482 for <>; Mon, 6 Feb 2017 13:05:39 -0800 (PST)
Received: from (unknown []) by Websense Email Security Gateway with ESMTPS id E14CE1FCA91D2; Mon, 6 Feb 2017 21:05:35 +0000 (GMT)
Received: from ( []) by (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 ( []) by (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 [] ( []) by (8.13.8/TPES) with ESMTP id v16L5aFx016688; Mon, 6 Feb 2017 15:05:36 -0600 (CST)
To: "Peterson, Jon" <>
References: <> <>
From: "Vijay K.Gurbani" <>
Message-ID: <>
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: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc: General Area Review Team <>
Subject: Re: [Gen-art] COMPLETE Gen-ART review of draft-ietf-stir-rfc4474bis-14
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 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
 > I think a blanket statement about future work at the end of the
 > section could cover it.


 >> - 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: /