[cabfpub] Certificate lifetimes: end state or trajectory?
Gervase Markham
need to come to a conclusion on whether we are aiming to reduce
certificate lifetimes below 27 months in the next few years, or not.
I think it's fair to say that if the Forum passes a ballot on
certificate lifetimes _without_ a roadmap to 13 months (such as the
current ballot 193), then observers can reasonably assume that the Forum
is unlikely to take further steps on reducing lifetimes in the next few
years. Because if we were planning to do that, we would have set out our
roadmap in the relevant ballot in order to give everyone maximum time to
prepare.
According to Ryan's summary, the following members voted No on ballot
185 giving the reason that "13 months is unacceptably short":
CA: DigiCert, Entrust, Izenpe, Quo Vadis, Actalis, Symantec, Trustwave,
CFCA, GDCA
Browser: Apple
It would be useful if those members could say whether 13 months would
still be unacceptably short if the date for introduction of the 13 month
requirement were something like 1st March 2019, 2 years from now.
If we can get consensus that this reduction is OK with a long enough
lead time, that might lead us to a ballot where the max. lifetime was
reduced to 27 months on 1st March 2018, and 13 months on 1st March 2019,
meaning that by 1st May 2020, all unexpired certificates would be of
lifetime 13 months or fewer.
If members feel that even with 2 years lead time, this reduction is
still unacceptable, we should pass ballot 193 or something like it,
thereby indicating to the world that we have no plans for further
reductions in a CAB Forum context.
Gerv
Richard Wang
And "13 months on 1st March 2019" that we have two years to prepare the change that I think it is enough.
This solution is good that meet the CAs and browsers' concern, and give the industry a clear roadmap.
Best Regards,
Richard
Gerv
_______________________________________________
Public mailing list
Pub...@cabforum.org
https://cabforum.org/mailman/listinfo/public
García Jimeno, Oscar
Thanks
.eus GARA !
horregatik orain nire helbide elektronikoa da:
por eso mi dirección de correo electrónico ahora es: o-ga...@izenpe.eus
Oscar García
CISSP, CISM
ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ!
ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente.
-----Mensaje original-----
De: Public [mailto:public-...@cabforum.org] En nombre de Gervase Markham via Public
Enviado el: viernes, 03 de marzo de 2017 10:15
Para: CABFPub
CC: Gervase Markham
Asunto: [cabfpub] Certificate lifetimes: end state or trajectory?
Gerv
Phillip Hallam-Baker
reason it was soundly rejected, I can't see it being likely that there will
be a near term change in sentiment.
Going from 2 years to 1 or even 90 days makes no significant difference to
security in my view. The only way to make a significant difference is to
take the vulnerability window down to 3 days or less by requiring effective
revocation.
My goal is to eventually reduce the vulnerability window to 1 day for
ordinary revocation and 15 minutes for extraordinary revocation.
But even if we achieved that through short lived certs of 24 hours it would
still take three to five years to effect major changes in the Web
infrastructure. The Web is the largest and most complex machine that has
been or will ever be built by humans. And no single person or company is in
charge of it.
Right now we have a situation where certain people are loudly asserting that
we can't do effective revocation because it requires X and simultaneously
asserting that we must make other measures that are less effective but also
require X.
If we want to develop a roadmap, we should put everything on the table and
perform a cost/benefit analysis.
* The security benefits
* The impact on legacy browsers that can't be updated
* The latency impact on browser users
* The impact on site administrators
CAs and Browser providers naturally have different views on the last as site
administrators are our customers. So a proposal that requires hundreds of
thousands of site admins to spend hours or days implementing a change is a
major issue for CAs.
Going to my customers with a statement 'we have decided you have to do this
work because we agreed to it' is probably not happening.
Going to my customers with a statement 'You have to do this work because
certain browser providers decided to make you' is a different statement. It
is also a statement that I have been making people who are much higher in
the management chains of certain companies aware would be their PR issue,
not ours.
Rather than coercing the site administrators and arguing over who is going
to be blamed for using the stick, I suggest we should try the carrot
approach.
What if the deal we offered site administrators was 'if you want the very
fastest site response, etc. then implement these measures.'
I think that would go down a lot better.
-----Original Message-----
From: Public [mailto:public-...@cabforum.org] On Behalf Of Gervase
Markham via Public
Sent: Friday, March 3, 2017 4:15 AM
To: CABFPub <pub...@cabforum.org>
Cc: Gervase Markham <ge...@mozilla.org>
Gerv
Gervase Markham
On 03/03/17 16:14, Phillip Hallam-Baker wrote:
> Going from 2 years to 1 or even 90 days makes no significant difference to
> security in my view. The only way to make a significant difference is to
> take the vulnerability window down to 3 days or less by requiring effective
> revocation.
You keep making this point, but it assumes incorrectly that the reason
for reducing certificate lifetimes is to reduce the "vulnerability
window". That's simply not the case. No-one is arguing "we should reduce
certificate lifetimes because then we don't have to bother with
revocation at all".
> Right now we have a situation where certain people are loudly asserting that
> we can't do effective revocation because it requires X and simultaneously
> asserting that we must make other measures that are less effective but also
> require X.
What is X in your example?
I would be more open to listening to your thoughts on revocation if
found you could clearly articulate all the reasons for Mozilla's
position regarding why we think OCSP hard-fail for every cert is not
possible (even if you didn't agree with it). Then you could tell me how
whatever plans you have address all those issues. But regardless, let's
do that in another thread, because this one is not about revocation.
> CAs and Browser providers naturally have different views on the last as site
> administrators are our customers. So a proposal that requires hundreds of
> thousands of site admins to spend hours or days implementing a change is a
> major issue for CAs.
This is another of those "if this is true, something is very wrong"
moments. If it takes hours or days to replace a cert, something is very
wrong. Moving from 2 years to 1 year makes it happen twice as often. If
it's taking that long, this customer needs automation whether certs are
2 years or 1 year in duration.
Gerv
Phillip Hallam-Baker
> Hi Philip,
>
> On 03/03/17 16:14, Phillip Hallam-Baker wrote:
> > Going from 2 years to 1 or even 90 days makes no significant
> > difference to security in my view. The only way to make a significant
> > difference is to take the vulnerability window down to 3 days or less
> > by requiring effective revocation.
>
> You keep making this point, but it assumes incorrectly that the reason for
> reducing certificate lifetimes is to reduce the "vulnerability window". That's
> simply not the case. No-one is arguing "we should reduce certificate lifetimes
> because then we don't have to bother with revocation at all".
I accept that the reasons motivating the proposal are different.
But when we get into discussions, the security reason for doing it is so that 'bad certs' are valid for shorter times. Whether you like it or not, that is a validity argument by definition.
If people will promise to say that the only benefit to the proposal is to give the industry more time to procrastinate over changes, I will be happy to stop bringing up revocation.
Since the proponents keep coming back with arguments that are a consequence of the lack of hard fail OCSP or demanding stapling, I will keep addressing the technical benefits.
> > Right now we have a situation where certain people are loudly
> > asserting that we can't do effective revocation because it requires X
> > and simultaneously asserting that we must make other measures that are
> > less effective but also require X.
>
> What is X in your example?
Change in site administration infrastructure.
We have been promoting stapling for quite a few years now and we are quite likely at a point where we could say 'you must turn on stapling'.
Requiring sites to adopt any other technology that is not already widely supported in the next 24 or even 48 months is a very much bigger ask.
> I would be more open to listening to your thoughts on revocation if found
> you could clearly articulate all the reasons for Mozilla's position regarding
> why we think OCSP hard-fail for every cert is not possible (even if you didn't
> agree with it). Then you could tell me how whatever plans you have address
> all those issues. But regardless, let's do that in another thread, because this
> one is not about revocation.
We are aware of those objections and as you say this is not the place to discuss them right now.
But the fact remains that if you the Browser providers are not willing to require sites turn on stapling or suffer a performance penalty because you think it is infeasible then the same objection holds for demands the same sites go to automated issue to support shorter lifetimes.
> > CAs and Browser providers naturally have different views on the last
> > as site administrators are our customers. So a proposal that requires
> > hundreds of thousands of site admins to spend hours or days
> > implementing a change is a major issue for CAs.
>
> This is another of those "if this is true, something is very wrong"
> moments. If it takes hours or days to replace a cert, something is very wrong.
> Moving from 2 years to 1 year makes it happen twice as often. If it's taking
> that long, this customer needs automation whether certs are
> 2 years or 1 year in duration.
There are many, many sites where the very least change requires considerable process. And the reason for that is that without that process you end up in situations like the one that caused both my doorbells to fail for 4 hours this week after a cloud service provider had an outage.
The problem that I don't think you appreciate is that turning on automation is not automatic. Certainly not in an environment where high levels of reliability are demanded. Running random Perl scripts off the net is not the way a lot of places operate and those that do are likely to create problems.
Gervase Markham
> But when we get into discussions, the security reason for doing it is
> so that 'bad certs' are valid for shorter times. Whether you like it
> or not, that is a validity argument by definition.
But it's not a problem that can be solved by revocation. Well,
technically you could solve the problem that e.g. "we've issued 2
million 39-month certs using an algorithm we now known to be broken" by
revoking them all, but in practice the level of disruption is too great.
However, making the max validity period 13 months means that people will
be planning to rotate their certs on a yearly basis anyway.
Revocation works for misissuance. It doesn't work for "this practice
everyone was doing wasn't optimal/algorithm everyone used was bad, and
we'd like to stop relying on certs which used it as quickly as we can".
>>> Right now we have a situation where certain people are loudly
>>> asserting that we can't do effective revocation because it
>>> requires X and simultaneously asserting that we must make other
>>> measures that are less effective but also require X.
>>
>> What is X in your example?
>
> Change in site administration infrastructure.
>
> We have been promoting stapling for quite a few years now and we are
> quite likely at a point where we could say 'you must turn on
> stapling'.
My understanding is that both Apache and nginx are not at a stage where
stapling "just works". And that's not for want of trying; we've paid for
work on Apache to try and make this better.
> But the fact remains that if you the Browser providers are not
> willing to require sites turn on stapling or suffer a performance
> penalty because you think it is infeasible then the same objection
> holds for demands the same sites go to automated issue to support
> shorter lifetimes.
You are right that we aren't willing to slow down 85%+ of the Internet
for our users (and block 1-3% of it) in order to drive a behavioural
change among sites, yes.
> There are many, many sites where the very least change requires
> considerable process. And the reason for that is that without that
> process you end up in situations like the one that caused both my
> doorbells to fail for 4 hours this week after a cloud service
> provider had an outage.
I'm so tempted to say that this is yet another "if this is true,
something is very wrong" moment ;-).
Gerv
Phillip Hallam-Baker
> > But when we get into discussions, the security reason for doing it is
> > so that 'bad certs' are valid for shorter times. Whether you like it
> > or not, that is a validity argument by definition.
>
> But it's not a problem that can be solved by revocation. Well, technically you
> could solve the problem that e.g. "we've issued 2 million 39-month certs
> using an algorithm we now known to be broken" by revoking them all, but in
> practice the level of disruption is too great.
> However, making the max validity period 13 months means that people will
> be planning to rotate their certs on a yearly basis anyway.
And it isn't a problem that can be solved by shortening the certificate lifetime either.
We are dealing with a complex infrastructure in which it currently takes about ten years to deploy a new algorithm.
It is not just a matter of updating the browsers or the Web sites. HTTP is used in a vast number of IoT devices that are currently fire and forget. Many have no update capabilities at all. Others can be upgraded with no controls on the upgrade process. It is a mess and not one that is going to be solved by CABForum fiat.
Certificate lifetime is currently much shorter than its place on the critical path for algorithm deployment demands.
> > We have been promoting stapling for quite a few years now and we are
> > quite likely at a point where we could say 'you must turn on
> > stapling'.
>
> My understanding is that both Apache and nginx are not at a stage where
> stapling "just works". And that's not for want of trying; we've paid for work
> on Apache to try and make this better.
So based on that experience, how long before we could require automated certificate management?
> > But the fact remains that if you the Browser providers are not willing
> > to require sites turn on stapling or suffer a performance penalty
> > because you think it is infeasible then the same objection holds for
> > demands the same sites go to automated issue to support shorter
> > lifetimes.
>
> You are right that we aren't willing to slow down 85%+ of the Internet for our
> users (and block 1-3% of it) in order to drive a behavioural change among
> sites, yes.
That is understood. We have to apply technical means to reduce the penalty.
> > There are many, many sites where the very least change requires
> > considerable process. And the reason for that is that without that
> > process you end up in situations like the one that caused both my
> > doorbells to fail for 4 hours this week after a cloud service provider
> > had an outage.
>
> I'm so tempted to say that this is yet another "if this is true, something is very
> wrong" moment ;-).
Just the one thing very wrong?
Geoff Keating
> On 3 Mar 2017, at 1:14 am, Gervase Markham via Public <pub...@cabforum.org> wrote:
>
> It would be useful if those members could say whether 13 months would
> still be unacceptably short if the date for introduction of the 13 month
> requirement were something like 1st March 2019, 2 years from now.
If we’re setting out a roadmap, and the end point of the road map is 13 months, I would ask what 13 months gives us that 27 or 39 doesn’t; and why stop at 13 months rather than some other number? Why not keep going all the way to 90 days or 30 days or 7 days?
I’d rather be having a discussion about the end state. If the vision is that all devices should automatically acquire and renew certificates, when is a practical date for that vision to be realized? And what benefits does it give that makes it worth the substantial effort to implement?
Kirk Hall
In my view, for revocation checking the choices are not "hard fail for non-response" (which no one is asking for) or "no revocation checking at all".
-----Original Message-----
From: Public [mailto:public-...@cabforum.org] On Behalf Of Gervase Markham via Public
Sent: Friday, March 3, 2017 8:46 AM
To: Phillip Hallam-Baker <phil...@comodo.com>; 'CA/Browser Forum Public Discussion List' <pub...@cabforum.org>
Cc: Gervase Markham <ge...@mozilla.org>
Hi Philip,
Gerv
_______________________________________________
Peter Bowen
On Mar 3, 2017, at 9:54 AM, Phillip Hallam-Baker via Public <pub...@cabforum.org> wrote:From: Gervase Markham [mailto:ge...@mozilla.org]On 03/03/17 17:25, Phillip Hallam-Baker wrote:But when we get into discussions, the security reason for doing it is
so that 'bad certs' are valid for shorter times. Whether you like it
or not, that is a validity argument by definition.
But it's not a problem that can be solved by revocation. Well, technically you
could solve the problem that e.g. "we've issued 2 million 39-month certs
using an algorithm we now known to be broken" by revoking them all, but in
practice the level of disruption is too great.
However, making the max validity period 13 months means that people will
be planning to rotate their certs on a yearly basis anyway.
And it isn't a problem that can be solved by shortening the certificate lifetime either.
We are dealing with a complex infrastructure in which it currently takes about ten years to deploy a new algorithm.
Geoff Keating
> On 3 Mar 2017, at 3:27 pm, Peter Bowen via Public <pub...@cabforum.org> wrote:
>
> I think that “algorithm” should be taken in a broader context that just cryptographic algorithm. For example, when looking at the validation method that allows domain validation via a change on a website, we found several issues:
>
> - A number of websites will echo back the URI path in the response body (https://cabforum.org/pipermail/public/2016-April/007504.html) and will return HTTP 200 for any path. This means a validation process that is “ensure that GET /<long random value>.txt returns 200” or “GET /<long random value>.txt returns <long random value>” is vulnerable
> - A number of websites allow users to create content (e.g forums). This means any validation process that is “here is <long random value>. Put it on your web server and give us the path to it” is vulnerable
>
> The changes in ballot 169 attempt to mitigate these risks, but there are lots of existing certs out there that passed validation using some variant of one of these methods. One option is to just require CAs revoke all existing certificates that were issued using website control validation, but this would be highly impactful to customers. The other option is to cease using the vulnerable method and let the existing certs expire. In this case the maximum validity period defines how long potentially mis-issued certificates are live.
>
> Assuming we agree on the principle of least surprise, revocation is a far worse choice than leaving the certificate live until expiration. However we still want bound how long this transition period will last. In most cases, the validity period of certificates is the largest driver of the duration of the transition period; by shortening it we shorten there transition period. So I disagree with your premise; there is a security benefit to shorter certificates, just like there is a security benefit to more frequent software updates.
I thought this was interesting in the context of automatically updating certificates. Imagine the scenario where most certificates are 90-day, automatically requested and validated, using a method like the broken one above. We find the problem described above and want to make a change. So, give a 6 month implementation period for CAs, and 9 months later all unexpired certificates have been issued with the new method, right? No! Now not only must CAs make a change, but millions of devices must make a change, which puts the provided token in a different place in their web site. Some will take years to have the change deployed. Some custom systems will need to do it as part of a regular release cycle, and might want engineering resources scheduled a year in advance. Some abandoned devices might never make the change and need to be upgraded by replacement, or need a manual exception method.
Gervase Markham
> If we’re setting out a roadmap, and the end point of the road map is
> 13 months, I would ask what 13 months gives us that 27 or 39 doesn’t;
> and why stop at 13 months rather than some other number? Why not
> keep going all the way to 90 days or 30 days or 7 days?
Well, because people's crystal balls are only so clear, and 7 days would
be a long, long way away even if it were a target.
I am asserting that if we pass a "27 months only" ballot now, people
would be very surprised if in six months time we then published a
"...and 13 months a little while after that" ballot. If in fact you
think this wouldn't surprise people and would be totally fine, say so.
But my suggestion is that if we plan to continue reducing, we need to
say so.
> I’d rather be having a discussion about the end state. If the vision
> is that all devices should automatically acquire and renew
> certificates, when is a practical date for that vision to be
> realized?
No-one knows yet. Which is why we can't have a dated roadmap to it.
> And what benefits does it give that makes it worth the
> substantial effort to implement?
Many have been articulated already; did you miss them, or are you asking
for them to be re-summarised?
Gerv
Gervase Markham
> Gerv - on the issue of revocation checking, not everyone is asking
> for browsers to turn on hard fail if the browser fails to get a
> response to a revocation query in a reasonable time.. We would be
> very happy to continue with soft fail - but please, turn on
> revocation checking again. Even if the browser doesn't get a timely
> response in (say) 10% of queries, if it does receive a response
> "revoked" in the other 90% of queries, and displays that to users,
> that would be a great increase in user security.
As noted by Adam Langley, "[S]oft-fail revocation checks are like a
seat-belt that snaps when you crash. Even though it works 99% of the
time, it's worthless because it only works when you don't need it."
https://www.imperialviolet.org/2012/02/05/crlsets.html
This is because "[A]n attacker who can intercept HTTPS connections [so
as to use their bad cert for an MITM] can also make online revocation
checks appear to fail and so bypass the revocation checks."
Gerv
Rich Smith
-----Original Message-----
From: Public [mailto:public-...@cabforum.org] On Behalf Of Gervase
Markham via Public
Sent: Friday, March 10, 2017 6:37 AM
To: Kirk Hall <Kirk...@entrustdatacard.com>; CA/Browser Forum Public
Discussion List <pub...@cabforum.org>; Phillip Hallam-Baker
<phil...@comodo.com>
Cc: Gervase Markham <ge...@mozilla.org>
Subject: Re: [cabfpub] Certificate lifetimes: end state or trajectory?
https://www.imperialviolet.org/2012/02/05/crlsets.html
Gerv
Ryan Sleevi
You can make the move to hard fail any time you like.
Robin Alden
infallible and you cannot quote his blog as incontrovertible fact.
It is not true that it only works when you don't need it.
It is true that it doesn't always work when you need it, but that is not the
same thing by any manner of means.
> This is because "[A]n attacker who can intercept HTTPS connections [so
> as to use their bad cert for an MITM] can also make online revocation
> checks appear to fail and so bypass the revocation checks."
Maybe. Maybe not.
It depends where the attacker is situated.
If you're in the same coffee shop as him, you're toast.
If the attacker is sitting in the data center that hosts the site with the
cert, then the attacker can't touch the path between the client and the CA,
so you've overstated the case.
The perfect can be the enemy of the good.
Regards
Robin Alden
Comodo
> -----Original Message-----
> From: Public [mailto:public-...@cabforum.org] On Behalf Of Gervase
> Markham via Public
> Sent: 10 March 2017 12:37
> To: Kirk Hall <Kirk...@entrustdatacard.com>; CA/Browser Forum Public
> Discussion List <pub...@cabforum.org>; Phillip Hallam-Baker
> <phil...@comodo.com>
> Cc: Gervase Markham <ge...@mozilla.org>
> Subject: Re: [cabfpub] Certificate lifetimes: end state or trajectory?
>
Ben Wilson
-----Original Message-----
From: Public [mailto:public-...@cabforum.org] On Behalf Of Robin Alden
via Public
Ryan Sleevi
Ryan Sleevi
It would be useful if those members could say whether 13 months would
still be unacceptably short if the date for introduction of the 13 month
requirement were something like 1st March 2019, 2 years from now.
If we can get consensus that this reduction is OK with a long enough
lead time, that might lead us to a ballot where the max. lifetime was
reduced to 27 months on 1st March 2018, and 13 months on 1st March 2019,
meaning that by 1st May 2020, all unexpired certificates would be of
lifetime 13 months or fewer.
If members feel that even with 2 years lead time, this reduction is
still unacceptable, we should pass ballot 193 or something like it,
thereby indicating to the world that we have no plans for further
reductions in a CAB Forum context.
Gervase Markham
> So now that we've had our lovely chat about revocation, can we go back
> to the substance of the question:
Yes; it would be great if, without disappearing down another
revocation-related rathole, we could get some sense of the answer to the
below:
> It would be useful if those members could say whether 13 months would
> still be unacceptably short if the date for introduction of the 13 month
> requirement were something like 1st March 2019, 2 years from now.
> If we can get consensus that this reduction is OK with a long enough
> lead time, that might lead us to a ballot where the max. lifetime was
> reduced to 27 months on 1st March 2018, and 13 months on 1st March 2019,
> meaning that by 1st May 2020, all unexpired certificates would be of
> lifetime 13 months or fewer.
> If members feel that even with 2 years lead time, this reduction is
> still unacceptable, we should pass ballot 193 or something like it,
> thereby indicating to the world that we have no plans for further
> reductions in a CAB Forum context.
Given the way they voted, I am particularly hoping for input from the
following: DigiCert, Entrust, Izenpe, Quo Vadis, Actalis, Symantec,
Trustwave, CFCA, GDCA and Apple.
Gerv
García Jimeno, Oscar
Thanks
.eus GARA !
horregatik orain nire helbide elektronikoa da:
por eso mi dirección de correo electrónico ahora es: o-ga...@izenpe.eus
Oscar García
CISSP, CISM
ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ!
ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente.
-----Mensaje original-----
De: Public [mailto:public-...@cabforum.org] En nombre de Gervase Markham via Public
Enviado el: miércoles, 15 de marzo de 2017 16:36
Para: CA/Browser Forum Public Discussion List
CC: Gervase Markham
Asunto: Re: [cabfpub] Certificate lifetimes: end state or trajectory?
Gerv
Gervase Markham
On 20/03/17 09:11, García Jimeno, Oscar wrote:
> We consider that this two years phase's roadmap is enough to adapt
> our systems (and try to automatize as much as possible) and to make
> aware our customers of the improvement in security.
Perhaps this is an English-as-a-second-language thing, but it doesn't
seem like your response answers my questions :-( Let me try rephrasing
them less narratively:
* Does Izenpe object to the idea of a 13-month limit on certificates a)
because the previous proposals did not have a long enough lead time, or
b) because you feel 13 months is unacceptable for some other reason?
* If it was proposed to introduce a 13-month limit from 1st March 2019,
which is 2 years away, would you support that?
* If not, please explain why you think the advantages of further
reductions given in previous discussions are not significant enough to
outweigh the customer inconvenience.
Thanks,
Gerv