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

[Brian Rosen <[e-mail]>]

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