Re: New wiki page on certificate revocation plans

[Kurt Roeckx]

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

[Kurt Roeckx]

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

[Gervase Markham]

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

[Jakob Bohm]

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

[Matt Palmer]

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

[Jakob Bohm]

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 

Re: New wiki page on certificate revocation plans

[Daniel Veditz]

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_TIMEaggregates=multiselect-all!Submissions!Mean!5th%20percentile!25th%20percentile!median!75th%20percentile!95th%20percentileevoOver=Buildslocked=truesanitize=truerenderhistogram=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

[Sebastian Wiesinger]

* Richard Barnes rbar...@mozilla.com [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

[Ryan Sleevi]

On Wed, August 6, 2014 11:14 pm, Sebastian Wiesinger wrote:
  * Richard Barnes rbar...@mozilla.com [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

[Sebastian Wiesinger]

* Ryan Sleevi ryan-mozdevsecpol...@sleevi.com [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

[fhw843]

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 ryan-mozdevsecpol...@sleevi.com [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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https

Re: New wiki page on certificate revocation plans

[Rob Stradling]

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

[Richard Barnes]

On Aug 7, 2014, at 9:47 AM, Rob Stradling rob.stradl...@comodo.com 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

[fhw843]

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 rob.stradl...@comodo.com 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

[Gervase Markham]

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

[Peter Bowen]

On Tue, Aug 5, 2014 at 2:02 AM, Gervase Markham g...@mozilla.org 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

[Jeremy Rowley]

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 g...@mozilla.org 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

[Matthias Hunstock]

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

[Hubert Kario]

- Original Message -
 From: David Huang linshunghu...@gmail.com
 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

[Gervase Markham]

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

[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.

 * 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

[Rob Stradling]

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

[Patrick McManus]

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 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=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

[Jeremy Rowley]

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 
jeremy.row...@digicert.commailto: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.rowleymailto:dev-security-policy-bounces%2Bjeremy.rowley=digicert@lists.mozilla.orgmailto:digicert@lists.mozilla.org]
 On Behalf Of Matthias Hunstock
Sent: Monday, August 4, 2014 2:35 AM
To: 
mozilla-dev-security-pol...@lists.mozilla.orgmailto: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.commailto: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.orgmailto:dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.orgmailto: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

[Erwann Abalea]

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

[Jesper Kristensen]

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

[Jeremy Rowley]

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

[David Huang]

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

[Jesper Kristensen]

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

[Ryan Sleevi]

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