Re: [stir] WG LC Comments: draft-ietf-stir-passport-divert-05

["Peterson, Jon" <[e-mail]>]

Thanks for notes Eric. Some responses inline:
    
    Section 4.1:
    Is there a scenario where the terminating verification service WOULD NOT do verification? There’s a bunch of text on how the diverting platform might or might not do verification and the terminating platform might or might not do verification.
    
    Would it not be better to point out the diverting platform would really, really, really (SHOULD?) want to verify the inbound call, because it will be the reputation of the diverting platform on the line if it signs the diversion on a bad call?

<Jon>I think SHOULD (as is there now, in the second sentence of 4.1) is the right level of arm-twisting there; we do say the scenario in which you would not want to do it is something very high-volume. I don't think it’s the reputation of the diverting platform that is on the line if the original PASSporT isn't valid - it's the creator of the original PASSporT, which is still in the INVITE, after all.</Jon>
    
    Conversely, why would any terminating provider EVER trust a diversion from a PBX? I.e., would not a terminating provider really, really, really (SHOULD?) want to verify all of the signatures in the chain?

<Jon>Here in the IETF, anyway, we're not in the business of telling you who you should trust or why. If someone signs a "div" PASSporT with a cert you trust, you can trust it, and if it gets signed with a cert you don't trust, don't trust it.</Jon>
    
    Towards the end of 4.1 we talk about RPH. Is there any issue of forwarding an RPH call? One would think that once a priority call hits a PBX, it will lose its priority. I am not stating a fact that I know, but for those in the RPH world, what is your understanding? Also, this paragraph is dense and a bit confusing. An example would go a long way in providing clarity.
    
<Jon>I'm just using RPH as an example of something that might have its own Identity header; I could have used "rcd" instead. I also don't really know how likely it is that a call using RPH would ever get retargeted, but it doesn't seem outside the realm of possibility. I'd be happy to swap this out for some other PASSporT extension if it seems especially confusing.</Jon>
    
    Section 4.2:
    Why would a failure in the verification chain EVER result in anything other than a failed verification, other than the obvious, “the certificate expired three minutes ago”? Remember, MAY = Never Will Happen.

<Jon>That would be in the case where the chain isn't the only thing you can validate in the INVITE. Even in a non-div case, if there are 5 Identity headers, and four of them don't validate for you, but the fifth does, you can trust the fifth. The mere presence of in an INVITE of something that you can't validate doesn't mean verification fails.</Jon>
    
    Section 4.2, Fifth step
    What is a “multiple based PASSporTs”?
    
<Jon>A typo for "multiple base PASSporTs". Will fix, probably with "innermost."</Jon>

    Section 5:
    As Ben pointed out in his review, div-o seems to be a different beast that might better be addressed in a separate document. In fact, if the only purpose of it is to support OOB, I would insist it go into a separate document. Conversely, if div-o will be the mechanism to support TN-PoP, then say so. Of course, if that is what div-o is about, again perhaps it would be better served in a separate document or as part of the eventual mechanism that allows the originating caller to sign a call (classic STIR) as well as an authentication service signing the call (SHAKEN).
    
<Jon>Ben was talking about "opt" I think, not "div-o". I think "div-o" is a similar enough beast that it belongs here, because it is used for diversion and uses the diversion authentication and verification service behaviors described here and this is the diversion draft. The nested "div-o" mechanism is explicitly marked as being for non-SIP conveyance, so it don't think the document is unclear about why it is there. Your insistence about removing it is noted, but if I recall about a year ago you were the one insisting that the entire mechanism use nested, which I had to patch in, and then later undo. I don't think there is any practical justification for doing more busywork along those lines.</Jon>

    Section 7:
    Why would we EVER allow a caller to pickup a signature from a 302 redirecting server? The text goes to great lengths to explain *how* to do it, but never says *why*. I’m having trouble groking the use case. A spammer sends INVITEs to a number, gets back a (set of) signed PASSporTs to include in their spam calls? Why would I ever care if the spammer found my current contact from a redirect from a registrar instead of guessing my current contact directly? Is there a double-secret use case hiding here?

<Jon>I don’t understand what attack you believe exists here. I don't think there's any practical security difference (in the STIR threat model) between inserting a "div" PASSporT in an INVITE as you retarget and forward it versus sending a 302 in the backwards direction with the "div" PASSporT. If AT&T is choosing a new target for your call, and creates a "div" PASSporT to reflect that, having a copy of that "div" PASSporT does not enable a spammer to add anything to a call other than AT&T's assurance that number A is being retargeted to number B at this specific iat internal, which, when added to a call, is of no use in impersonating anyone or obscuring your identity.</Jon>
    
    Section [Missing]: Privacy Considerations
    Sprinkled throughout the document are privacy considerations, like how this mechanism is inappropriate for anonymization services (see, e.g., the last paragraph of Section 4.2).
    
<Jon>Probably we could stand to add a few sentences about the privacy implications of this; I'll do that.</Jon>

Jon Peterson
Neustar, Inc.