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

[Chris Wendt <[e-mail]>]

Depends on your perspective. 

I would suspect we would both agree that “phones querying the numbering authority registry" is not the problem statement we are working towards, for very different reasons.


> On Jul 28, 2015, at 9:51 PM, Richard Barnes <[e-mail]> wrote:
> 
> On Tue, Jul 28, 2015 at 9:43 PM, Chris Wendt <[e-mail]> wrote:
>> Henning discussed an example at the modern meeting.  Gossip based
>> distributed mechanisms can be used.
>> 
>> I’m curious what you mean by unbounded, in terms of numbers?
>> 1k/10k/100k/1M?
> 
> How many phones are there out there?  "end systems must be able to
> validate the source identity information."
> 
> 
>> DNS is a much more brute force mechanism for a distributed system but yet it
>> propagates things pretty quickly globally.
>> 
>> 4474bis if i remember correctly even mentions the fact that we will need to
>> store multiple historical certificate records and references (maybe 2 is
>> enough in practice) in order to mitigate delays in propagation of new
>> certificates.
>> 
>> I don’t see the issue.
> 
> The point is that when my phone gets a call it needs to be able to
> verify the caller's authorization.  The Identity-Info signature binds
> the call to the caller's public key.  So the my phone needs to verify
> that the public key is authorized.
> 
> If I understand you correctly, you're proposing that my phone needs to
> sync down a giant database of which public keys are authorized for
> which numbers, or it needs to call out to some registry it trusts,
> which needs to be online all the time.
> 
> Those both seem far worse than my phone just having to look up a
> certificate, or verify one that was included in the INVITE directly.
> The only cost of on the signer side is that the signer has to pick the
> right cert to send, which, as I said before, is just a hash table
> lookup.
> 
> --Richard
> 
>> 
>> 
>> On Jul 28, 2015, at 9:30 PM, Richard Barnes <[e-mail]> wrote:
>> 
>> On Tue, Jul 28, 2015 at 9:22 PM, Chris Wendt <[e-mail]>
>> wrote:
>> 
>> If the registry is distributed, and the certificate dip is local to the
>> provider, the numbering authority isn’t in the middle of each call, one of
>> the points we are advocating in general, in terms of making this scalable
>> and “deployable”.
>> 
>> 
>> Do you happen to have a good standard technology on hand for
>> synchronizing a database across a potentially unbounded set of
>> signers/verifiers?  I don't think we can assume that that set of
>> actors is limited to the set of "providers", for any definition of
>> that term.  For so it is written in RFC 7340:
>> 
>> """
>>  Generation:  Intermediaries as well as end systems must be able to
>>     generate the source identity information.
>> 
>>  Validation:  Intermediaries as well as end systems must be able to
>>     validate the source identity information.
>> """
>> 
>> If you're going to meet that requirement, I think your distributed
>> registry ends up looking far more complex than just passing around
>> certificates.
>> 
>> Of course, if you're just talking about a signer looking up what cert
>> it should use, then we agree; that's just what I meant when I said
>> that managing multiple certs is just a hash table lookup.
>> 
>> --Richard
>> 
>> 
>> 
>> 
>> 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
>> 
>> 
>> _______________________________________________
>> stir mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/stir
>> 
>>