Re: [stir] New draft draft-rosenberg-stir-callback-00

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

A couple more notes on the design choices of attesting effective control of a number via a CA vs. caching “callback on first-use” self-signed certs, as I’m doing slides for tomorrow…

The CA still becomes accountable for holding an accurate and authoritative database of numbers for (presumably) a very large number of users, for keeping it up to date, for handling corrections should an error get made (which invariably it will for some reason), for deciding how to price such a service,

So Let's Encrypt is now doing this sort of thing gratis for what, 50 million active certs or so? It doesn't have to be just one CA doing all the work: for various operational and administrative reasons, one size probably won’t fit all for STIR. And sure, no CA is perfect in terms of handling errors - but then again the "effective proof of control of a telephone number" attestation we're seeking for this particular use case is closer to TOFU than to heavyweight enrollment mechanisms for liability-grade certs. Our threat model can be mitigated with something weaker than liability-grade certs, anyway. So we just need to have a sane CP/CPS that does not overpromise on the level of assurance these certs provide.

for dealing with whatever local regulations their lawyers think they may be signing up for by being in the telco business. Since, regardless of how this database gets populate, they are in the telco business because they sell a telco database.

I don't know if you're implying something more specific here, but I guess I agree that any database used in communications could end up being regulated somewhere in the world. I'm sure that's as true of distributed databases as centralized ones. Certificates have always been able to have telephone numbers in them, including a telephone number in a cert doesn't polymorph its issuing CA into a "telco database" with a national flag sticking out of it.

Distributing the work distributes the accountability, and places it in the first party (the entity that consumes it) rather than the third party (with someone else). That is a dramatic difference.

ACME is just a protocol: who operates the CAs and the relationship of those entities to the communicating parties isn't prescribed by the architecture. So it doesn’t entail centralizing the accountability in one place or distancing it from the first (or second) party. Maybe some of the CSPs involved in STIR want to act as CAs themselves (or contract out for that as a white label service), in which case we should hesitate to consider them “third parties” at all. Moreover, where there are one or more third parties, or a federated consortium like Let's Encrypt, say, accountability is always limited by the policies used to issue certificates - which can be favorable or unfavorable to various user and/or government interests, sure.

But to the broader question here, I think there are other differences that matter, beyond just accountability. The design decision to have callers enroll to establish their identities prior to the first time they place a secure call to anyone, versus establishing their identity in real time every time they call someone new, has a host of architectural implications and associated trade-offs. How many times you need to prove your effective control, and whether you need to prove it within call set-up time, can lead to some pretty substantially differences in how the system behaves.

We’ve considered something similar when looking at models where you might require a new short-term cert for every signed call as an alternative to doing something like OCSP stapling in SIP for credential freshness - some of the same principles probably apply here. Any strategy that relies on called parties remembering the last cert you used incidentally limits certain ways of using short-term certs, and that has been our ostensible direction for certificate freshness here in STIR since we gave up on OCSP stapling.

A lot of scam calls these days impersonate government agencies or large enterprises - but those entities place a lot of legitimate calls too from one number, sometimes a large number of legal calls all at once, and in a COFU scheme that could cause vast amounts of simultaneous callbacks. In so far as we care about the potential post-dial delay due to the RTT in the reverse direction before connecting, those problems could be compounded in some of the harder use cases we hope to solve for.

As Christer mentioned there are probably some hard edges around forking and forwarding cases where a callback has trouble finding its way home or the whole thing is otherwise confused by unexpected retargeting. The difference between the way SIP requests are routed and how PSTN calls/messages are routed has always been a challenge in considering “pure SIP” callback mechanisms as a way to prove ownership of a telephone number – I know it’s kind of an assumption of the draft that this just works, but I worry enough about it that I think SMS routability tests are at least as viable, even with the limitations of SMS.

We sometimes talk about "legitimate spoofing" cases in STIR: cases where an entity (a doctor is the usual example) is authorized to use someone else's telephone number. Typically we would address that with certificate delegation, under the RFC8226 model. There are trade-offs related to implementing this with callbacks: if legitimate spoofing needs to be authorized in real time during call set-up, that requires the delegating authority to be available and responsive at the necessary moment. Sometimes that’s convenient but sometimes it might not be.

We can work through those trade-offs, but at the end of the day my biggest concern is that this isn’t moving the ball in the right direction. SIP isn't the only protocol used to originate robocalls, so we've spent some time here thinking about how to make PASSporT and the STIR architecture applicable when SIP isn't being used end-to-end, like in our out-of-band draft. I think we want entities that don't even support SIP to be able to use PASSporT. So while I think a SIP callback could be a way to help get credentials for STIR, it shouldn't be the only way - and the security association it creates should ideally be applicable to signing PASSporTs in non-SIP use cases. This is why at least I’ve been looking at a more generic credential architecture like ACME. Having the credentials just be bare self-signed keys that are only trusted because a recipient has seen them before doesn't seem like a promising incremental step in the direction we want to go. If we have certificates that show even effective proof of control over a telephone number they could be leveraged for other functions than beating impersonation as well, which we’re talking about elsewhere in the IETF.

I think there are probably paths here that have many of the desirable properties of a callback solution that nonetheless have a clearer transition path to our intended architecture, and which perhaps don’t incur some of the challenges that arise from doing this in real time.

Jon Peterson
Neustar, Inc.