Stir/Shaken Questions

I've been looking over STIR/SHAKEN stuff for dealing with Spam-o-SIP. There's a really nice problem statement (rfc 7340) which outlines all of the interactions with the legacy PSTN and its interactions with SIP gateways and session border controllers (SBC). The gist of the resulting set of RFC's presents a pretty complicated architecture with Policy Administrators (PA) (I assume something like the ITU or some other such creature) which does admission control of who is allowed to join the telephone number bearing club, delegated CA's to sign club member's certs, and then a sort of peculiar over-the-wire signing and verifying service within each provider. From my understanding this is all within a SIP network -- anything beyond a PSTN gateway is terra incognita if the gateway switch is relaying it from a source it does not control. But that's just a previously unsolved technical problem, I think, and the layer 8 solutions from the past may still be effective, re: Caller ID. Now I must fess up that I only recently heard about this, so my characterizations are likely to have flaws or be downright wrong, so take this with a grain of salt.

Plain Old SIP

My first question is whether this is intended to be a solution for plain old SIP URI's as well? If so, it's sort of worrisome to have his PA entity determining who can join the club for an all-IP service. Binding telephone numbers to particular carriers and making certain that the carrier is part of the telephone number club is a much different problem space than SIP-SIP with no telephone numbers involved. Assuming that is not intended to solve for that problem, is there a way to identify either the end user URI, or aggregated at provider boundaries on, say, a domain basis? With DKIM, we chose to allow mail providers to sign the mail with their domain -- whether or not they are the originating domain -- to say "blame me".  This gives the originating provider some incentive not to be blamed by requiring MUA authentication, etc.

RFC 7340 talks about SIP Identity (rfc 4474) and I can certainly understand the issue with B2BUA's which have analogs in the email universe (cf mailing lists). With DKIM we essentially punted and declared that the breaking gateway should sign the mail anew, and that they are now the one to blame. This seems to have worked out ok, as far I can tell. Dealing with spam is all about messy heuristics and I expect that SIP spam will be no different. The general idea is to be able get enough clues about bad actors as part of the full set of clues.

DKIM for SIP?

It has always seemed that a DKIM like approach would work for SIP as well. It has the nice property that it doesn't require a centralized CA. I'm too lazy to look up SIP identity, but I'm guessing that it does require them in some form. The web got lucky with TLS because there were only a very few browsers and the accepted CA root list was controlled by them before things could get out of control. With SIP, it's been around a long time and SIP Identity didn't get much traction from what I read, so I'm not sure if that's part of the problem, or is just academic since it just didn't get deployed.

DKIM for SIP would be fairly trivial to implement. In fact, I hacked together a SIP proxy that signed and verified SIP messages. And, of course, the infrastructure is all there as DKIM at this point is really old and really widely deployed. If SIP Identity doesn't get used for whatever reason, and we don't have a deployed solution for SIP-SIP calls, that seems like a really big hole. Fortunately, we have an existence proof with email which could be retrofitted pretty easily.

Is this Partly a UI Problem?

When I receive a call, my phone does the best it can to tell me who it is rather than giving me just a plain old telephone number. In fact, that's one of the best ways to determine whether it's spam is if you don't recognize the number. At this point, we are all very comfortable using email addresses as identities. So what I'm getting at is why doesn't my phone app take plain old SIP calls and treat them equivalently? In which case, it can use the From: address rather than some Paleolithic telephone number. There's nothing stopping Google or Apple from adding a new SIP protocol head onto their existing call apps, after all. This would at least break the notion that legacy telephone numbers are the only ID I should see when I get an incoming call. Hopefully the legacy PSTN calling will be winding down in the next 10 years or so, but we certainly don't want to carry along legacy telephone anachronisms into the future of an all SIP infrastructure. 

Signer and Verifier Services

This is more of a quibble, but I really don't understand why there needs to be a separate on-the-wire protocol for SIP proxies and authentication. With DKIM, the signing and verifying are done in the MTA, and it demonstrably works just fine. The CPU cost of signing these days is minuscule, and verification was always nothing. Plus, it costs time to send something over the wire and get a response, and with SIP that is a consideration. So I just don't get what motivated this.

Conclusion

While I think this looks like good work, I'm worried that it's putting a lot of time and energy into dealing with a legacy issue, and perhaps either not dealing with the SIP-SIP case, or dealing with it in a way that requires being invited to a club.  Either would be very bad. We really should be trying as hard as possible to make plain old SIP the way people expect to get a "phone call", and SIP itself needs to be able to have a workable solution that doesn't depend in any way on legacy PSTN stuff or we're going to be in the same boat a few years down the line.