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

["Vijay K.Gurbani" <[e-mail]>]

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: [e-mail] / [e-mail]
Web: https://www.bell-labs.com/usr/vijay.gurbani
Calendar: http://goo.gl/x3Ogq