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

[Richard Shockey <[e-mail]>]

Richard.  That is the core problem here. As far as some of us believe
there are no silver bullets and STIR in itself is not the ultimate
solution. It was in the beginning a multifaceted problem. We knew that the
goal was to suppress the problem sufficiently in order to restore public
confidence in the system.

Perfection is not the goal.  Goodness knows I don’t think ENUM is now the
solution for database distrbution.  The model to be sure but we have much
better tools and HTTPS now for distributed databases.

Focus on tools and not policy.




On 7/28/15, 6:57 PM, "stir on behalf of Richard Barnes"
<[e-mail] on behalf of [e-mail]> wrote:

>On Tue, Jul 28, 2015 at 6:30 PM, Richard Shockey <[e-mail]>
>wrote:
>>
>> Richard .. Be reasonable here its not a perfect world and IETF
>>protocols,
>
>You are correct that if we build a putative security solution based on
>public keys passed DNS, it will not be an IETF protocol.  It will not
>become an RFC because it will not meet the IETF's security standards.
>
>And in any case, it's not that much harder to do the really secure
>thing.  Even if you want a central registry, do it over HTTPS, and
>it'll be just as fast and 100% more secure.
>
>--Richard
>
>
>> especially its security protocols are not perfect.  At some point the
>> limited competency of the IETF will move into the realm of policy.
>>
>> In the US that means the usual suspects will have to weigh in. ATIS INC,
>> the NANC,FCC. Its only a matter of time this ends up being a FCC Docket.
>> This is not to say engineering concerns do not drive policy, far from it
>> look at spectrum issues for instance.
>>
>> But its their [FCC CRTC OFCOM ART BeNetA FICORA) numbers and we (IETF)
>>do
>> not dictate policy. Only offer options.
>>
>>
>> ‹
>> Richard Shockey
>> Shockey Consulting LLC
>> Chairman of the Board SIP Forum
>> www.shockey.us
>> www.sipforum.org
>> richard<at>shockey.us
>> Skype-Linkedin-Facebook rshockey101
>> PSTN [phone]
>>
>>
>>
>>
>>
>> On 7/28/15, 4:06 PM, "stir on behalf of Richard Barnes"
>> <[e-mail] on behalf of [e-mail]> wrote:
>>
>>>http://www.afldreamers.com/wp-content/uploads/2014/01/why-not-have-both-
>>>30
>>>0x187.png
>>>
>>>You could have a database of certs+OCSP responses as an optimization.
>>>IIRC, Identity-Info only has pointers to certs anyway.
>>>
>>>On Tue, Jul 28, 2015 at 3:13 PM, PFAUTZ, PENN L <[e-mail]> wrote:
>>>> 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
>>
>>
>
>_______________________________________________
>stir mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/stir