Re: [stir] On OCSP, TNs, and Privacy

["DOLLY, MARTIN C" <[e-mail]>]

It has to be easy and deplorable, without creating a business case for some 3rd party or we may just have white/black lists

Sent from my iPhone

> On Jul 28, 2015, at 3:27 PM, Henning Schulzrinne <[e-mail]> wrote:
> 
> That was certainly one of the models that have been discussed in the past. Particularly for small carriers, this would likely reduce the operational impact to a configuration option in the SBC.
> 
> The disadvantage of this model is caller privacy: If the cert is stored at a numbering authority, it would be easy for that authority to know which carrier is receiving calls from whom. (It's not the complete meta data since it's lacking the callee information.)
> 
> However, unless the TN-to-LRN (in the US) mapping is cached, this "leak" already exists today.
> 
> -----Original Message-----
> From: PFAUTZ, PENN L [mailto:[e-mail]] 
> Sent: Tuesday, July 28, 2015 3:14 PM
> To: Henning Schulzrinne <[e-mail]>; Gorman, Pierce A [CTO] <[e-mail]>
> Cc: [e-mail]
> Subject: RE: [stir] On OCSP, TNs, and Privacy
> 
> Forgive me but my reptile brain keeps whispering in my ear that this would be a lot easier if we simply had a numbering registry, whether distributed or centralized - like we need anyway for at least for number portability - that also contained the public keys. No tedious mucking about in cyberspace with certs, CRLs, or OCSP.
> 
> 
> 
> -----Original Message-----
> From: stir [mailto:[e-mail]] On Behalf Of Henning Schulzrinne
> Sent: Tuesday, July 28, 2015 10:24 AM
> To: Gorman, Pierce A [CTO]
> Cc: [e-mail]
> Subject: Re: [stir] On OCSP, TNs, and Privacy
> 
> In the US alone, we have about 4000 carriers. Managing the reputation of that many entities, reliably (i.e., without making false positive/negative mistakes) seems a whole lot more manual effort than storing bags of bits. Storage and automation is cheap, human judgement and dealing with mistakes is expensive.
> 
> Obviously, nothing in the architecture prevents wildcard certificates.
> 
> -----Original Message-----
> From: stir [mailto:[e-mail]] On Behalf Of Gorman, Pierce A [CTO]
> Sent: Tuesday, July 28, 2015 10:14 AM
> To: Richard Barnes <[e-mail]>
> Cc: [e-mail]; Alex Bobotek <[e-mail]>; Brian Rosen <[e-mail]>
> Subject: Re: [stir] On OCSP, TNs, and Privacy
> 
> I thought the discussion was on key/cert management.  I'm asking if I understood the suggestion to minimize requirements.  How is that off topic?
> 
> Best regards,
> 
> 
> Pierce Gorman
> Core Network Planning
> O: 913-439-4368
> [e-mail]
> 
> 
> -----Original Message-----
> From: Richard Barnes [mailto:[e-mail]]
> Sent: July 28, 2015 9:12 AM
> To: Gorman, Pierce A [CTO] <[e-mail]>
> Cc: Alex Bobotek <[e-mail]>; Brian Rosen <[e-mail]>; [e-mail]
> Subject: Re: [stir] On OCSP, TNs, and Privacy
> 
>> On Tue, Jul 28, 2015 at 9:51 AM, Gorman, Pierce A [CTO] <[e-mail]> wrote:
>> "Large scale certificate management is expensive, and TN-specific certificates are unneeded for securing calls placed by parties who choose to place calls through a single reputable telephone service provider."
>> 
>> Are you saying that for "on-net" calls, STIR methodology is unnecessary?
> 
> This seems a little off-topic for this list.
> 
> --Richard
> 
>> 
>> Best regards,
>> 
>> 
>> Pierce Gorman
>> Core Network Planning
>> O: 913-439-4368
>> [e-mail]
>> 
>> 
>> -----Original Message-----
>> From: Alex Bobotek [mailto:[e-mail]]
>> Sent: July 27, 2015 11:36 PM
>> To: Brian Rosen <[e-mail]>; Richard Barnes <[e-mail]>
>> Cc: [e-mail]
>> Subject: Re: [stir] On OCSP, TNs, and Privacy
>> 
>> What motivation would a carrier have to choose any model other than carrier signing using one of a very limited set of carrier-owned keys?  Large scale certificate management is expensive, and TN-specific certificates are unneeded for securing calls placed by parties who choose to place calls through a single reputable telephone service provider.  Anyone can get many certificates, even a free ones anonymously from some issuers.  It is typically a combination of the strength of the end-user authentication performed by the service provider (or certificate issuer in a provider-agnostic model) and the identity's history that are most useful in security.
>> 
>> If we're trying to secure the current telephone system, DNS-like key repositories a la DKIM or perhaps a small number (compared to the number of TNs) of certificates are far more practical.
>> 
>> Regards,
>> 
>> Alex
>> 
>>> -----Original Message-----
>>> From: stir [mailto:[e-mail]] On Behalf Of Brian Rosen
>>> Sent: Monday, July 27, 2015 7:40 PM
>>> To: Richard Barnes <[e-mail]>
>>> Cc: [e-mail]
>>> Subject: Re: [stir] On OCSP, TNs, and Privacy
>>> 
>>> What this means in practice is that it’s TN per cert.
>>> 
>>> I wouldn’t say that it’s impossible for a carrier to maintain dozens 
>>> of copies of millions of private keys securely, but it’s hard.  You 
>>> need multiple copies because you have multiple elements that can 
>>> initiate a call, and you don’t want to depend on a centralized 
>>> resource to do something as basic as create a call.
>>> 
>>> I think it’s hard enough that REQUIRING cert per TN is not acceptable.
>>> 
>>> Folks with more intimate knowledge of carrier SIP infrastructure 
>>> might have more insight than I do.  It may be acceptable to have a 
>>> centralized resource to manage millions of keys.
>>> 
>>> Brian
>>> 
>>>> On Jul 27, 2015, at 6:13 PM, Richard Barnes <[e-mail]> wrote:
>>>> 
>>>> After the STIR meeting in Prague, Henning and I spent a few minutes 
>>>> talking through options for revocation checking and certificate 
>>>> scoping, and I think we have a better idea of what the optimal 
>>>> solution looks like.  Some notes are below, and some slides with 
>>>> pictures attached.
>>>> 
>>>> tl;dr: We should:
>>>> * Keep TNs in certificates and not bother with any OCSP extensions
>>>> * Require Identity-Info to include OCSP responses for all certs in 
>>>> the chain
>>>> 
>>>> 
>>>> # Background: Revocation in the web PKI
>>>> 
>>>> In an HTTPS transaction, the HTTPS server provides the client with 
>>>> a certificate, and it can optionally include an OCSP response ("staple"
>>>> it to the transaction).
>>>> 
>>>> A certificate contains a validity interval, a key, and some names/TNs.
>>>> An OCSP responses contains a validity interval, a certificate ID 
>>>> (i.e., a hash), and a status (good/revoked/unknown).  In the web 
>>>> PKI, certificates are required to be no more than 39 months long, 
>>>> and OCSP responses no more than 10 days.
>>>> 
>>>> Ideally, a client only considers a certificate valid if it is 
>>>> accompanied by an OCSP response.  In practice, this is not always 
>>>> possible; because OCSP queries fail around 3% of the time, browsers 
>>>> can't require OCSP.  This operational fact will be important below, 
>>>> but we will continue to have scoping cert lifetimes as an objective.
>>>> 
>>>> In the web PKI, there are basically three revocation checking modalities:
>>>> 
>>>> 1. Live OCSP checking [RFC6069]
>>>> 2. OCSP stapling / must_staple [RFC6066, 
>>>> draft-hallambaker-tlsfeature] 3. Short-lived certificates (~OCSP
>>>> lifetime)
>>>> 
>>>> (The last of these is relatively novel, and has not been deployed.
>>>> Neither has must-staple.  But they're both pretty trivial, and 
>>>> could be folded into a STIR architecture pretty easily.)
>>>> 
>>>> Right now, about 90% of TLS transactions use live OCSP, and about 10%.
>>>> CAs and browsers dearly want the world to move toward stapled OCSP 
>>>> or short-lived certs, because these reduces latency and improve the 
>>>> quality of revocation information.
>>>> 
>>>> Revocation for CA certificates is currently done by having browsers 
>>>> download a list from a centralized server, since there's no way to 
>>>> staple more than one OCSP response.  That solution works OK for the 
>>>> web, but if I were designing something de novo, I would probably 
>>>> use multi-stapling as well.
>>>> 
>>>> 
>>>> # Applying this experience to STIR
>>>> 
>>>> Most of the below appear to be desired properties by the WG:
>>>> 
>>>> * Verifier neeeds to know that a cert is valid for a specific 
>>>> number
>>>> * Scoped cert lifetime: Limit certs to ~1week lifetime (by OCSP if 
>>>> issued longer)
>>>> * Caller privacy: Don't report what calls someone receives to a 
>>>> central server
>>>> * Carrier privacy: Don't allow a third party to figure out all the 
>>>> numbers a carrier holds
>>>> * Minimize the rate at which the CA has to sign things
>>>> * Tolerate outages at the CA
>>>> 
>>>> I'm going to assume for now that we will not do live OCSP.  It 
>>>> violates the caller privacy requirement, and as discussed above, it 
>>>> just sucks operationally.  So STIR should require OCSP to be sent 
>>>> in "stapled" form, which probably means sending it in Identity-Info.
>>>> And while we're at it, we should also do "multi-stapling" -- send 
>>>> an OCSP response for CA certs as well.
>>>> 
>>>> So if we consider a server with 50k TNs / blocks, that leaves us 
>>>> with basically 3 options:
>>>> 
>>>> 1. 50k short-lived certs (no OCSP)
>>>> 2. 50k long-lived certs scoped to TNs + generic OCSP 3. 1 
>>>> long-lived cert not scoped to TN (or a few loosely scoped) + OCSP 
>>>> with TN info
>>>> 
>>>> (As I didn't quite get to say in the meeting, regardless of the 
>>>> approach, you have to have 50k of *something*.)  Of these, it seems 
>>>> like the preference order is 2 > 1 > 3.
>>>> 
>>>> Option 3 is bad from several perspectives:
>>>> * Putting TN info in the OCSP response enables someone to trawl for 
>>>> numbers unless you access-control the OCSP server, so you inherit a 
>>>> requirement to do that.
>>>> * With the rate of churn in number assignments, you're probably 
>>>> going to have to update the long-lived cert pretty frequently anyway.
>>>> * Putting TN-specific stuff in certs is better than putting it in 
>>>> OCSP.  As bad as X.509 libraries can be, OCSP libraries are much 
>>>> worse.
>>>> 
>>>> Option 1 is mainly bad from the perspective of CA load and outages.
>>>> With Option 2, if the CA goes down, client can continue to use the 
>>>> long-lived cert and just not bother doing OCSP (vs. tolerating an 
>>>> expired cert).  Slightly cleaner.  Plus, there's a lot more 
>>>> experience caching OCSP than new certs.  OCSP signing can also be 
>>>> delegated, so you can have the recurring operation done by a lower-risk key.
>>>> 
>>>> Option 2 should be pretty easy to automate.  You can probably 
>>>> re-use tooling for OCSP stapling that has already been developed 
>>>> for use with HTTPS.  If you're a big box signing for a bunch of 
>>>> numbers, you do need to select the right cert and OCSP response for 
>>>> a given call, but that's a pretty simple lookup table.
>>>> <STIR.pptx>_______________________________________________
>>>> stir mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/stir
>>> 
>>> _______________________________________________
>>> stir mailing list
>>> [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.
> 
> ________________________________
> 
> 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.
> _______________________________________________
> stir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stir
> _______________________________________________
> stir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stir
> _______________________________________________
> stir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stir