Re: New wiki page on certificate revocation plans
On 04/12/2015 15:58, Kurt Roeckx wrote: On 2015-12-04 15:21, Jakob Bohm wrote: On 04/12/2015 11:19, Kurt Roeckx wrote: On 2015-12-04 02:55, Jakob Bohm wrote: How huge and unwieldy are CRLs really, especially if letting the computer (NSS/Firefox) do the updating? Individual CRLs are in the range of a few kB to a few MB. For the CA that issues the subscriber certificates they have a maximum validity of 10 days but should be updated at least every 7 days. The problem is that you want to check that CRLs before you send anything to that site, so either you need to download that CRL during the handshake, delaying the whole thing, of you would need to download all the CRLs beforehand and update them regularly. If you want to download them before you connect, you have a problem that you don't know them all. You only know about the root CAs, not the intermediate ones. But you do cache the intermediates that you've seen. You know the ones for all the certificates you have during validation, because each certificate lists all the applicable URLs directly. Root CA certs only list the (optional) CRL whose sole job is to self-revoke the root itself in worst case scenarios. This CRL may or may not be the same URL as the CRL that is used to revoke directly issued certificates. It should be a different CRL. A CRL is only about a specific CA certificate. The point is, that the two (one) CRLs are both for certificates issued by that self-signed root CA. Downloading for all the intermediates would be in the order of several GB a week that you need to download. As for timing, there is the bootstrap problem of slowing down the first connection needing a specific CRL (whose URL may not, in general, be known in advance), but subsequent connections to certificates pointing to that URL can use a cached CRL, which is preemptively updated at the first few "update by" times until N such downloads have been done without any reuse of that CRL. Thus for a typical user surfing mostly sites signed by the biggest 3-4 CAs plus 1 or 2 regional CAs, the weekly update would be limited to those (and only to those subCAs actually referenced). I currently have 197 non-root CAs in my browsers cache. But how many of those were accessed /recently/ and how big are their CRLs. And how does this compare to your regular weekly network usage, since I suspect a close correlation between the general level of user Internet activity and the number of subCAs involved in any given month. However this is also why I wrote at length about how ensuring that all mainstream/common browsers accept the more "recent" CRL format version will allow CAs to set up bandwidth-saving delta CRL schemes for certificates issued after this becomes a reality (remember that CRLs are referenced by the certificates they can revoke, not the subCA that signed those certificates). This general availability of v2+ CRL format compatibility applies regardless if those specific browsers use CRL download by default or not, just like the slow adaptation of SHA-2 in Microsoft browsers and e-mail clients held back the SHA-2 transition for at least a decade (and is still holding it back for code signing certificates because Microsoft officially refuses to provide this update for some of its OSes that software developers still need to support.) Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
On 2015-12-04 15:21, Jakob Bohm wrote: On 04/12/2015 11:19, Kurt Roeckx wrote: On 2015-12-04 02:55, Jakob Bohm wrote: How huge and unwieldy are CRLs really, especially if letting the computer (NSS/Firefox) do the updating? Individual CRLs are in the range of a few kB to a few MB. For the CA that issues the subscriber certificates they have a maximum validity of 10 days but should be updated at least every 7 days. The problem is that you want to check that CRLs before you send anything to that site, so either you need to download that CRL during the handshake, delaying the whole thing, of you would need to download all the CRLs beforehand and update them regularly. If you want to download them before you connect, you have a problem that you don't know them all. You only know about the root CAs, not the intermediate ones. But you do cache the intermediates that you've seen. You know the ones for all the certificates you have during validation, because each certificate lists all the applicable URLs directly. Root CA certs only list the (optional) CRL whose sole job is to self-revoke the root itself in worst case scenarios. This CRL may or may not be the same URL as the CRL that is used to revoke directly issued certificates. It should be a different CRL. A CRL is only about a specific CA certificate. Downloading for all the intermediates would be in the order of several GB a week that you need to download. As for timing, there is the bootstrap problem of slowing down the first connection needing a specific CRL (whose URL may not, in general, be known in advance), but subsequent connections to certificates pointing to that URL can use a cached CRL, which is preemptively updated at the first few "update by" times until N such downloads have been done without any reuse of that CRL. Thus for a typical user surfing mostly sites signed by the biggest 3-4 CAs plus 1 or 2 regional CAs, the weekly update would be limited to those (and only to those subCAs actually referenced). I currently have 197 non-root CAs in my browsers cache. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
On 04/12/2015 11:19, Kurt Roeckx wrote: On 2015-12-04 02:55, Jakob Bohm wrote: How huge and unwieldy are CRLs really, especially if letting the computer (NSS/Firefox) do the updating? Individual CRLs are in the range of a few kB to a few MB. For the CA that issues the subscriber certificates they have a maximum validity of 10 days but should be updated at least every 7 days. The problem is that you want to check that CRLs before you send anything to that site, so either you need to download that CRL during the handshake, delaying the whole thing, of you would need to download all the CRLs beforehand and update them regularly. If you want to download them before you connect, you have a problem that you don't know them all. You only know about the root CAs, not the intermediate ones. But you do cache the intermediates that you've seen. You know the ones for all the certificates you have during validation, because each certificate lists all the applicable URLs directly. Root CA certs only list the (optional) CRL whose sole job is to self-revoke the root itself in worst case scenarios. This CRL may or may not be the same URL as the CRL that is used to revoke directly issued certificates. Downloading for all the intermediates would be in the order of several GB a week that you need to download. As for timing, there is the bootstrap problem of slowing down the first connection needing a specific CRL (whose URL may not, in general, be known in advance), but subsequent connections to certificates pointing to that URL can use a cached CRL, which is preemptively updated at the first few "update by" times until N such downloads have been done without any reuse of that CRL. Thus for a typical user surfing mostly sites signed by the biggest 3-4 CAs plus 1 or 2 regional CAs, the weekly update would be limited to those (and only to those subCAs actually referenced). If all relevant browsers (I suspect NSS is or was the last holdout) supports v2+ CRLs with extra attributes in them, then the CA can publish delta CRLs to greatly reduce the per-refresh download size. If a still relevant browser supports only the original v1 CRL format, the CA cannot include the attributes needed to protect against MitM attackers duplicating one of the CRLs (master or delta) for the other to hide that the attacker is using a revoked certificate listed only in the thus suppressed CRL. This in turn is because it is legal (and good) for a certificate to provide redundant URLs for the same CRL, so the browser cannot object to discovering that multiple listed URLs point return the same CRL, unless that CRL contains a v2+ extension attribute saying it should only be returned from one of the other URLs. With proper delta CRL support across browsers, it might also be possible (I think) for a huge CRL to be split into multiple layers: A master updated every few months, a medium delta updated weekly and a minimal delta updated daily (or even hourly). Of cause all the technical details are in the relevant official specifications from ITU-T, RSADSI and IETF. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
On 2015-12-04 02:55, Jakob Bohm wrote: How huge and unwieldy are CRLs really, especially if letting the computer (NSS/Firefox) do the updating? Individual CRLs are in the range of a few kB to a few MB. For the CA that issues the subscriber certificates they have a maximum validity of 10 days but should be updated at least every 7 days. The problem is that you want to check that CRLs before you send anything to that site, so either you need to download that CRL during the handshake, delaying the whole thing, of you would need to download all the CRLs beforehand and update them regularly. If you want to download them before you connect, you have a problem that you don't know them all. You only know about the root CAs, not the intermediate ones. But you do cache the intermediates that you've seen. Downloading for all the intermediates would be in the order of several GB a week that you need to download. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
On 04/12/2015 02:20, Matt Palmer wrote: On Thu, Dec 03, 2015 at 07:32:43PM +0100, Jakob Bohm wrote: On 03/12/2015 11:25, Gervase Markham wrote: On 30/11/15 22:37, Jakob Bohm wrote: 1.2. Certificates that are moved from a server software implementation that does do OCSP stapling to another that doesn't. In particular, such cases should not lead to "certificate pinning errors" or any similar failure modes. You'll need to get a new cert if you have one which has must-staple in it and you want to use it on a webserver which does not support stapling. I wonder what the benefit is then (other than some CAs being able to force their customers to reduce load on their OCSP servers). Specifically: Regular stapling already provides the load and performance benefits when used. Non-stapling would result in an OCSP or CRL check without the change and/or without the extension, while it would result in instant failure with the change *and* the extension. You're assuming a world in which OCSP or CRL checks are done as a matter of course. They're not, because they're largely worthless (OCSP is not perfectly reliable, thus preventing hard-fail semantics, and CRLs are huge, unwieldy, and thus rarely updated by clients). Thus, a certificate without must-staple is able to be used by someone who has acquired the corresponding private key *long* after it has been revoked. On the other hand, a must-staple certificate isn't going to last past the OCSP response lifetime. - Matt How huge and unwieldy are CRLs really, especially if letting the computer (NSS/Firefox) do the updating? Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
On Thu, Dec 03, 2015 at 07:32:43PM +0100, Jakob Bohm wrote: > On 03/12/2015 11:25, Gervase Markham wrote: > >On 30/11/15 22:37, Jakob Bohm wrote: > >>1.2. Certificates that are moved from a server software implementation > >>that does do OCSP stapling to another that doesn't. In particular, > >>such cases should not lead to "certificate pinning errors" or any > >>similar failure modes. > > > >You'll need to get a new cert if you have one which has must-staple in > >it and you want to use it on a webserver which does not support stapling. > > I wonder what the benefit is then (other than some CAs being able to force > their customers to reduce load on their OCSP servers). > > Specifically: Regular stapling already provides the load and > performance benefits when used. Non-stapling would result in an OCSP > or CRL check without the change and/or without the extension, while it > would result in instant failure with the change *and* the extension. You're assuming a world in which OCSP or CRL checks are done as a matter of course. They're not, because they're largely worthless (OCSP is not perfectly reliable, thus preventing hard-fail semantics, and CRLs are huge, unwieldy, and thus rarely updated by clients). Thus, a certificate without must-staple is able to be used by someone who has acquired the corresponding private key *long* after it has been revoked. On the other hand, a must-staple certificate isn't going to last past the OCSP response lifetime. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
On 03/12/2015 11:25, Gervase Markham wrote: On 30/11/15 22:37, Jakob Bohm wrote: 1.1. Certificates that are used on servers that don't implement OCSP stapling. No-one is suggesting dropping support for non-stapling web servers. But the revocation options will not be as good. Good. 1.2. Certificates that are moved from a server software implementation that does do OCSP stapling to another that doesn't. In particular, such cases should not lead to "certificate pinning errors" or any similar failure modes. You'll need to get a new cert if you have one which has must-staple in it and you want to use it on a webserver which does not support stapling. I wonder what the benefit is then (other than some CAs being able to force their customers to reduce load on their OCSP servers). Specifically: Regular stapling already provides the load and performance benefits when used. Non-stapling would result in an OCSP or CRL check without the change and/or without the extension, while it would result in instant failure with the change *and* the extension. 2. Reintroducing the original CRL support (as was once present in Netscape browsers) would be a much more privacy friendly and efficient thing than trying to run a centralized Chrome-style "OneCRL" service for all ordinary revocations at all levels. The privacy and performance trade-offs between CRLs, OCSP and OneCRL have been hashed out many times. It's unlikely to be worth discussing them again unless you have anything new to add. Where? Could you point me to such a discussion? Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
On 30/11/15 22:37, Jakob Bohm wrote: > 1.1. Certificates that are used on servers that don't implement > OCSP stapling. No-one is suggesting dropping support for non-stapling web servers. But the revocation options will not be as good. > 1.2. Certificates that are moved from a server software implementation > that does do OCSP stapling to another that doesn't. In particular, > such cases should not lead to "certificate pinning errors" or any > similar failure modes. You'll need to get a new cert if you have one which has must-staple in it and you want to use it on a webserver which does not support stapling. > 1.3. Certificates that are used on multiple servers with the same owner > but different software, where some such servers support OCSP stapling > and others don't. One example would be the *.mozilla.org certificates > and the possibility (even if not applicable to Mozilla specifically) > that some may differ in that capability. Again, don't get must-staple in this case. > 2. Reintroducing the original CRL support (as was once present in > Netscape browsers) would be a much more privacy friendly and efficient > thing than trying to run a centralized Chrome-style "OneCRL" service > for all ordinary revocations at all levels. The privacy and performance trade-offs between CRLs, OCSP and OneCRL have been hashed out many times. It's unlikely to be worth discussing them again unless you have anything new to add. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
Having seen the current (as of a few hours ago) wiki page, I have two major things to add: 1. Unfortunately, not all https servers seem capable of doing OCSP stapling, thus any viable requirements and mechanisms must allow for: 1.1. Certificates that are used on servers that don't implement OCSP stapling. 1.2. Certificates that are moved from a server software implementation that does do OCSP stapling to another that doesn't. In particular, such cases should not lead to "certificate pinning errors" or any similar failure modes. 1.3. Certificates that are used on multiple servers with the same owner but different software, where some such servers support OCSP stapling and others don't. One example would be the *.mozilla.org certificates and the possibility (even if not applicable to Mozilla specifically) that some may differ in that capability. 2. Reintroducing the original CRL support (as was once present in Netscape browsers) would be a much more privacy friendly and efficient thing than trying to run a centralized Chrome-style "OneCRL" service for all ordinary revocations at all levels. Specifically: 2.1. Make Mozilla products recognize the CRL urls present in certificate extensions (accepting both the RFC-standard and the historic Netscape extension IDs), eliminate duplicate URLs and check those CRLs automatically (as opposed to the silly system where users had to enter the URLs and update frequencies manually for every CA). 2.2. CRLs should be cached in the (regular) browser cache according to their signed information on expiry on renewal, not the expiry values in HTTP headers. However unreasonably short or long expirys should be capped before use. Of cause invalid CRLs (bad syntax, bad signature, not valid at time of download, ...) should be discarded and not pollute the cache. 2.3. If relevant valid and current CRLs are obtained, skip OCSP querying for that certificate. This improves user privacy as OCSP requests reveal more about the users activities than CRL downloads, and since CRL downloads don't occur for each certificate but more like once per subCA per day/week. It should also be faster than OCSP. It is noted that many CAs (don't know the percentage amongst CAs in Mozilla's default trust list), update the CRL and OCSP at the same frequency, so there is rarely a benefit to check both. 2.4. Include logic that recognizes valid implementations of delta CRLs and other multi-CRL schemes and doesn't consider the checkable CRLs complete until a full set has been obtained and checked (for purposes of determining that the CRLs declare a certificate OK, but not for the purposes of declaring a certificate BAD). 2.5 Include countermeasures for CAs that try to provide different CRL URLs for different users, as that negates the intended privacy and efficiency benefits. In the past I am aware that the "TDC OCES" e-mail CA did this before moving to an even less secure model. 2.6. Note that such direct in-browser CRL support would also work with CAs not on the default Mozilla trust list, including local CAs inside companies and communities, as well as "citizen ID" CAs (that don't certify websites, but do certify users for e-mail and client-side TLS). On 21/11/2015 18:00, Richard Barnes wrote: Sorry, wrong thread. Expect to see a security blog post about revocation soon, summarizing some recent work :) On Sat, Nov 21, 2015 at 11:59 AM, Richard Barnes wrote: I took a hack at the blog post. I kept your outline, but ended up text-editing a bunch of it. I think it's pretty good now. On Thu, Jul 31, 2014 at 10:07 PM, Richard Barnes wrote: Hi all, We in the Mozilla PKI team have been discussing ways to improve revocation checking in our PKI stack, consolidating a bunch of ideas from earlier work [1][2] and some maybe-new-ish ideas. I've just pressed "save" on a new wiki page with our initial plan: https://wiki.mozilla.org/CA:RevocationPlan It would be really helpful if people could review and provide feedback on this plan. There's one major open issue highlighted in the wiki page. We're planning to adopt a centralized revocation list model for CA certificates, which we're calling OneCRL. (Conceptually similar to Chrome's CRLsets.) In addition to covering CA certifcates, we're also considering covering some end-entity (EE) certificates with OneCRL too. But there are some drawbacks to this approach, so it's not certain that we will include this in the final plan. Feedback on this point would be especially valuable. Thanks a lot, --Richard [1] https://wiki.mozilla.org/CA:ImprovingRevocation [2] https://www.imperialviolet.org/2012/02/05/crlsets.html ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 Thi
Re: New wiki page on certificate revocation plans
Sorry, wrong thread. Expect to see a security blog post about revocation soon, summarizing some recent work :) On Sat, Nov 21, 2015 at 11:59 AM, Richard Barnes wrote: > I took a hack at the blog post. I kept your outline, but ended up > text-editing a bunch of it. I think it's pretty good now. > > On Thu, Jul 31, 2014 at 10:07 PM, Richard Barnes > wrote: > >> Hi all, >> >> We in the Mozilla PKI team have been discussing ways to improve >> revocation checking in our PKI stack, consolidating a bunch of ideas from >> earlier work [1][2] and some maybe-new-ish ideas. I've just pressed "save" >> on a new wiki page with our initial plan: >> >> https://wiki.mozilla.org/CA:RevocationPlan >> >> It would be really helpful if people could review and provide feedback on >> this plan. >> >> There's one major open issue highlighted in the wiki page. We're >> planning to adopt a centralized revocation list model for CA certificates, >> which we're calling OneCRL. (Conceptually similar to Chrome's CRLsets.) >> In addition to covering CA certifcates, we're also considering covering >> some end-entity (EE) certificates with OneCRL too. But there are some >> drawbacks to this approach, so it's not certain that we will include this >> in the final plan. Feedback on this point would be especially valuable. >> >> Thanks a lot, >> --Richard >> >> [1] https://wiki.mozilla.org/CA:ImprovingRevocation >> [2] https://www.imperialviolet.org/2012/02/05/crlsets.html >> ___ >> dev-security-policy mailing list >> dev-security-policy@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-security-policy >> > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
I took a hack at the blog post. I kept your outline, but ended up text-editing a bunch of it. I think it's pretty good now. On Thu, Jul 31, 2014 at 10:07 PM, Richard Barnes wrote: > Hi all, > > We in the Mozilla PKI team have been discussing ways to improve revocation > checking in our PKI stack, consolidating a bunch of ideas from earlier work > [1][2] and some maybe-new-ish ideas. I've just pressed "save" on a new > wiki page with our initial plan: > > https://wiki.mozilla.org/CA:RevocationPlan > > It would be really helpful if people could review and provide feedback on > this plan. > > There's one major open issue highlighted in the wiki page. We're planning > to adopt a centralized revocation list model for CA certificates, which > we're calling OneCRL. (Conceptually similar to Chrome's CRLsets.) In > addition to covering CA certifcates, we're also considering covering some > end-entity (EE) certificates with OneCRL too. But there are some drawbacks > to this approach, so it's not certain that we will include this in the > final plan. Feedback on this point would be especially valuable. > > Thanks a lot, > --Richard > > [1] https://wiki.mozilla.org/CA:ImprovingRevocation > [2] https://www.imperialviolet.org/2012/02/05/crlsets.html > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
Hey all,
Just to let you know: I've updated this wiki page and removed the {{draft}}
indication at the top. I'm considering this the plan of record for now.
https://wiki.mozilla.org/CA:RevocationPlan
The primary edit was with regard to OneCRL covering EE certificates. For now,
we're considering that off the table, and focusing on CA certificates. Once we
have something there, we might re-consider whether some EE certificates can be
covered. For example, the space of EV certificates seems small enough (~40K
IIRC) that it might be feasible to cover with OneCRL.
Thanks to all for the discussion.
--Richard
On Aug 7, 2014, at 4:23 PM, Richard Barnes wrote:
>
> On Aug 4, 2014, at 9:21 AM, Rob Stradling wrote:
>
>> On 04/08/14 14:16, Gervase Markham wrote:
>>> On 02/08/14 15:20, Jesper Kristensen wrote:
* Have you considered adding support for multiple ocsp staples to allow
stapeling of CA certs?
>>>
>>> There is a proposed standard for multi-stapling but as far as I remember
>>> it's not even finished yet, yet alone implemented and deployed. We
>>> decided that we can't wait for it.
>>
>> FWIW, it's a Standards Track RFC now.
>>
>> http://tools.ietf.org/html/rfc6961
>>
>> I'm not aware of any implementations though.
>
>
> Funny enough, I'm an author on RFC 6169 :)
> http://tools.ietf.org/html/rfc6169
>
> Multi-stapling seems like a reasonable idea in principle. However, given the
> lack of implementation, it seems like a OneCRL-like strategy for
> intermediates is likely to have more impact faster.
>
> --Richard
>
>
>
>>
* Why not allow short-lived CA certs without revocation info, just like
EE certs?
>>>
>>> I'm not sure there are any CAs out there who would like to get their
>>> root key out of it secure storage every 3 days.
>>
>> Ouch. Painful.
>>
* While must-staple and short-lived certificates seem to be scalable
solutions, OneCRL seems to be a hack needed to make things work in the
current situation. It would be nice if this could be explicitly stated,
and even better if you could declare it as a temporary solution intended
to be used only until more scalable solutions are specced, implemented
and deployed.
>>>
>>> It's not a temporary solution for intermediate certs. Well, perhaps it's
>>> possible that multi-stapling could eventually supplant it (if TCP init
>>> windows also enlarge) but I don't think it's really necessary to
>>> speculate on that yet.
>>>
>>> Gerv
>>>
>>>
>>> ___
>>> dev-security-policy mailing list
>>> dev-security-policy@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-security-policy
>>>
>>
>> --
>> Rob Stradling
>> Senior Research & Development Scientist
>> COMODO - Creating Trust Online
>>
>> ___
>> dev-security-policy mailing list
>> dev-security-policy@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
Curious to know the process by which cert holders will get their certs added to these lists. How much of that flow and the necessary security measures have been worked out? Original Message From: Richard Barnes Sent: Thursday, August 7, 2014 3:59 PM To: Rob Stradling Cc: mozilla-dev-tech-cry...@lists.mozilla.org; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: New wiki page on certificate revocation plans On Aug 7, 2014, at 9:47 AM, Rob Stradling wrote: > http://dev.chromium.org/Home/chromium-security/crlsets says: > "The limit of the CRLSet size is 250KB" > > Have Mozilla decided what the maximum OneCRL size will be? No, we haven't. The need for a limit largely depends on whether we cover EE certificates. If we cover only intermediate CAs, of which there are roughly 1,800, then there is no size issue -- we can include the full SHA-256 digest of every CA certificate and only come to around 56KB. (Or just use a 1800-bit bitmap!) If we choose to cover EE certificates (as CRLSets do), then we will have to impose a size limit. In some initial experiments in representing CRLs with Golomb compressed encoding, we've been able to get down to roughly N bits per entry for 2^-N false positive rate. Since we'll still have OCSP as a fall-back, we can tolerate a high failure rate, maybe as high as 0.5% (2^-9). At that rate, a 250KB limit would fit around 220,000 CRL entries. So we would need to do some experimentation to see how that capacity compares to the size of CRLs in the wild. --Richard > > On 01/08/14 03:07, Richard Barnes wrote: >> Hi all, >> >> We in the Mozilla PKI team have been discussing ways to improve revocation >> checking in our PKI stack, consolidating a bunch of ideas from earlier work >> [1][2] and some maybe-new-ish ideas. I've just pressed "save" on a new wiki >> page with our initial plan: >> >> https://wiki.mozilla.org/CA:RevocationPlan >> >> It would be really helpful if people could review and provide feedback on >> this plan. >> >> There's one major open issue highlighted in the wiki page. We're planning to >> adopt a centralized revocation list model for CA certificates, which we're >> calling OneCRL. (Conceptually similar to Chrome's CRLsets.) In addition to >> covering CA certifcates, we're also considering covering some end-entity >> (EE) certificates with OneCRL too. But there are some drawbacks to this >> approach, so it's not certain that we will include this in the final plan. >> Feedback on this point would be especially valuable. >> >> Thanks a lot, >> --Richard >> >> [1] https://wiki.mozilla.org/CA:ImprovingRevocation >> [2] https://www.imperialviolet.org/2012/02/05/crlsets.html > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
On Aug 7, 2014, at 9:47 AM, Rob Stradling wrote: > http://dev.chromium.org/Home/chromium-security/crlsets says: > "The limit of the CRLSet size is 250KB" > > Have Mozilla decided what the maximum OneCRL size will be? No, we haven't. The need for a limit largely depends on whether we cover EE certificates. If we cover only intermediate CAs, of which there are roughly 1,800, then there is no size issue -- we can include the full SHA-256 digest of every CA certificate and only come to around 56KB. (Or just use a 1800-bit bitmap!) If we choose to cover EE certificates (as CRLSets do), then we will have to impose a size limit. In some initial experiments in representing CRLs with Golomb compressed encoding, we've been able to get down to roughly N bits per entry for 2^-N false positive rate. Since we'll still have OCSP as a fall-back, we can tolerate a high failure rate, maybe as high as 0.5% (2^-9). At that rate, a 250KB limit would fit around 220,000 CRL entries. So we would need to do some experimentation to see how that capacity compares to the size of CRLs in the wild. --Richard > > On 01/08/14 03:07, Richard Barnes wrote: >> Hi all, >> >> We in the Mozilla PKI team have been discussing ways to improve revocation >> checking in our PKI stack, consolidating a bunch of ideas from earlier work >> [1][2] and some maybe-new-ish ideas. I've just pressed "save" on a new wiki >> page with our initial plan: >> >> https://wiki.mozilla.org/CA:RevocationPlan >> >> It would be really helpful if people could review and provide feedback on >> this plan. >> >> There's one major open issue highlighted in the wiki page. We're planning >> to adopt a centralized revocation list model for CA certificates, which >> we're calling OneCRL. (Conceptually similar to Chrome's CRLsets.) In >> addition to covering CA certifcates, we're also considering covering some >> end-entity (EE) certificates with OneCRL too. But there are some drawbacks >> to this approach, so it's not certain that we will include this in the final >> plan. Feedback on this point would be especially valuable. >> >> Thanks a lot, >> --Richard >> >> [1] https://wiki.mozilla.org/CA:ImprovingRevocation >> [2] https://www.imperialviolet.org/2012/02/05/crlsets.html > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
On Aug 4, 2014, at 9:21 AM, Rob Stradling wrote: > On 04/08/14 14:16, Gervase Markham wrote: >> On 02/08/14 15:20, Jesper Kristensen wrote: >>> * Have you considered adding support for multiple ocsp staples to allow >>> stapeling of CA certs? >> >> There is a proposed standard for multi-stapling but as far as I remember >> it's not even finished yet, yet alone implemented and deployed. We >> decided that we can't wait for it. > > FWIW, it's a Standards Track RFC now. > > http://tools.ietf.org/html/rfc6961 > > I'm not aware of any implementations though. Funny enough, I'm an author on RFC 6169 :) http://tools.ietf.org/html/rfc6169 Multi-stapling seems like a reasonable idea in principle. However, given the lack of implementation, it seems like a OneCRL-like strategy for intermediates is likely to have more impact faster. --Richard > >>> * Why not allow short-lived CA certs without revocation info, just like >>> EE certs? >> >> I'm not sure there are any CAs out there who would like to get their >> root key out of it secure storage every 3 days. > > Ouch. Painful. > >>> * While must-staple and short-lived certificates seem to be scalable >>> solutions, OneCRL seems to be a hack needed to make things work in the >>> current situation. It would be nice if this could be explicitly stated, >>> and even better if you could declare it as a temporary solution intended >>> to be used only until more scalable solutions are specced, implemented >>> and deployed. >> >> It's not a temporary solution for intermediate certs. Well, perhaps it's >> possible that multi-stapling could eventually supplant it (if TCP init >> windows also enlarge) but I don't think it's really necessary to >> speculate on that yet. >> >> Gerv >> >> >> ___ >> dev-security-policy mailing list >> dev-security-policy@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-security-policy >> > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
http://dev.chromium.org/Home/chromium-security/crlsets says: "The limit of the CRLSet size is 250KB" Have Mozilla decided what the maximum OneCRL size will be? On 01/08/14 03:07, Richard Barnes wrote: Hi all, We in the Mozilla PKI team have been discussing ways to improve revocation checking in our PKI stack, consolidating a bunch of ideas from earlier work [1][2] and some maybe-new-ish ideas. I've just pressed "save" on a new wiki page with our initial plan: https://wiki.mozilla.org/CA:RevocationPlan It would be really helpful if people could review and provide feedback on this plan. There's one major open issue highlighted in the wiki page. We're planning to adopt a centralized revocation list model for CA certificates, which we're calling OneCRL. (Conceptually similar to Chrome's CRLsets.) In addition to covering CA certifcates, we're also considering covering some end-entity (EE) certificates with OneCRL too. But there are some drawbacks to this approach, so it's not certain that we will include this in the final plan. Feedback on this point would be especially valuable. Thanks a lot, --Richard [1] https://wiki.mozilla.org/CA:ImprovingRevocation [2] https://www.imperialviolet.org/2012/02/05/crlsets.html -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
DANE will never happen, let's just acknowledge that, if for no other reason
than DNSSEC will never happen. It will take years to get enough support for
DANE (by both browsers and websites) to even judge how well it works. And
there is no guarantee it will work that well.
OneCRL itself will be of limited impact because it does not cover end entities.
We should acknowledge that there is no possible way to come up with a list of
end entities because in reality *all* entities need that protection. I know I
rail on this a lot but it's because I've seen the damage it causes.
Regarding the trustworthiness of CA's, there is room for improvement here in
terms of how we choose to evaluate the CA's and enforce the ideas of security
and privacy. We've talked about this before and while I think Kathleen is
interested in doing something I'm not sure how much of an appetite the larger
Mozilla has (i.e. lawyers). There's probably an issue of time and staff
availability.
Original Message
From: Sebastian Wiesinger
Sent: Thursday, August 7, 2014 2:28 AM
To: dev-security-policy@lists.mozilla.org
Subject: Re: New wiki page on certificate revocation plans
* Ryan Sleevi [2014-08-07 08:33]:
> Hi Sebastian,
>
> While you raise an important issue, the problem(s) OneCRL sets out to
> solve are still problems that need solving, and we should not lose sight.
I agree with that. And I also agree that we should not lose sight. The
difference seems to be what we have set our sights on. :)
> Now, as for the problem you raise ("trusting CAs until you can prove that
> they have done wrong" and "Does not keep CAs from issuing certificates
> that can enable certain entities to mount MITM attacks"), it's important
> to realize and remember that DNSSEC/DANE do not solve these, and in fact,
> in many ways, make it easier. DNSSEC is still a single hierarchy of trust,
> much like CAs, and there's still ample opportunity for malfeasance, and
> there's even more opportunity for key mismanagement and insecure
> cryptographic practices.
DNSSEC also builds a chain of trust but it's a different chain. You
can easily tell if someone is manipulating the chain (because it
breaks) and the root is under control by multiple parties in multiple
countries. If someone tried to rig the system there would be
immediately noticeable effects.
Key mismanagement and insecure practices are a problem for
certificates as well. When adoption of DNSSEC raises people will get
used to it and tools will mature to ease implementation and
maintenance. It's happening already.
> I'm not trying to defend CAs or suggest the problem you raise isn't real,
> but there exist other solutions for this - like Public Key Pinning (which
> Firefox implements) and Certificate Transparency, which offer more
> substantial and meaningful benefits over a DANE-based solution.
Public Key Pinning is something that is good for a hand full of (big)
sites but not really feasible for large scale deployment. DNSSEC/DANE
works for everyone.
Certificate Transparency on the other hand requires additional
infrastructure and active monitoring. With DNSSEC/DANE you need no
additional infrastructure (DNS is required anyway) and it makes little
difference if the browser checks the DANE record or audits the CT log.
Reading the explanation on the CT site
(http://www.certificate-transparency.org/how-ct-works) it looks like
browsers are not even required to check every certificate while DANE
records would be checked for every site/cert.
I don't see the substantial and meaningful benefits to be honest.
> Though DANE seems like a simple solution, it's one filled with errors. And
> if Dan Veditz's and Patrick McManus' replies on the state of OCSP weren't
> depressing, DNSSEC is an order of magnitude more depressing. Important to
> keep in mind when talking "long-term vision", which is practically
> achievable, and what is really "long-long-long term vision", which is more
> theoretical and academic. Like DANE.
DANE is not a simple solution but it will solve the problems we have.
As for academical, right now mail providers start implementing DANE as
MTA software gets support for it. GNUTLS has DANE support and OpenSSL
has at least begun implementation. DNSSEC itself is starting to get
traction so I don't think it would be a very long-long-long term
vision.
Of course we need applications supporting DANE and browsers would be a
"killer feature" to increase deployment.
Regards
Sebastian
--
GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
-- Terry Pratchett, The Fifth Elephant
___
dev-secur
Re: New wiki page on certificate revocation plans
* Ryan Sleevi [2014-08-07 08:33]:
> Hi Sebastian,
>
> While you raise an important issue, the problem(s) OneCRL sets out to
> solve are still problems that need solving, and we should not lose sight.
I agree with that. And I also agree that we should not lose sight. The
difference seems to be what we have set our sights on. :)
> Now, as for the problem you raise ("trusting CAs until you can prove that
> they have done wrong" and "Does not keep CAs from issuing certificates
> that can enable certain entities to mount MITM attacks"), it's important
> to realize and remember that DNSSEC/DANE do not solve these, and in fact,
> in many ways, make it easier. DNSSEC is still a single hierarchy of trust,
> much like CAs, and there's still ample opportunity for malfeasance, and
> there's even more opportunity for key mismanagement and insecure
> cryptographic practices.
DNSSEC also builds a chain of trust but it's a different chain. You
can easily tell if someone is manipulating the chain (because it
breaks) and the root is under control by multiple parties in multiple
countries. If someone tried to rig the system there would be
immediately noticeable effects.
Key mismanagement and insecure practices are a problem for
certificates as well. When adoption of DNSSEC raises people will get
used to it and tools will mature to ease implementation and
maintenance. It's happening already.
> I'm not trying to defend CAs or suggest the problem you raise isn't real,
> but there exist other solutions for this - like Public Key Pinning (which
> Firefox implements) and Certificate Transparency, which offer more
> substantial and meaningful benefits over a DANE-based solution.
Public Key Pinning is something that is good for a hand full of (big)
sites but not really feasible for large scale deployment. DNSSEC/DANE
works for everyone.
Certificate Transparency on the other hand requires additional
infrastructure and active monitoring. With DNSSEC/DANE you need no
additional infrastructure (DNS is required anyway) and it makes little
difference if the browser checks the DANE record or audits the CT log.
Reading the explanation on the CT site
(http://www.certificate-transparency.org/how-ct-works) it looks like
browsers are not even required to check every certificate while DANE
records would be checked for every site/cert.
I don't see the substantial and meaningful benefits to be honest.
> Though DANE seems like a simple solution, it's one filled with errors. And
> if Dan Veditz's and Patrick McManus' replies on the state of OCSP weren't
> depressing, DNSSEC is an order of magnitude more depressing. Important to
> keep in mind when talking "long-term vision", which is practically
> achievable, and what is really "long-long-long term vision", which is more
> theoretical and academic. Like DANE.
DANE is not a simple solution but it will solve the problems we have.
As for academical, right now mail providers start implementing DANE as
MTA software gets support for it. GNUTLS has DANE support and OpenSSL
has at least begun implementation. DNSSEC itself is starting to get
traction so I don't think it would be a very long-long-long term
vision.
Of course we need applications supporting DANE and browsers would be a
"killer feature" to increase deployment.
Regards
Sebastian
--
GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
-- Terry Pratchett, The Fifth Elephant
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
On Wed, August 6, 2014 11:14 pm, Sebastian Wiesinger wrote:
> * Richard Barnes [2014-08-01 04:09]:
> > Hi all,
> >
> > We in the Mozilla PKI team have been discussing ways to improve
> > revocation checking in our PKI stack, consolidating a bunch of ideas
> > from earlier work [1][2] and some maybe-new-ish ideas. I've just
> > pressed "save" on a new wiki page with our initial plan:
> >
> > https://wiki.mozilla.org/CA:RevocationPlan
>
> Hello,
>
> while I appreciate that something is being done, this is another
> band-aid for a system that is falling apart. Revocation is helping
> when you know that a certificate was stolen/abused but does not keep
> CAs from issuing certificates that can enable certain entities to
> mount MITM attacks. It always comes down to trusting the CAs until you
> can prove that they have done wrong.
>
> CAs have lost a lot of trust and while we still depend on them NOW I
> think it would be wise to keep working on better alternatives. When
> looking at the "Long-Range Vision" paragraph on your page I don't see
> that happening. It's rather a collection of band-aids.
>
> There is bug 672239 which would implement DNSSEC DANE to verify
> certificates/keys via DNSSEC secured DNS-Records:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=672239
>
> This bug is essentially abandoned at the moment which is really sad.
> DANE would solve all the trust problems we have right now but it seems
> no one is interested in working on it. That's especially frustrating
> when seeing how much work is now put into the OneCRL stuff.
>
> Regards
>
> Sebastian
>
> --
> GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE)
> 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE
> SCYTHE.
> -- Terry Pratchett, The Fifth Elephant
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
Hi Sebastian,
While you raise an important issue, the problem(s) OneCRL sets out to
solve are still problems that need solving, and we should not lose sight.
Now, as for the problem you raise ("trusting CAs until you can prove that
they have done wrong" and "Does not keep CAs from issuing certificates
that can enable certain entities to mount MITM attacks"), it's important
to realize and remember that DNSSEC/DANE do not solve these, and in fact,
in many ways, make it easier. DNSSEC is still a single hierarchy of trust,
much like CAs, and there's still ample opportunity for malfeasance, and
there's even more opportunity for key mismanagement and insecure
cryptographic practices.
I'm not trying to defend CAs or suggest the problem you raise isn't real,
but there exist other solutions for this - like Public Key Pinning (which
Firefox implements) and Certificate Transparency, which offer more
substantial and meaningful benefits over a DANE-based solution.
Though DANE seems like a simple solution, it's one filled with errors. And
if Dan Veditz's and Patrick McManus' replies on the state of OCSP weren't
depressing, DNSSEC is an order of magnitude more depressing. Important to
keep in mind when talking "long-term vision", which is practically
achievable, and what is really "long-long-long term vision", which is more
theoretical and academic. Like DANE.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
* Richard Barnes [2014-08-01 04:09]: > Hi all, > > We in the Mozilla PKI team have been discussing ways to improve > revocation checking in our PKI stack, consolidating a bunch of ideas > from earlier work [1][2] and some maybe-new-ish ideas. I've just > pressed "save" on a new wiki page with our initial plan: > > https://wiki.mozilla.org/CA:RevocationPlan Hello, while I appreciate that something is being done, this is another band-aid for a system that is falling apart. Revocation is helping when you know that a certificate was stolen/abused but does not keep CAs from issuing certificates that can enable certain entities to mount MITM attacks. It always comes down to trusting the CAs until you can prove that they have done wrong. CAs have lost a lot of trust and while we still depend on them NOW I think it would be wise to keep working on better alternatives. When looking at the "Long-Range Vision" paragraph on your page I don't see that happening. It's rather a collection of band-aids. There is bug 672239 which would implement DNSSEC DANE to verify certificates/keys via DNSSEC secured DNS-Records: https://bugzilla.mozilla.org/show_bug.cgi?id=672239 This bug is essentially abandoned at the moment which is really sad. DANE would solve all the trust problems we have right now but it seems no one is interested in working on it. That's especially frustrating when seeing how much work is now put into the OneCRL stuff. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
On 8/4/2014 10:16 AM, Erwann Abalea wrote: > I imagine you have access to more detailed information (OCSP URL, > date/time, user location, ...), could some of it be open? All of our telemetry data is open as far as I know. Because of privacy concerns we only collect aggregate stats from users, nothing as specific as URLs. Here's an example of the kind of data Patrick was using: http://telemetry.mozilla.org/#filter=release%2F31%2FCERT_VALIDATION_HTTP_REQUEST_SUCCEEDED_TIME&aggregates=multiselect-all!Submissions!Mean!5th%20percentile!25th%20percentile!median!75th%20percentile!95th%20percentile&evoOver=Builds&locked=true&sanitize=true&renderhistogram=Graph (or http://mzl.la/1qXOu8u ) Feel free to play with the many options for release and type of data gathered. You can look at your own local data at about:telemetry (the cert_validation items are in the "Histograms" section). -Dan Veditz ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: New wiki page on certificate revocation plans
I think most CAs use CDNs to help serve OCSP responses quite fast and reliably. A breakdown of failure rates based on certificate provider could provide insight on what's going on. Is gathering this information too close to violating a user's privacy for Mozilla? Any chance of peering into this data further? Jeremy -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] On Behalf Of Peter Bowen Sent: Tuesday, August 5, 2014 10:18 AM To: Gervase Markham Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: New wiki page on certificate revocation plans On Tue, Aug 5, 2014 at 2:02 AM, Gervase Markham wrote: > On 04/08/14 18:16, Erwann Abalea wrote: >> OCSP is painful and costly to optimize, x509labs shows great >> availability and good performance for most CA/location combination, >> but this is in contradiction with real user measurements. Why, and >> how? > > Good question. Perhaps the point is that consumer internet connections > are a lot flakier than the one x509labs uses. It is also possible that x509labs is requesting OCSP response for the same cert over and over which means it is getting edge-cached replies. Users request responses for random certs, which could include certs just issued or rarely seen. Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
On Tue, Aug 5, 2014 at 2:02 AM, Gervase Markham wrote: > On 04/08/14 18:16, Erwann Abalea wrote: >> OCSP is painful and costly to optimize, x509labs shows great >> availability and good performance for most CA/location combination, >> but this is in contradiction with real user measurements. Why, and >> how? > > Good question. Perhaps the point is that consumer internet connections > are a lot flakier than the one x509labs uses. It is also possible that x509labs is requesting OCSP response for the same cert over and over which means it is getting edge-cached replies. Users request responses for random certs, which could include certs just issued or rarely seen. Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
On 04/08/14 18:16, Erwann Abalea wrote: > I imagine you have access to more detailed information (OCSP URL, > date/time, user location, ...), could some of it be open? Not necessarily; I suspect this data was gathered using Firefox Telemetry, where we try very hard to avoid violating a user's privacy. Aggregate pass/fail stats (and even failure reasons) are one thing; details of sites visited are another. It could be that we could break it down by CA (top level domain) without significant privacy intrusion, as most CAs secure many websites, but I suspect it would require more mods to Firefox to do that. > OCSP is painful and costly to optimize, x509labs shows great > availability and good performance for most CA/location combination, > but this is in contradiction with real user measurements. Why, and > how? Good question. Perhaps the point is that consumer internet connections are a lot flakier than the one x509labs uses. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
On 04/08/14 18:44, Jesper Kristensen wrote: > I agree that it would not be relevant for the traditional intermediate > CA certificates in the near future for this reason. I was thinking of > name constrained sub-CAs, which on some aspects are more similar to EE > certs than CA certs. OK. Let's assume for a moment that there is someone out there who wants to do this. Can anyone think of a reason why allowing short-lived intermediates is more risky than allowing short-lived EE certs? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
I agree that some of this performance data is concerning but I'm not ready to give up on OCSP just yet because I don't see any choice in the matter: OCSP hard fail has to be done. The fact that end entity certs can not be revoked is a major gap in Internet security right now. That gap should be acknowledged in the problem statement (on the wiki page) as either something that will be addressed now or something to be ignored until a later date. I hope we are going to address it now. In contrast, we do have a revocation mechanism for intermediate and root certs called a browser update. Obviously that's reserved for the most egregious cases but it is there and it does work. I imagine someone has a ready example of a non-egregious situation where intermediate revocation is necessary but the only one I can think of is periodic tweaks to cert data...??? The other issue I have with the problem statement is that it lists optimization goals that are separate from actually improving security. I think it's naive to suggest we can move forward without having an effect on latency or memory or privacy or all of the above. Obviously you want to choose a solution that minimizes those measurements, but that's all they represent: ways to evaluate solutions and not problems to be solved in and of themselves. So, let's clarify if end entity certs are in scope for this effort and we'll move forward from there. Thanks. Original Message From: Erwann Abalea Sent: Monday, August 4, 2014 12:17 PM Le lundi 4 août 2014 18:34:50 UTC+2, Patrick McManus a écrit : > Firefox 31 data: > > on desktop the median successful OCSP validation took 261ms, and the 95th > percentile (looking at just the universe of successful ones) was over > 1300ms. 9% of all OCSP requests on desktop timed out completely and aren't > counted in those numbers. > > on mobile the median successful validation was 372ms with the 95th > percentile over 1500ms. 20% of all requests on mobile timed out completely > and aren't counted in those numbers. > > OCSP is brutally painful. This is depressing. I imagine you have access to more detailed information (OCSP URL, date/time, user location, ...), could some of it be open? OCSP is painful and costly to optimize, x509labs shows great availability and good performance for most CA/location combination, but this is in contradiction with real user measurements. Why, and how? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
Den 04-08-2014 kl. 15:16 skrev Gervase Markham: On 02/08/14 15:20, Jesper Kristensen wrote: * Have you considered adding support for multiple ocsp staples to allow stapeling of CA certs? There is a proposed standard for multi-stapling but as far as I remember it's not even finished yet, yet alone implemented and deployed. We decided that we can't wait for it. * Why not allow short-lived CA certs without revocation info, just like EE certs? I'm not sure there are any CAs out there who would like to get their root key out of it secure storage every 3 days. I agree that it would not be relevant for the traditional intermediate CA certificates in the near future for this reason. I was thinking of name constrained sub-CAs, which on some aspects are more similar to EE certs than CA certs. - Jesper Kristensen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
Le lundi 4 août 2014 18:34:50 UTC+2, Patrick McManus a écrit : > Firefox 31 data: > > on desktop the median successful OCSP validation took 261ms, and the 95th > percentile (looking at just the universe of successful ones) was over > 1300ms. 9% of all OCSP requests on desktop timed out completely and aren't > counted in those numbers. > > on mobile the median successful validation was 372ms with the 95th > percentile over 1500ms. 20% of all requests on mobile timed out completely > and aren't counted in those numbers. > > OCSP is brutally painful. This is depressing. I imagine you have access to more detailed information (OCSP URL, date/time, user location, ...), could some of it be open? OCSP is painful and costly to optimize, x509labs shows great availability and good performance for most CA/location combination, but this is in contradiction with real user measurements. Why, and how? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: New wiki page on certificate revocation plans
Thanks Patrick – that’s great information. This high of failure rate is why the CASC and DigiCert are encouraging OCSP stapling as the best way to move forward. Jeremy From: patrick.ducks...@gmail.com [mailto:patrick.ducks...@gmail.com] On Behalf Of Patrick McManus Sent: Monday, August 4, 2014 10:35 AM To: Jeremy Rowley Cc: Matthias Hunstock; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: New wiki page on certificate revocation plans Firefox 31 data: on desktop the median successful OCSP validation took 261ms, and the 95th percentile (looking at just the universe of successful ones) was over 1300ms. 9% of all OCSP requests on desktop timed out completely and aren't counted in those numbers. on mobile the median successful validation was 372ms with the 95th percentile over 1500ms. 20% of all requests on mobile timed out completely and aren't counted in those numbers. OCSP is brutally painful. On Mon, Aug 4, 2014 at 11:19 AM, Jeremy Rowley mailto:jeremy.row...@digicert.com>> wrote: Seems like a lot of anecdotes are being shared with respect to hard fail without a lot of data. Do the browsers have more data on this? Considering the X.509 labs shows nearly 100% availability with response times of about 100 ms, data showing in-depth info on failure rates (and the reasons why) would help drive the discussion in a productive direction. Jeremy -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley<mailto:dev-security-policy-bounces%2Bjeremy.rowley>=digicert@lists.mozilla.org<mailto:digicert@lists.mozilla.org>] On Behalf Of Matthias Hunstock Sent: Monday, August 4, 2014 2:35 AM To: mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: New wiki page on certificate revocation plans Am 01.08.2014 12:11, schrieb simon.zer...@gmail.com<mailto:simon.zer...@gmail.com>: > Where is the evidence that OSCP hard fails and these speed issues are > actually a problem in the real world? Try it on a site with an unknown issuer. The handshake takes at least 30 seconds longer, because thats the time you need to turn off hard fail in the browser UI. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org> https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org> https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
Firefox 31 data: on desktop the median successful OCSP validation took 261ms, and the 95th percentile (looking at just the universe of successful ones) was over 1300ms. 9% of all OCSP requests on desktop timed out completely and aren't counted in those numbers. on mobile the median successful validation was 372ms with the 95th percentile over 1500ms. 20% of all requests on mobile timed out completely and aren't counted in those numbers. OCSP is brutally painful. On Mon, Aug 4, 2014 at 11:19 AM, Jeremy Rowley wrote: > Seems like a lot of anecdotes are being shared with respect to hard fail > without a lot of data. Do the browsers have more data on this? > Considering the X.509 labs shows nearly 100% availability with response > times of about 100 ms, data showing in-depth info on failure rates (and the > reasons why) would help drive the discussion in a productive direction. > > Jeremy > > -Original Message- > From: dev-security-policy [mailto: > dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] > On Behalf Of Matthias Hunstock > Sent: Monday, August 4, 2014 2:35 AM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: New wiki page on certificate revocation plans > > Am 01.08.2014 12:11, schrieb simon.zer...@gmail.com: > > Where is the evidence that OSCP hard fails and these speed issues are > > actually a problem in the real world? > > Try it on a site with an unknown issuer. > > The handshake takes at least 30 seconds longer, because thats the time you > need to turn off hard fail in the browser UI. > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: New wiki page on certificate revocation plans
Seems like a lot of anecdotes are being shared with respect to hard fail without a lot of data. Do the browsers have more data on this? Considering the X.509 labs shows nearly 100% availability with response times of about 100 ms, data showing in-depth info on failure rates (and the reasons why) would help drive the discussion in a productive direction. Jeremy -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] On Behalf Of Matthias Hunstock Sent: Monday, August 4, 2014 2:35 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: New wiki page on certificate revocation plans Am 01.08.2014 12:11, schrieb simon.zer...@gmail.com: > Where is the evidence that OSCP hard fails and these speed issues are > actually a problem in the real world? Try it on a site with an unknown issuer. The handshake takes at least 30 seconds longer, because thats the time you need to turn off hard fail in the browser UI. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
On 04/08/14 14:16, Gervase Markham wrote: On 02/08/14 15:20, Jesper Kristensen wrote: * Have you considered adding support for multiple ocsp staples to allow stapeling of CA certs? There is a proposed standard for multi-stapling but as far as I remember it's not even finished yet, yet alone implemented and deployed. We decided that we can't wait for it. FWIW, it's a Standards Track RFC now. http://tools.ietf.org/html/rfc6961 I'm not aware of any implementations though. * Why not allow short-lived CA certs without revocation info, just like EE certs? I'm not sure there are any CAs out there who would like to get their root key out of it secure storage every 3 days. Ouch. Painful. * While must-staple and short-lived certificates seem to be scalable solutions, OneCRL seems to be a hack needed to make things work in the current situation. It would be nice if this could be explicitly stated, and even better if you could declare it as a temporary solution intended to be used only until more scalable solutions are specced, implemented and deployed. It's not a temporary solution for intermediate certs. Well, perhaps it's possible that multi-stapling could eventually supplant it (if TCP init windows also enlarge) but I don't think it's really necessary to speculate on that yet. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
On 02/08/14 15:20, Jesper Kristensen wrote: > * Have you considered adding support for multiple ocsp staples to allow > stapeling of CA certs? There is a proposed standard for multi-stapling but as far as I remember it's not even finished yet, yet alone implemented and deployed. We decided that we can't wait for it. > * Why not allow short-lived CA certs without revocation info, just like > EE certs? I'm not sure there are any CAs out there who would like to get their root key out of it secure storage every 3 days. > * While must-staple and short-lived certificates seem to be scalable > solutions, OneCRL seems to be a hack needed to make things work in the > current situation. It would be nice if this could be explicitly stated, > and even better if you could declare it as a temporary solution intended > to be used only until more scalable solutions are specced, implemented > and deployed. It's not a temporary solution for intermediate certs. Well, perhaps it's possible that multi-stapling could eventually supplant it (if TCP init windows also enlarge) but I don't think it's really necessary to speculate on that yet. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
I am generally in favour of this plan - I think it's the right way to go. I am not sure we will ever get to hard-fail for plain OCSP, but I am very happy for that to be a data-driven decision somewhere down the line. On 01/08/14 03:07, Richard Barnes wrote: > There's one major open issue highlighted in the wiki page. We're > planning to adopt a centralized revocation list model for CA > certificates, which we're calling OneCRL. (Conceptually similar to > Chrome's CRLsets.) In addition to covering CA certifcates, we're > also considering covering some end-entity (EE) certificates with > OneCRL too. But there are some drawbacks to this approach, so it's > not certain that we will include this in the final plan. Feedback on > this point would be especially valuable. I think we should _not_ try and add EE certs (beyond high-profile misissuances) to OneCRL. Here are my reasons, some of which are already noted in the wiki page: * The number of certificates involved means that either the data set is of large size (bad for download and disk performance) or we use a Bloom filter or equivalent which has a false positive rate. This would be such that if a given cert was a false positive, it would be a false positive for every user all the time, until the unrelated revoked cert it was false-positived to fell out of the filter, e.g. by expiring. This means that if Fred owns fred.com and Joe owns joe.com, and joe.com's cert happens to be a Bloom match for a revoked cert, joe.com will have worse performance than fred.com (because every Firefox user will end up doing a hard-fail live OCSP lookup) in a way which is not obvious to Joe. This random aspect to the performance of the solution is not good. * The Bloom filter part is extra engineering which is not needed for the intermediate-only version. Even if the data is transmitted together, OneCRL effectively becomes TwoCRLs, one for intermediates and one for EEs, which work differently. We need to trade off this extra engineering requirement against the priority of the many other things we'd like to be doing. * If we put the EE CRLs of all publicly-trusted CAs into OneCRL, we have a significant information management issue for all the changing data. If we don't, we have to make decisions about who is in and who is out. Whatever we decide and however, the people who end up out suffer a performance (and therefore market) disadvantage for their certs. We are effectively playing favourites. I.e. we could be open and transparent, but it's impossible to be neutral. * If a CA has managed to persuade us to include their CRL in OneCRL, they have no incentive to encourage their users to deploy must-staple or short-lived, because revocation already works fine. That has a number of negative effects, including that there will be less pressure for greater ecosystem support for these technologies. Non publicly-trusted CAs can _only_ use these solutions (they can't be in OneCRL) so they need to work and be well supported. So I am of the opinion that must-staple OCSP and short-lived certs together (plus OneCRL for malicious misissuance) should be our solution for EE cert revocation. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
On Mon, Aug 4, 2014 at 12:12 AM, Jeremy Rowley wrote: > Why does OneCRL seem like a hack? Considering how infrequently intermediates > and roots are revoked, OneCRL seems like a satisfactory way to provide this > information long-term, provided that the certs are removed from OneCRL at > some point. I'd think they could safely remove the OneCRL certs after the > listed cert expires. For EE, OneCRL is only necessary where the other > methods of revocation are considered insufficient. If hard-fail OCSP is > turned on (the last point), then OneCRL for EE certs becomes obsolete. Hack or not, its very important to check revocation there. We don't have armed guards at the data centers and if we did any attacker could easily come with more. The only viable defense here is to make sure that what is being guarded is not worth taking. ATMs are protected the same way - with a dye-pack that explodes on the cash if someone attempts to remove the cartridge. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
- Original Message - > From: "David Huang" > To: mozilla-dev-security-pol...@lists.mozilla.org > Sent: Saturday, August 2, 2014 1:21:58 AM > Subject: Re: New wiki page on certificate revocation plans > > This is great news! > > Regarding the max lifetime threshold of short-lived certificates, we ran > study [1] a while back that indicated the average OCSP validity time was 4 > days (while 87.14% were equal to or less than 7 days). Thus, FWIW, we > suggested a certificate lifetime of 4 days in our paper [2] advocating > short-lived certificates for revocation. > > [1] http://www.internetsociety.org/sites/default/files/12_4.pdf > [2] http://www.w2spconf.com/2012/papers/w2sp12-final9.pdf Very interesting, thanks for sharing! This results are a bit scary though: OCSP responder: Max Validity lifetime http://EVIntl-ocsp.verisign.com 86 days 7 hours http://ocsp.verisign.com 20 days 21 hours How often did they provide responses valid for over a week? -- Regards, Hubert Kario ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
Am 01.08.2014 12:11, schrieb simon.zer...@gmail.com: > Where is the evidence that OSCP hard fails and these > speed issues are actually a problem in the real world? Try it on a site with an unknown issuer. The handshake takes at least 30 seconds longer, because thats the time you need to turn off hard fail in the browser UI. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: New wiki page on certificate revocation plans
Why does OneCRL seem like a hack? Considering how infrequently intermediates and roots are revoked, OneCRL seems like a satisfactory way to provide this information long-term, provided that the certs are removed from OneCRL at some point. I'd think they could safely remove the OneCRL certs after the listed cert expires. For EE, OneCRL is only necessary where the other methods of revocation are considered insufficient. If hard-fail OCSP is turned on (the last point), then OneCRL for EE certs becomes obsolete. Jeremy -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] On Behalf Of Jesper Kristensen Sent: Saturday, August 2, 2014 8:21 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: New wiki page on certificate revocation plans Hi This sounds like a really great plan! Some comments: * Have you considered adding support for multiple ocsp staples to allow stapeling of CA certs? * Why not allow short-lived CA certs without revocation info, just like EE certs? * While must-staple and short-lived certificates seem to be scalable solutions, OneCRL seems to be a hack needed to make things work in the current situation. It would be nice if this could be explicitly stated, and even better if you could declare it as a temporary solution intended to be used only until more scalable solutions are specced, implemented and deployed. - Jesper Kristensen Den 01-08-2014 kl. 04:07 skrev Richard Barnes: > Hi all, > > We in the Mozilla PKI team have been discussing ways to improve revocation > checking in our PKI stack, consolidating a bunch of ideas from earlier work > [1][2] and some maybe-new-ish ideas. I've just pressed "save" on a new wiki > page with our initial plan: > > https://wiki.mozilla.org/CA:RevocationPlan > > It would be really helpful if people could review and provide feedback on > this plan. > > There's one major open issue highlighted in the wiki page. We're planning to > adopt a centralized revocation list model for CA certificates, which we're > calling OneCRL. (Conceptually similar to Chrome's CRLsets.) In addition to > covering CA certifcates, we're also considering covering some end-entity (EE) > certificates with OneCRL too. But there are some drawbacks to this approach, > so it's not certain that we will include this in the final plan. Feedback on > this point would be especially valuable. > > Thanks a lot, > --Richard > > [1] https://wiki.mozilla.org/CA:ImprovingRevocation > [2] https://www.imperialviolet.org/2012/02/05/crlsets.html > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
Hi This sounds like a really great plan! Some comments: * Have you considered adding support for multiple ocsp staples to allow stapeling of CA certs? * Why not allow short-lived CA certs without revocation info, just like EE certs? * While must-staple and short-lived certificates seem to be scalable solutions, OneCRL seems to be a hack needed to make things work in the current situation. It would be nice if this could be explicitly stated, and even better if you could declare it as a temporary solution intended to be used only until more scalable solutions are specced, implemented and deployed. - Jesper Kristensen Den 01-08-2014 kl. 04:07 skrev Richard Barnes: Hi all, We in the Mozilla PKI team have been discussing ways to improve revocation checking in our PKI stack, consolidating a bunch of ideas from earlier work [1][2] and some maybe-new-ish ideas. I've just pressed "save" on a new wiki page with our initial plan: https://wiki.mozilla.org/CA:RevocationPlan It would be really helpful if people could review and provide feedback on this plan. There's one major open issue highlighted in the wiki page. We're planning to adopt a centralized revocation list model for CA certificates, which we're calling OneCRL. (Conceptually similar to Chrome's CRLsets.) In addition to covering CA certifcates, we're also considering covering some end-entity (EE) certificates with OneCRL too. But there are some drawbacks to this approach, so it's not certain that we will include this in the final plan. Feedback on this point would be especially valuable. Thanks a lot, --Richard [1] https://wiki.mozilla.org/CA:ImprovingRevocation [2] https://www.imperialviolet.org/2012/02/05/crlsets.html ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
This is great news! Regarding the max lifetime threshold of short-lived certificates, we ran study [1] a while back that indicated the average OCSP validity time was 4 days (while 87.14% were equal to or less than 7 days). Thus, FWIW, we suggested a certificate lifetime of 4 days in our paper [2] advocating short-lived certificates for revocation. [1] http://www.internetsociety.org/sites/default/files/12_4.pdf [2] http://www.w2spconf.com/2012/papers/w2sp12-final9.pdf Cheers, David On Thursday, July 31, 2014 7:07:32 PM UTC-7, Richard Barnes wrote: > Hi all, > > > > We in the Mozilla PKI team have been discussing ways to improve revocation > checking in our PKI stack, consolidating a bunch of ideas from earlier work > [1][2] and some maybe-new-ish ideas. I've just pressed "save" on a new wiki > page with our initial plan: > > > > https://wiki.mozilla.org/CA:RevocationPlan > > > > It would be really helpful if people could review and provide feedback on > this plan. > > > > There's one major open issue highlighted in the wiki page. We're planning to > adopt a centralized revocation list model for CA certificates, which we're > calling OneCRL. (Conceptually similar to Chrome's CRLsets.) In addition to > covering CA certifcates, we're also considering covering some end-entity (EE) > certificates with OneCRL too. But there are some drawbacks to this approach, > so it's not certain that we will include this in the final plan. Feedback on > this point would be especially valuable. > > > > Thanks a lot, > > --Richard > > > > [1] https://wiki.mozilla.org/CA:ImprovingRevocation > > [2] https://www.imperialviolet.org/2012/02/05/crlsets.html ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
- Original Message - > From: "Simon Zerafa" > To: mozilla-dev-security-pol...@lists.mozilla.org > Sent: Friday, 1 August, 2014 8:38:53 PM > Subject: Re: New wiki page on certificate revocation plans > > > I have asked lots of people who use OCSP hard fail if they have ever seen a > hard fail (via Twitter and a group of technical people admittedly) and only > one person reported ever seeing one. then you can count me as another (the ocsp server was down/incorrect) it's a real issue the problem is that we have two types of sites that use TLS: * important sites that have your personal data, your password(s), etc. * sites that have just information you want to read I don't care for validity of certificates, let alone OCSP responses, for the second set of sites. I do very much care for revocation data, used ciphers, etc. for the first set of sites. Unfortunately only the user can say which site is which. If I'm the author of a site, it falls into the first category, if I'm a user, usually to the second. -- Regards, Hubert Kario ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
Hi Ryan, Yes I do represent the real world. I am not fictional or in a test lab somewhere with non production hardware or Internet connectivity :-) I'm looking at that data now and from what it seems to be showing OCSP fails are transitory and short lived. I will look at the numbers to see if this impression is correct or not :-) I do have relatively high bandwidth but even in first world countries it's not always reliable. It fails now and again but fortunately not on a regular basis. My last mile connection was not all that good untill recently. Lots of data errors on the infrastructure. I have asked lots of people who use OCSP hard fail if they have ever seen a hard fail (via Twitter and a group of technical people admittedly) and only one person reported ever seeing one. If we want to check last mile issues then Mozilla could add metrics to the OCSP hard fail as an experiment (assuming it's not there already) to get the data. With such a baseline then it might be possible to ask the right questions. Are OCSP fails and hard fails really the problem they are reported to be? Does Mozilla record such information already? The reason I am asking questions is precisely because we do need good quality data to make informed decisions. Anecdotes are not data but they are observations from which it's possible to start asking the right questions and looking for data to support or refute the topic under discussion. Yes it's possible that for some set of people OCSP hard fail could be an issue but if that is the case then where are they and how and when does it manifest itself? >From what I have seen to date nothing would warrant the removal of OCSP hard >fail from FF on reliability grounds. Adding a separate and supporting CRL solution should not be an issue and would be of some benefit to those FF users who cannot use OCSP hard fail reliability. Regards Simon ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
On Fri, August 1, 2014 3:11 am, simon.zer...@gmail.com wrote: > Hi, > > I would really like to see some hard metrics on OSCP failures and SSL/TLS > setup speed issues. > > I use FF a lot with OSCP hard fail enabled and I don't seem to see any > hard fails. In addition my SSL/TLS sessions seems to be as quick to set up > and responsive as ever. > > Where is the evidence that OSCP hard fails and these speed issues are > actually a problem in the real world? Do you represent the real world? Or are you, more than likely, accessing the Internet from a first-world country, probably with a high-bandwidth connection, and more than likely, from a relatively modern machine? The reference Jeremy pointed you gives you a reasonable understanding of 'raw' server availability, as measured from certain core Internet links. A more reasonable path is to consider the 'last mile' issues - and which there are many (as the endless debates in the US regarding Netflix streaming quality attest to, on one extreme, and as anyone who has been to countries like China, India, Australia, or South Africa can attest to, on another) The plural of anecdote is not data. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: New wiki page on certificate revocation plans
Some information on performance is available here: http://ocspreport.x509labs.com/. You might be able to reach out to them and get the actual data related to number of failed responses. Whether fails and speed are major issues depends on who you ask. Jeremy -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] On Behalf Of simon.zer...@gmail.com Sent: Friday, August 1, 2014 4:12 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: New wiki page on certificate revocation plans Hi, I would really like to see some hard metrics on OSCP failures and SSL/TLS setup speed issues. I use FF a lot with OSCP hard fail enabled and I don't seem to see any hard fails. In addition my SSL/TLS sessions seems to be as quick to set up and responsive as ever. Where is the evidence that OSCP hard fails and these speed issues are actually a problem in the real world? It seems to be repeated that these are major issues, so if that is the case where are the metrics to demonstrate it? Many users such as myself are not happy about the way the Google Chrome project is moving away from best available security towards an incomplete and less secure CRLset method. If you wish to provide a CRLsets type feature that's fine but please don't remove OSCP hard fail. Security is far more important for many users that fractional speed improvements and the illusion of security. Kind Regards Simon Zerafa ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
Hi, I would really like to see some hard metrics on OSCP failures and SSL/TLS setup speed issues. I use FF a lot with OSCP hard fail enabled and I don't seem to see any hard fails. In addition my SSL/TLS sessions seems to be as quick to set up and responsive as ever. Where is the evidence that OSCP hard fails and these speed issues are actually a problem in the real world? It seems to be repeated that these are major issues, so if that is the case where are the metrics to demonstrate it? Many users such as myself are not happy about the way the Google Chrome project is moving away from best available security towards an incomplete and less secure CRLset method. If you wish to provide a CRLsets type feature that's fine but please don't remove OSCP hard fail. Security is far more important for many users that fractional speed improvements and the illusion of security. Kind Regards Simon Zerafa ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
On Jul 31, 2014, at 11:23 PM, Jeremy Rowley wrote: > This is great. Thanks Richard! Thanks go to the whole team. This was very much a group effort. > For OneCRL and the EE certs, establishing parameters around when an EE is > eligible for inclusion would give guidance to CAs about when to report > revocations. Is the OneCRL intended for when the cert is compromised because > of a breach of the CA? Or can high profile domains with stolen keys request > inclusion? There are two types of EE coverage you could imagine: 1. One-off "exceptional" inclusions of individual certificates 2. Bulk inclusion of an EE-issuing CA's CRL I think most of the discussion/controversy here is about the bulk inclusion. One-off exceptional inclusion in OneCRL is something that we will almost certainly do for high-profile cases. By definition, it's a small enough set that the burden to include it will not be that high. Is there a reason to discriminate between the two cases you describe? The earlier proposal for something like OneCRL included some instructions for requesting revocation be distributed through OneCRL. We should produce something similar once we're ready to accept such requests. https://wiki.mozilla.org/CA:ImprovingRevocation#Preload_Revocations_of_Certain_End-Entity_Certificates Hope that helps, --Richard > Jeremy > > -Original Message- > From: dev-security-policy > [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] > On Behalf Of Richard Barnes > Sent: Thursday, July 31, 2014 8:08 PM > To: mozilla-dev-security-pol...@lists.mozilla.org; > mozilla-dev-tech-cry...@lists.mozilla.org > Subject: New wiki page on certificate revocation plans > > Hi all, > > We in the Mozilla PKI team have been discussing ways to improve revocation > checking in our PKI stack, consolidating a bunch of ideas from earlier work > [1][2] and some maybe-new-ish ideas. I've just pressed "save" on a new wiki > page with our initial plan: > > https://wiki.mozilla.org/CA:RevocationPlan > > It would be really helpful if people could review and provide feedback on > this plan. > > There's one major open issue highlighted in the wiki page. We're planning to > adopt a centralized revocation list model for CA certificates, which we're > calling OneCRL. (Conceptually similar to Chrome's CRLsets.) In addition to > covering CA certifcates, we're also considering covering some end-entity (EE) > certificates with OneCRL too. But there are some drawbacks to this approach, > so it's not certain that we will include this in the final plan. Feedback on > this point would be especially valuable. > > Thanks a lot, > --Richard > > [1] https://wiki.mozilla.org/CA:ImprovingRevocation > [2] https://www.imperialviolet.org/2012/02/05/crlsets.html > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: New wiki page on certificate revocation plans
This is great. Thanks Richard! For OneCRL and the EE certs, establishing parameters around when an EE is eligible for inclusion would give guidance to CAs about when to report revocations. Is the OneCRL intended for when the cert is compromised because of a breach of the CA? Or can high profile domains with stolen keys request inclusion? Jeremy -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] On Behalf Of Richard Barnes Sent: Thursday, July 31, 2014 8:08 PM To: mozilla-dev-security-pol...@lists.mozilla.org; mozilla-dev-tech-cry...@lists.mozilla.org Subject: New wiki page on certificate revocation plans Hi all, We in the Mozilla PKI team have been discussing ways to improve revocation checking in our PKI stack, consolidating a bunch of ideas from earlier work [1][2] and some maybe-new-ish ideas. I've just pressed "save" on a new wiki page with our initial plan: https://wiki.mozilla.org/CA:RevocationPlan It would be really helpful if people could review and provide feedback on this plan. There's one major open issue highlighted in the wiki page. We're planning to adopt a centralized revocation list model for CA certificates, which we're calling OneCRL. (Conceptually similar to Chrome's CRLsets.) In addition to covering CA certifcates, we're also considering covering some end-entity (EE) certificates with OneCRL too. But there are some drawbacks to this approach, so it's not certain that we will include this in the final plan. Feedback on this point would be especially valuable. Thanks a lot, --Richard [1] https://wiki.mozilla.org/CA:ImprovingRevocation [2] https://www.imperialviolet.org/2012/02/05/crlsets.html ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
New wiki page on certificate revocation plans
Hi all, We in the Mozilla PKI team have been discussing ways to improve revocation checking in our PKI stack, consolidating a bunch of ideas from earlier work [1][2] and some maybe-new-ish ideas. I've just pressed "save" on a new wiki page with our initial plan: https://wiki.mozilla.org/CA:RevocationPlan It would be really helpful if people could review and provide feedback on this plan. There's one major open issue highlighted in the wiki page. We're planning to adopt a centralized revocation list model for CA certificates, which we're calling OneCRL. (Conceptually similar to Chrome's CRLsets.) In addition to covering CA certifcates, we're also considering covering some end-entity (EE) certificates with OneCRL too. But there are some drawbacks to this approach, so it's not certain that we will include this in the final plan. Feedback on this point would be especially valuable. Thanks a lot, --Richard [1] https://wiki.mozilla.org/CA:ImprovingRevocation [2] https://www.imperialviolet.org/2012/02/05/crlsets.html ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
