Subject: [stir] In-line certificate checking

From: Eric Burger <[email-masked]>
Date: Sun, 19 Jul 2015 20:38:57 -0400

The threat model for revoked certificates is beyond wrong and results in putting a burden of 100,000+ tps during busy hour on exemplary networks, such as AT&T and Verizon in the U.S. Note that not only are they making that magnitude of queries, but they are also responding to more than that magnitude of queries.

The fundamental error is that the threat model presumes that a number port will break the certificate. Well, that is correct. If you port your number from AT&T to Verizon, AT&T should not be able to sign for your CLID. However, it does not matter. You ported the number, which means you are the number, which means that it does not matter whether AT&T or Verizon signs for it, the number still points to you. So, the fundamental error is in thinking who vouched for the end user matters. It does not.

The other cases that one might think could matter also do not matter. Specifically, if a fallow number gets reassigned, the old subscriber could then start reusing their old number. This does not matter because the protocol can simply specify that the certificate lifetime MUST be shorter than the service provider’s fallow period. Since certificates will have a lifetime of at most days, this is not a problem in the real world. The other possibility is a fallow number gets ported (I don’t see how that could happen, but let’s say it might). Again, the solution to the general fallow number scenario applies here.

Also, if someone did manage to use an old certificate on what is now someone else’s number, the carrier has the certificate and date, which means they can figure out who had the certificate, which means they can use legal means to rectify the situation.

Diginotar was brought up as a potential reason to check each and every call’s certificate chain. Again, this is a non-issue in the real world. Specifically, I doubt there will be 300+ root certificates in the trusted root store. There might be one or two in the validation function. These certificates will certainly be pinned. Moreover, they are likely to have proprietary update mechanisms.

Because the draft gets the threat model wrong, it asserts that CRL distribution is not an answer and that verifiers MUST do in-call dips to check the validity of the certificate before they validate the call against the certificate. Well, the draft does propose an optimization: the authorizer can assert that it is authorized to do the authorization. That is insane. The vulnerability is precisely that the authorizer is lying. Relying on a lying element say it is not lying is not a good policy.

I would also offer that we already have an out of band mechanism that is already established in North America (and similar systems in the UK, India, much of South America, etc.): carriers already get push notifications when a number gets ported. One can envision mechanisms, outside of an IETF protocol, that can let carriers know when certificate owners might not be the right ones for a particular number. Moreover, those existing mechanisms blow up the “CRL’s could not possibly be used because of volume,” because a similar process has been done for close to 20 years at a precisely similar rate of transactions.

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 20 Jul 2015 07:59:37 +0000

Because the draft gets the threat model wrong, it asserts that CRL distribution is not an answer and that verifiers MUST do in-call dips to check the validity of the certificate before they validate the call against the certificate.

No, it doesn't. Not only does it not stipulate that verifiers MUST do OCSP, it only lists it as a SHOULD that certs contain a link to an OCSP service at all. It discusses numerous alternatives for establishing current cert scope: for example, future work on subscription-based approaches.

Number portability is not part of the "threat model," the threat model is about impersonation - robocalling, voicemail hacking, and all that. To defeat those threats, you need a means to determine if a particular number is within the scope of the credential. This is the part of the STIR work that is fairly novel - it isn't baseline X.509 behavior to have a TNAuthList dictate credential scope. It is not clear that the TNAuthList will actually appear in every cert, even - we want to be able to include it by reference. These are the sorts of practicalities that motivated the OCSP TNQuery extension and the new AIA accessMethod proposed in the draft. But they are not mandatory, and number portability is only one example of how the scope of these certs might be dynamic.

We know that there will be high volume environments for STIR, and we do expect optimizations will be required for these environments - like potentially a push model for cert scope changes. But let's crawl before we walk.

Jon Peterson
Neustar, Inc,

Sent from my iPad

On Jul 20, 2015, at 2:39 AM, Eric Burger <[email-masked]<mailto:[email-masked]>> wrote:

I would also offer that we already have an out of band mechanism that is already established in North America (and similar systems in the UK, India, much of South America, etc.): carriers already get push notifications when a number gets ported. One can envision mechanisms, outside of an IETF protocol, that can let carriers know when certificate owners might not be the right ones for a particular number. Moreover, those existing mechanisms blow up the “CRL’s could not possibly be used because of volume,” because a similar process has been done for close to 20 years at a precisely similar rate of transactions.
_______________________________________________
stir mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/stir