Re: [stir] Review of: draft-ietf-stir-rfc4474bis-10

["Gorman, Pierce A [CTO]" <[e-mail]>]

Sorry.  Not responding to Mary’s excellent comments. I didn’t see Jon’s e-mail and don’t want to go look for it, so I’m replying to Jon’s e-mail that Mary was responding to.  (smiley emoticon)

In reading Mary’s remarks I saw that Jon said, “[Dave] pointed out that we really don't have any motivation for including multiple Identity headers in there, and we probably do need an indication of what future work might use that feature.”

It has occurred to me before that multiple signatures might be handy.  Intentionally and illegtimately authenticating spoofed calling numbers is possible.  A proxy which had information about an untrustworthy source might like to add a signature which in effect says, “you can trust the call came from the originator owning the certificate, but you cannot trust that the cert owner used it legitimately”.  It would be a way to preserve the originating authentication information which is useful, but deprecating it too.

I suppose there could be History-Info sorts of applications too.

Pierce

From: Mary Barnes [mailto:[e-mail]]
Sent: August 17, 2016 2:04 PM
To: Peterson, Jon <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [stir] Review of: draft-ietf-stir-rfc4474bis-10

Jon,

Thanks for responding to Dave's comments - I found that quite helpful.  I have some comments/responses below [MB].  As a caveat to my responses, I did not read all the details in Dave's review.

Regards,
Mary.

On Sat, Aug 13, 2016 at 2:40 AM, Peterson, Jon <[e-mail]<mailto:[e-mail]>> wrote:

I finally had a chance to go through these comments, and I did want to
provide a few responses on Dave's review of rfc4474bis here.

>Taken on its own and also when taken with its companion documents, the
>specifications are confusing and incomplete.  It is quite far from being
>ready for publication.

Having looked through Dave's specific concerns, I don't think he makes his
case for this criticism.

>Terminology is used inconsistently. It often is introduced with no
>background or citation.  Many uses of 'header' are probably supposed to
>be 'header field'.  My sense is that quite a bit of terminology is used
>equally loosely.

I think the use of terminology in the specification has proper background
and citations. Certainly Dave is correct that the text is pretty lax with
"header" vs. "header field" vs. "header field value," no denying that. If
people think this is a big deal, I will fix it. But the suggestion that
because this is true, terminology is loosely used to a point where it
would hamper implementation, that I think his comments don't really
substantiate.

[MB] As pendantic as it might seem, in my experience, the expectation is that we are precise with terminology in the specs, so that qualifying 'header' as 'header field' and 'parameter' as 'header field parameter' is a reasonable expectation. I've had to do that with the RFCs that I've authored and in re-reading this document recently, I think it adds to the readability/understanding in particular since the ABNF comes later. [/MB]


>There is no integrative architectural description, so the reader has
>difficulty understanding what all of the pieces are or how they fit
>together.  In fact is appears that the document itself gets confused on
>this matter.

I'm not sure what an "integrative architectural description" would entail,
but there are a number of sections that provide overviews of operations
and related examples of how the architectural piece come together. I don't
think anything in the review comments genuinely substantiates that the
document itself is confused about its own architecture.

>Algorithms are all offered only as prose and often in a form mitigating
>comprehension, such as tending towards negation or disjunction, which
>humans process less well than affirmatives and conjunctions. From what I
>can tell, the algorithms often are incomplete, but serious analysis is
>difficult.

Algorithms are offered in steps with normative language, if that's what
you mean by "prose form". RFCs are typically composed of prose. The review
does reveal some very striking views about specmanship and algorithms in
particular which are foreign to my experience in the IETF.

>The documents appear to rely on a reader's having quite a bit of prior
>knowledge and are certainly not usable by an implementer who is not
>already deeply embedded in the community that produced these
>specifications.  My impression is that being embedded won't suffice
>either, both from my assessment of the documents' deficiencies and given
>back-channel comments I have heard about the expectation of the work to
>be done after these specifications are published.

We do expect basic SIP literacy, and a willingness to follow references
and read external specifications and sections that are cited. Readers that
are unwilling to do this will probably find a lot of things confusing in
there.
[MB]  I think the challenge is that 'basic SIP literacy' isn't such a basic thing anymore and it does require *a lot* of background to parse this document, but I don't know a way around that. [/MB]

>Overall, the writing impedes comprehension and the document needs a very
>diligent pass by a technical editor.  I suspect this will uncover quite
>a number of semantic deficiencies in the text.

You did catch some good typos, and I caught a few more following your
notes through the text. I'm not sure that yielded the semantic
difficulties you speculate about here though.

>There is a possible tendency to support more alternative behavior than
>appropriate. Successful interoperability usually benefits from fewer
>choices, not more.  Common, mandatory canonicalization is an example.

Common, mandatory canonicalization of telephone numbers is unfortunately
only slightly more reliable than common, mandatory normalization of
internationalized domain names. At least it's just numbers. The algorithm
we have is good enough to cover the common operational case, and where it
fails, hopefully "canon" will help to close the gap.

