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

["Gorman, Pierce A [CTO]" <[e-mail]>]

I assume in practice there will be billions of communication endpoints (in the discussion they've been referred to as phones, but laptops, tablets, toasters, cars, M2M/IoT are also candidates) which may authenticate calling number in situ, and others which may have authenticated information proxied to them (over a secure communications channel?), and not necessarily using SIP (think WebRTC) or HTML.

Computing power and time is cheaper in the core as compared to endpoints.  More signaling messages and dips are bad as compared to less signaling and dips.

There are always trade-offs and the safe thing to assume is don't assume anything (with regard to centralized or distributed, cached or dipped).

Sent from my iPad

> On Jul 28, 2015, at 8:57 PM, Chris Wendt <[e-mail]> wrote:
>
> 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
>

________________________________

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.