>Credentials: the specification neither defines nor references a standard
>for the specification of credentials, here.  That means that the
>technical details -- as distinct from the operational policies -- of
>credentials are out of scope, although they are fundamental to proper
>operation of this serve.  This is a showstopper, in terms of
>specification completeness for the service.

Well, it does reference a standard for the specification of credentials:
stir-certs. I agree it would be a showstopper if we didn't have the
stir-certs work.

>How is the recipient to know what credential 'standard' is used?  How
>does this ensure interoperability between two participants who have not
>interacted before?

There is in practice only one at the moment. I'm content to worry about
interop problems when we have another one.

>At base, these specifications appear intended to roughly chart out a
>system structure, leaving most of the difficult work for later and
>elsewhere.  By way of example, there are few if any cross-organization
>key management services on the Internet that demonstrate the utility
>needed here.  I am pretty sure that Web certs don't qualify.  We know
>that DKIM's operation does, of course.  However DKIM strictly uses
>domain names as identifiers and they conveniently align with their
>administrative authorities, whereas telephone numbers do not...

I'd say that, by design, rfc4474bis is pretty tightly confined to
specifying the SIP over-the-wire protocol behavior. It takes a lot of spec
just to do that.

And your praise of DKIM as a model is once again noted. I would respond
again that we are unlikely to abandon our years of work on this mechanism
and switch to DKIM at this point, no matter how many comments you place in
our path.

>      [[[ The mailing list just had an extensive regurgitation of
>critical commentary about ENUM.  What appears to be getting missed is
>that whatever mechanism is going to be used for finding and validating
>keys is going to have no operational history of reliability, safety or
>efficacy. ]]]

HTTP has none of those qualities, apparently.

>There is remarkably little of the original RFC 4474 substance still in
>this document.  Calling it a bis is a bit like tearing all of a building
>except its fireplace or its front door and calling that a remodeling.
>The previous document does not have an installed base, so I strongly
>suggest removing all references to it.  It will allow some of the text
>to be notably simpler and clearer.

I think enough of the concepts and protocol mechanisms of the original are
retained to warrant keeping this as a bis.

[MB] I'm not sure on this one, in particular given that it deprecates the header fields defined in RFC 4474 (per section 8).  And, unlike other -bis specs there is no summary section in this document of the differences between the two.  Also, currently this draft doesn't indicate what impact it has on 4474 in the header page. There is the sentence at the end of section 1 stating that this document "revises RFC 4474" but that's not particularly meaningful. Given that when we produced RFC 7044, we obsoleted RFC 4244 despite RFC 7044 being backwards compatible with RFC 4244, I really think that this draft should be documented as obsoleting RFC 4474. [/MB]

>The document is heavy with forward references.  These force the reader
>to stop what they are in the middle of, try to hold that place, and look
>forward to understand what they've just been interrupted from reading.
>As a literary style, forward references create useful tension.  In
>specifications they just interrupt the flow.  The document should be
>reorganization so that integrative text comes /after/ the text
>describing the pieces being integrated.  And opening overview, design
>summary, or the like can give a non-normative description of the
>architecture and the service, so the reader has a basic sense of the big
>picture, before diving into the detail of those to-be-integrated pieces.


Dave does make a number of organizational suggestions about the spec. The
spec has an overview, a design summary, before it gets down to specifying
things. The virtue of the "integrative" approach he describes is however
unclear to me. I think whether you define the auth service behavior first
or define the header syntax first, one of those sections is going to end
up pointing to the other. There wasn't much in his reorg suggestions that
seemed to me like a substantial improvement.
[MB] As another RFC 4244 example, we did find that moving the syntax early in the document in RFC 7044 made it more readable.  From a developer's perspective, I think it's helpful to have the syntax in mind as one reads all the details of the processing.[/MB]

Overall, there are a handful of changes (beyond the typos, which again are
appreciated) I'd make based on the substance of Dave's review. Some of the
suggestions to rename sections seem harmless to me. Like some other people
who come to mind, he would like to see some more precise specification and
examples of how you break off the signature from JWT. He pointed out that
we really don't have any motivation for including multiple Identity
headers in there, and we probably do need an indication of what future
work might use that feature.
[MB] I would 3rd the need for examples.  That has been a usual practice for other RFCs defining new SIP header fields (and header field parameters). [/MB]

In terms of topics for discussion that might warrant the attention of the
working group, he did suggest we need to be sure we think the scope of the
signature is correct, and that we have enough confidence that
intermediaries won't break it, and that when it is broken, the verifier
behavior makes sense. I think we've focused a lot of attention on those
questions, but I'm happy to talk more about that if people think there's
room for improvement.

Also, he suggests that we might need a better pointer than RFC3986 Section
6.2.2 for URI normalization procedures. If anyone (including Dave!) knows
of one, I'd be happy to cite it instead.

Otherwise, I think we've got this covered. Anyone who's interested in
further details can see the attached.

Jon Peterson
Neustar, Inc.


_______________________________________________
stir mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/stir


________________________________

This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.