Short-lived certs

[Gervase Markham]

Short-lived certs are one plank of our future revocation strategy.[0]
Currently, it is not permitted by the CAB Forum Baseline Requirements to
revocation pointers out of a cert, ever. However, this is part of the
big value of short-lived certs, as it's what unlocks their
speed-increasing potential across all browsers. (The logic is that a
3-day expiry misissued cert with no revocation pointers has a similar
risk profile to a 1-year expiry misissued cert where the attacker has
captured a valid 3-day expiry OCSP response they can staple to it).

I've just been reviewing discussions from July 2012 on the CAB Forum
mailing lists about short-lived certs. There was some significant
opposition to removing revocation information from short-lived certs at
the time (although things may be different now, I don't know). I
personally think much of that opposition was mistaken, but the
discussion nevertheless did not result in consensus.

How should we approach the issue of short-lived certs? It seems to me we
can do the following:

0) Try and get a motion passed to change the BRs to allow short-lived
certs to not have any revocation information. This would probably
require us to review the original discussion and make a wiki page
outlining our proposal and rebutting objections. We may still run into
heavy weather. We could also discuss it at the face-to-face.

1) Write an exception in Mozilla's policy that short-lived certs don't
have to have revocation info. This would likely have no effect, because
CAs would want to continue issuing to the BRs.

2) Stop checking revocation information for short-lived certs
unilaterally. This would result in reduced take-up of the idea, because
there would be no advantage in other browsers, and one would still need
to implement all the mechanisms, both at the CA and at the site, for
frequent cert renewals and deployments.

3) Configure Firefox to not bother checking revocation information for
any cert newer than N days. This way, you can "emulate" short-lived
certs by just reissuing an X-year cert every N days or less. It also
'fixes' the clock-skew problem in one direction, because the certs will
still work for users whose clocks are some way in the future (although
their browsers would check revocation).

4) Something else?

Gerv

[0] https://wiki.mozilla.org/CA:RevocationPlan

[Hubert Kario]

----- Original Message -----
> From: "Gervase Markham" <ge...@mozilla.org>
> To: mozilla-dev-s...@lists.mozilla.org
> Sent: Thursday, September 4, 2014 12:21:50 PM
> Subject: Short-lived certs
>
> Short-lived certs are one plank of our future revocation strategy.[0]
> Currently, it is not permitted by the CAB Forum Baseline Requirements to
> revocation pointers out of a cert, ever. However, this is part of the
> big value of short-lived certs, as it's what unlocks their
> speed-increasing potential across all browsers. (The logic is that a
> 3-day expiry misissued cert with no revocation pointers has a similar
> risk profile to a 1-year expiry misissued cert where the attacker has
> captured a valid 3-day expiry OCSP response they can staple to it).

It all depends on the exact definition of "short-lived". If the definition
is basically the same as for OCSP responses or shorter, then yes, they
provide the same security as regular certs with hard fail for OCSP
querying/stapling.

I'm not sure what gives us the removal of revocation info from certificate.

I mean, if the recommendation for PKIX is to not check revocation info
for certificates that have total validity period of less than, say 2 days,
then inclusion or exclusion of AIA extension is secondary.

There's also the must-staple extension in the works, which can be part of
the plan: you either get short lived certs or you get a long lived with
must-staple. They would provide the same security guarantees.

--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Email: hka...@redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

[Gervase Markham]

On 04/09/14 12:52, Hubert Kario wrote:
> It all depends on the exact definition of "short-lived". If the definition
> is basically the same as for OCSP responses or shorter, then yes, they
> provide the same security as regular certs with hard fail for OCSP
> querying/stapling.

The exact definition of "short-lived" is something I want to declare out
of scope for this particular discussion.

> I'm not sure what gives us the removal of revocation info from certificate.

Because there are lots of clients out there who check revocation info
always if the pointers are present. The only way to stop them doing that
(and so realise the speed advantage) is by not putting revocation info
in the cert.

> I mean, if the recommendation for PKIX is to not check revocation info
> for certificates that have total validity period of less than, say 2 days,
> then inclusion or exclusion of AIA extension is secondary.

We can't update all the software in the world to magically follow our
recommendation.

> There's also the must-staple extension in the works, which can be part of
> the plan: you either get short lived certs or you get a long lived with
> must-staple. They would provide the same security guarantees.

It is part of the plan, if you read it :-)
https://wiki.mozilla.org/CA:RevocationPlan

Gerv

[Hubert Kario]

----- Original Message -----
> From: "Gervase Markham" <ge...@mozilla.org>
> To: mozilla-dev-s...@lists.mozilla.org

> Sent: Thursday, September 4, 2014 3:04:33 PM
> Subject: Re: Short-lived certs
>
> On 04/09/14 12:52, Hubert Kario wrote:

> > It all depends on the exact definition of "short-lived". If the definition
> > is basically the same as for OCSP responses or shorter, then yes, they
> > provide the same security as regular certs with hard fail for OCSP
> > querying/stapling.
>

> The exact definition of "short-lived" is something I want to declare out
> of scope for this particular discussion.
>

> > I'm not sure what gives us the removal of revocation info from certificate.
>

> Because there are lots of clients out there who check revocation info
> always if the pointers are present. The only way to stop them doing that
> (and so realise the speed advantage) is by not putting revocation info
> in the cert.

>From what I heard (and my limited personal experience matches), is that
the vast majority of clients not only completely ignore failures in OCSP
retrieval (soft-fail) but completely lack any mechanism for revocation checking
(be it OCSP or CRL).

In fact, that is the main driver behind must-staple.

Can you provide examples to the contrary?

[Rob Stradling]

On 04/09/14 14:04, Gervase Markham wrote:
> On 04/09/14 12:52, Hubert Kario wrote:

>> It all depends on the exact definition of "short-lived". If the definition
>> is basically the same as for OCSP responses or shorter, then yes, they
>> provide the same security as regular certs with hard fail for OCSP
>> querying/stapling.
>

> The exact definition of "short-lived" is something I want to declare out
> of scope for this particular discussion.
>

>> I'm not sure what gives us the removal of revocation info from certificate.
>

> Because there are lots of clients out there who check revocation info
> always if the pointers are present. The only way to stop them doing that
> (and so realise the speed advantage) is by not putting revocation info
> in the cert.

Today, if an end-entity cert contains no AIA->OCSP URL and the server
sends no stapled OCSP response, it's a violation of the BRs. I wonder
if any clients out there would reject the cert in this situation? (I
suspect not, but it's something to watch out for).

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Rob Stradling]

When attempting to access an HTTPS site with an expired cert on Firefox
32, you'll see a "This Connection is Untrusted" page that lets you add
an exception and proceed.

But when attempting to access an HTTPS site with a revoked cert, you'll
see "Secure Connection Failed" and Firefox 32 does NOT let you proceed.

Would it make sense to treat expired certs in the same way as revoked
certs? (And if not, why not?)

On 04/09/14 12:52, Hubert Kario wrote:

> ----- Original Message -----
>> From: "Gervase Markham" <ge...@mozilla.org>
>> To: mozilla-dev-s...@lists.mozilla.org

>> Sent: Thursday, September 4, 2014 12:21:50 PM
>> Subject: Short-lived certs
>>
>> Short-lived certs are one plank of our future revocation strategy.[0]
>> Currently, it is not permitted by the CAB Forum Baseline Requirements to
>> revocation pointers out of a cert, ever. However, this is part of the
>> big value of short-lived certs, as it's what unlocks their
>> speed-increasing potential across all browsers. (The logic is that a
>> 3-day expiry misissued cert with no revocation pointers has a similar
>> risk profile to a 1-year expiry misissued cert where the attacker has
>> captured a valid 3-day expiry OCSP response they can staple to it).
>

> It all depends on the exact definition of "short-lived". If the definition
> is basically the same as for OCSP responses or shorter, then yes, they
> provide the same security as regular certs with hard fail for OCSP
> querying/stapling.
>

> I'm not sure what gives us the removal of revocation info from certificate.
>

> I mean, if the recommendation for PKIX is to not check revocation info
> for certificates that have total validity period of less than, say 2 days,
> then inclusion or exclusion of AIA extension is secondary.
>

> There's also the must-staple extension in the works, which can be part of
> the plan: you either get short lived certs or you get a long lived with
> must-staple. They would provide the same security guarantees.
>

[Jeremy Rowley]

An exception to Mozilla's policy won't permit short-lived certificates since the other browsers won't have the same exception. Personally, I like 0 the best since it coordinates all of the CAs and browsers into a single plan of action rather than carving out individual exceptions to the guidelines.

Jeremy

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org] On Behalf Of Gervase Markham
Sent: Thursday, September 4, 2014 4:22 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Short-lived certs

Short-lived certs are one plank of our future revocation strategy.[0] Currently, it is not permitted by the CAB Forum Baseline Requirements to revocation pointers out of a cert, ever. However, this is part of the big value of short-lived certs, as it's what unlocks their speed-increasing potential across all browsers. (The logic is that a 3-day expiry misissued cert with no revocation pointers has a similar risk profile to a 1-year expiry misissued cert where the attacker has captured a valid 3-day expiry OCSP response they can staple to it).

I've just been reviewing discussions from July 2012 on the CAB Forum mailing lists about short-lived certs. There was some significant opposition to removing revocation information from short-lived certs at the time (although things may be different now, I don't know). I personally think much of that opposition was mistaken, but the discussion nevertheless did not result in consensus.

How should we approach the issue of short-lived certs? It seems to me we can do the following:

0) Try and get a motion passed to change the BRs to allow short-lived certs to not have any revocation information. This would probably require us to review the original discussion and make a wiki page outlining our proposal and rebutting objections. We may still run into heavy weather. We could also discuss it at the face-to-face.

1) Write an exception in Mozilla's policy that short-lived certs don't have to have revocation info. This would likely have no effect, because CAs would want to continue issuing to the BRs.

2) Stop checking revocation information for short-lived certs unilaterally. This would result in reduced take-up of the idea, because there would be no advantage in other browsers, and one would still need to implement all the mechanisms, both at the CA and at the site, for frequent cert renewals and deployments.

3) Configure Firefox to not bother checking revocation information for any cert newer than N days. This way, you can "emulate" short-lived certs by just reissuing an X-year cert every N days or less. It also 'fixes' the clock-skew problem in one direction, because the certs will still work for users whose clocks are some way in the future (although their browsers would check revocation).

4) Something else?

Gerv

[0] https://wiki.mozilla.org/CA:RevocationPlan

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

[Tim Moses]

Hi Mark. I think that makes sense.

Historically, the Development manager for the affected product has been invited to SARB. He or she has taken on the task of communicating with the relevant product managers.

"Relevant" product managers should include those with responsibility for services.

The service product managers should ensure that service components are remediated in an expeditious manner and that (where not already publicly disclosed) the security bulletin is not released until this has been done.

I don't think that contradicts anything in the proposed amendment. We just have to make sure that the Development manager brings ALL the relevant product managers into the discussion.

All the best. Tim.

> On Sep 4, 2014, at 12:41 PM, "Ben Wilson" <ben.w...@digicert.com> wrote:
>
> Options for trying this out might fit under an exception, if one were
> created, for "test, experimental, temporary, pilot, provisional, etc."
> certificate types.

[Tim Moses]

Oops. Does it look like I replied to wrong email?

Red-faced. Tim.

[David E. Ross]

On 9/4/2014 3:21 AM, Gervase Markham wrote [in part]:
> How should we approach the issue of short-lived certs?

Spammers change their E-mail addresses quite frequently, using the same
address for only a day or two. Hackers also frequently change their
"residence" so as to prevent tracing them. The same is true of
distributors of malware.

If short-lived certificates are subjected to less stringent security by
client applications, I would fear that they would become hacker and
malware tools.

--
David E. Ross

The Crimea is Putin's Sudetenland.
The Ukraine will be Putin's Czechoslovakia.
See <http://www.rossde.com/editorials/edtl_PutinUkraine.html>.

[Jeremy Rowley]

They aren't subject to less stringent security in issuing the certificate. The benefit is that the certificate doesn't include revocation information (smaller size) and doesn't need to check revocation status (faster handshake). The issuance of the certificate still must meet all of the Mozilla root store requirements.

Jeremy

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org] On Behalf Of David E. Ross
Sent: Thursday, September 4, 2014 11:36 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Short-lived certs

On 9/4/2014 3:21 AM, Gervase Markham wrote [in part]:

> How should we approach the issue of short-lived certs?

Spammers change their E-mail addresses quite frequently, using the same address for only a day or two. Hackers also frequently change their "residence" so as to prevent tracing them. The same is true of distributors of malware.

If short-lived certificates are subjected to less stringent security by client applications, I would fear that they would become hacker and malware tools.

--
David E. Ross

The Crimea is Putin's Sudetenland.
The Ukraine will be Putin's Czechoslovakia.
See <http://www.rossde.com/editorials/edtl_PutinUkraine.html>.

[Phillip Hallam-Baker]

On Thu, Sep 4, 2014 at 7:52 AM, Hubert Kario <hka...@redhat.com> wrote:
> ----- Original Message -----
>> From: "Gervase Markham" <ge...@mozilla.org>
>> To: mozilla-dev-s...@lists.mozilla.org

>> Sent: Thursday, September 4, 2014 12:21:50 PM
>> Subject: Short-lived certs
>>
>> Short-lived certs are one plank of our future revocation strategy.[0]
>> Currently, it is not permitted by the CAB Forum Baseline Requirements to
>> revocation pointers out of a cert, ever. However, this is part of the
>> big value of short-lived certs, as it's what unlocks their
>> speed-increasing potential across all browsers. (The logic is that a
>> 3-day expiry misissued cert with no revocation pointers has a similar
>> risk profile to a 1-year expiry misissued cert where the attacker has
>> captured a valid 3-day expiry OCSP response they can staple to it).
>

> It all depends on the exact definition of "short-lived". If the definition
> is basically the same as for OCSP responses or shorter, then yes, they
> provide the same security as regular certs with hard fail for OCSP
> querying/stapling.
>
> I'm not sure what gives us the removal of revocation info from certificate.
>
> I mean, if the recommendation for PKIX is to not check revocation info
> for certificates that have total validity period of less than, say 2 days,
> then inclusion or exclusion of AIA extension is secondary.
>
> There's also the must-staple extension in the works, which can be part of
> the plan: you either get short lived certs or you get a long lived with
> must-staple. They would provide the same security guarantees.

Some constraints:

1) Any new scheme has to work equally well with legacy browsers and
enabled browsers.

2) Ditto for legacy servers and this is actually a harder problem as
upgrading a server can force a complete redesign if they are using a
middleware layer that has changed radically.

3) The status vulnerability window needs to be no longer than 48 hours
for a machine with an accurate clock

4) The scheme must tolerate some degree of clock skew, though the
amount might vary over time.


Because of (1), the AIA field is going to have to be populated in EV
certs for a very long time and so we probably don't need to raise any
of this in CABForum right now. Lets do the work then let them follow
the deployment. A browser doesn't have to check the AIA field just
because it is there.

At worst we reword the requirements on browsers to say that they have
to verify that the status is current and not specify how. Short lived
certs would automatically qualify.


Must Staple and short lived certs are pretty much the same as far as
the security requirements go. The difference is that the server
requirements for supporting stapling with must staple are pretty
simple. All that is needed is that the server specify the must staple
extension when the certificate is applied for (just a flag on the key
generator) and then the server pulls the OCSP token from the AIA
extension every n hours which is already implemented almost
everywhere.

Short lived certs are just as easy in theory BUT they require some new
infrastructure to do the job right. At minimum there needs to be a
mechanism to tell the server how to get its supply of short lived
certificates. And we haven't designed a standard for that yet or
really discussed how to do it and so it isn't ready to press the fire
button on.


What I suggest browsers do right now is

1) Join in the IETF discussion on the TLS/PKIX lists saying that you
support my TLS Feature extension proposal aka MUST STAPLE.

2) Read and comment on the proposal you have just committed to.

3) Implement an appropriate response to a certificate that specifies a
MUST STAPLE condition when the server does not staple. This could be
(1) Hard Fail immediately or (2) attempt to do an OCSP lookup and hard
fail if it does not succeed or (3) choose randomly between options 1
and 2 so as to disincentivize CAs misusing setting the flag to force
hard fail.

4) Implement a mechanism that regards certificates with a total
validity interval of 72 hours or less to be valid without checking. I
do not expect this feature to be used very soon but implementing the
feature in the browser is probably a gating function on starting the
server folk thinking about the best way to implement the cert update
feature.


The simplest way to do cert update would be for the server to keep the
same key throughout and just issue fresh certs for the same old key.

A much better approach that provides a lot of robustness in all sorts
of ways is to rotate the private key with each new certificate. Under
one scheme the server would have some means of authenticating the cert
update request to a CA (probably a long term RSA or ECC key pair).

But in a large server farm where outsourcing etc is involved you might
want to have a scheme that makes use of trustworthy hardware to bind
unique keys to particular hardware in a manner that prevents
extraction.

I have a scheme of this type described here...

https://datatracker.ietf.org/doc/draft-hallambaker-omnipublish/



Rotating the server private key every 24 hours practically eliminates
key compromise due to a server or hard drive being disposed of within
the cert validity interval. It vastly increases the cost of pervasive
attacks against well known keys. It also works a lot better for cloud
computing.

[fhw...@gmail.com]

Hi Jeremy, 

Could you (or anyone) elaborate a bit on the use cases where short lived certs are desirable?

Are there really cases where the extra 50 bytes (or whatever) for the revocation info is t‎oo great a burden? Or is the desire really to short circuit the revocation checks? Or...?

I'm also wondering what the plan is for handling an expired short term cert. Will the user be given a choice of allowing an exception or does it get special handling? 


  Original Message  
From: Jeremy Rowley
Sent: Thursday, September 4, 2014 12:46 PM
To: 'David E. Ross'; mozilla-dev-s...@lists.mozilla.org
Subject: RE: Short-lived certs

They aren't subject to less stringent security in issuing the certificate. The benefit is that the certificate doesn't include revocation information (smaller size) and doesn't need to check revocation status (faster handshake). The issuance of the certificate still must meet all of the Mozilla root store requirements.

Jeremy

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org] On Behalf Of David E. Ross
Sent: Thursday, September 4, 2014 11:36 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Short-lived certs

On 9/4/2014 3:21 AM, Gervase Markham wrote [in part]:

> How should we approach the issue of short-lived certs?

[David E. Ross]

On 9/4/2014 10:44 AM, Jeremy Rowley wrote:
>
> They aren't subject to less stringent security in issuing the
> certificate. The benefit is that the certificate doesn't include
> revocation information (smaller size) and doesn't need to check
> revocation status (faster handshake). The issuance of the certificate
> still must meet all of the Mozilla root store requirements.
> > Jeremy
>

Are you suggesting that NO certificate authority applying stringent
procedures has ever signed a subscriber certificate for someone who
intended to use it for malevolent purposes?

[Jeremy Rowley]

Of course not. I'm implying that the level of security in a short-lived cert is at least equal to any other certificate with a longer life cycle. I'd argue that the security is perhaps better since revocation happens automatically by the certificate's expiration without the need to push a CRL or provide OCSP.

Jeremy

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org] On Behalf Of David E. Ross
Sent: Thursday, September 4, 2014 12:44 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Short-lived certs

On 9/4/2014 10:44 AM, Jeremy Rowley wrote:
>

> They aren't subject to less stringent security in issuing the
> certificate. The benefit is that the certificate doesn't include
> revocation information (smaller size) and doesn't need to check
> revocation status (faster handshake). The issuance of the certificate
> still must meet all of the Mozilla root store requirements.
> > Jeremy
>

Are you suggesting that NO certificate authority applying stringent procedures has ever signed a subscriber certificate for someone who intended to use it for malevolent purposes?

[Peter Bowen]

On Thu, Sep 4, 2014 at 7:54 AM, Ben Wilson <ben.w...@digicert.com> wrote:
> Options for trying this out might fit under an exception, if one were
> created, for "test, experimental, temporary, pilot, provisional, etc."
> certificate types.

Ben,

I think there is value in allowing some level of non-compliance for
the purposes of testing and development, as that is the only way to
get real world data. However the challenge is going to be not
creating a loophole large enough to drive a truck (or business)
through. I have no question there are customers who would love to pay
a CA to issue a 1024-bit RSA certificate directly from a root with a
subject of "CN=exchange" with no subject alternative name. What would
prevent a CA from issuing such a certificate as a "test, experimental,
temporary, pilot, provisional, etc." type certificate?

Thanks,
Peter

[Ryan Sleevi]

On Thu, September 4, 2014 11:20 am, Phillip Hallam-Baker wrote:
> Some constraints:
>
> 1) Any new scheme has to work equally well with legacy browsers and
> enabled browsers.

Sure. However, this requires a definition of legacy.

>
> 2) Ditto for legacy servers and this is actually a harder problem as
> upgrading a server can force a complete redesign if they are using a
> middleware layer that has changed radically.

Respectfully, Phillip, I disagree. CAs MAY offer such short-lived certs as
an option. No one's requiring they exclusively limit issuance to it.
There's no concern for legacy servers. If you're a legacy server, you
don't use this. It's that simple.

>
> 3) The status vulnerability window needs to be no longer than 48 hours
> for a machine with an accurate clock

That's an opinion, and not a hard requirement memorialized in the current
Baseline Requirements or Mozilla program. So I don't think it's fair or
reasonable to introduce it as a requirement upon some new scheme or
proposal.

>
> 4) The scheme must tolerate some degree of clock skew, though the
> amount might vary over time.

That's up to the server operator, not the CA, and whether or not the
solution is viable for them.

Which is to say, a solution that tolerates no degree of clock skew is
still immensely viable for a group of people. The more clock skew
supported, the more viable it becomes for others, but that is NOT a gating
factor to the overall scheme.

>
>
> Because of (1), the AIA field is going to have to be populated in EV
> certs for a very long time and so we probably don't need to raise any
> of this in CABForum right now. Lets do the work then let them follow
> the deployment. A browser doesn't have to check the AIA field just
> because it is there.

I'm not sure I agree with your conclusion for 1. As noted elsewhere, a
short-lived cert is effectively the same as the maximal attack window for
a revocation response. That's it. The AIA can be dropped if they're
equivalent.

>
> At worst we reword the requirements on browsers to say that they have
> to verify that the status is current and not specify how. Short lived
> certs would automatically qualify.
>
>
> Must Staple and short lived certs are pretty much the same as far as
> the security requirements go. The difference is that the server
> requirements for supporting stapling with must staple are pretty
> simple. All that is needed is that the server specify the must staple
> extension when the certificate is applied for (just a flag on the key
> generator) and then the server pulls the OCSP token from the AIA
> extension every n hours which is already implemented almost
> everywhere.
>
> Short lived certs are just as easy in theory BUT they require some new
> infrastructure to do the job right. At minimum there needs to be a
> mechanism to tell the server how to get its supply of short lived
> certificates. And we haven't designed a standard for that yet or
> really discussed how to do it and so it isn't ready to press the fire
> button on.

I disagree here. What's at stake is not the particular mechanisms of doing
so, nor would I endorse going down the route of standardizing such
mechanisms as you do. I would much rather see the relevant frameworks -
Mozilla and the BRs - altered to support them, and then allow site
operators and CAs interested in this model to work to develop the
infrastructure and, based on real world experience, rough consensus, and
running code, rather than idealized abstractions.

>
>
> What I suggest browsers do right now is
>
> 1) Join in the IETF discussion on the TLS/PKIX lists saying that you
> support my TLS Feature extension proposal aka MUST STAPLE.
>
> 2) Read and comment on the proposal you have just committed to.
>
> 3) Implement an appropriate response to a certificate that specifies a
> MUST STAPLE condition when the server does not staple. This could be
> (1) Hard Fail immediately or (2) attempt to do an OCSP lookup and hard
> fail if it does not succeed or (3) choose randomly between options 1
> and 2 so as to disincentivize CAs misusing setting the flag to force
> hard fail.

This is something you should nail down before 1 or 2.

The correct answer is hard fail. Any other answers and we'll be back here
again in 5 years with the same issues.

>
> 4) Implement a mechanism that regards certificates with a total
> validity interval of 72 hours or less to be valid without checking. I
> do not expect this feature to be used very soon but implementing the
> feature in the browser is probably a gating function on starting the
> server folk thinking about the best way to implement the cert update
> feature.

And implementing it in policy is the gating function before thinking about
implementing it in the server or the browser.

>
>
> The simplest way to do cert update would be for the server to keep the
> same key throughout and just issue fresh certs for the same old key.
>
> A much better approach that provides a lot of robustness in all sorts
> of ways is to rotate the private key with each new certificate. Under
> one scheme the server would have some means of authenticating the cert
> update request to a CA (probably a long term RSA or ECC key pair).
>
> But in a large server farm where outsourcing etc is involved you might
> want to have a scheme that makes use of trustworthy hardware to bind
> unique keys to particular hardware in a manner that prevents
> extraction.
>
> I have a scheme of this type described here...
>
> https://datatracker.ietf.org/doc/draft-hallambaker-omnipublish/
>
>
>
> Rotating the server private key every 24 hours practically eliminates
> key compromise due to a server or hard drive being disposed of within
> the cert validity interval. It vastly increases the cost of pervasive
> attacks against well known keys. It also works a lot better for cloud
> computing.

Which are a different, and valuable, set of mitigations, but orthogonal
the key issue at hand.

That is, I would like to see the world rotate keys on the regular, but I'm
not at all willing to throw the baby out with the bathwater and require
it.

[Brian Smith]

On Thu, Sep 4, 2014 at 6:04 AM, Gervase Markham <ge...@mozilla.org> wrote:
> On 04/09/14 12:52, Hubert Kario wrote:

>> It all depends on the exact definition of "short-lived". If the definition
>> is basically the same as for OCSP responses or shorter, then yes, they
>> provide the same security as regular certs with hard fail for OCSP
>> querying/stapling.
>

> The exact definition of "short-lived" is something I want to declare out
> of scope for this particular discussion.

Precisely defining a short-lived certificate is a prerequisite for a
proper discussion of policy for short-lived certificates. It seems
likely to me that short-lived certificates will be defined as
certificates that would expire before the longest-acceptable-life OCSP
response for that certificate would expire. Then it would be easy to
understand the security properties of short-lived certificates, given
that we understand the security properties of OCSP.

Previously, we decided it was important that we have evidence that the
OCSP responder know about all certificates that were issued by the CA,
so we made it a requirement that OCSP responders must return not
return "Good" for certificates that they do not know about. But,
accepting short-lived certificates is equivalent to an OCSP responder
returning "Good" for all certificates, whether it knows about them or
not. So, we need to decide whether this aspect (a type of multi-factor
authentication or counter-signature mechanism) is really important or
not. It seems wrong for us to make it mandatory for long-lived
certificates but not short-lived certificates, considering that the
highest period of risk is immediately after issuance.

Cheers,
Brian

[Jeremy Rowley]

Yeah - the cert would have to be shorter than the longest acceptable OCSP response for certificates. I think that's set to 10 days in the CAB Forum, but I'd be surprised if anyone issues OCSP responses that are valid that long.

The issue of revocation checking is where the proposal died in the CAB Forum. Opponents argued that mis-issued certificates are revoked immediately after issuance, meaning that traditional revocation is, on average, faster than short-lived certificate since the revocation usually occurs before the revocation information is cached.

Jeremy

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org] On Behalf Of Brian Smith
Sent: Thursday, September 4, 2014 5:07 PM
To: Gervase Markham
Cc: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Short-lived certs

On Thu, Sep 4, 2014 at 6:04 AM, Gervase Markham <ge...@mozilla.org> wrote:
> On 04/09/14 12:52, Hubert Kario wrote:

>> It all depends on the exact definition of "short-lived". If the
>> definition is basically the same as for OCSP responses or shorter,
>> then yes, they provide the same security as regular certs with hard
>> fail for OCSP querying/stapling.
>

> The exact definition of "short-lived" is something I want to declare
> out of scope for this particular discussion.

Precisely defining a short-lived certificate is a prerequisite for a proper discussion of policy for short-lived certificates. It seems likely to me that short-lived certificates will be defined as certificates that would expire before the longest-acceptable-life OCSP response for that certificate would expire. Then it would be easy to understand the security properties of short-lived certificates, given that we understand the security properties of OCSP.

Previously, we decided it was important that we have evidence that the OCSP responder know about all certificates that were issued by the CA, so we made it a requirement that OCSP responders must return not return "Good" for certificates that they do not know about. But, accepting short-lived certificates is equivalent to an OCSP responder returning "Good" for all certificates, whether it knows about them or not. So, we need to decide whether this aspect (a type of multi-factor authentication or counter-signature mechanism) is really important or not. It seems wrong for us to make it mandatory for long-lived certificates but not short-lived certificates, considering that the highest period of risk is immediately after issuance.

Cheers,
Brian

[Jeremy Rowley]

I agree with Ryan - as long as Mozilla (or the CAB) isn't requiring short lived certs, there isn't a concern about legacy servers. Since short-lived certs are optional, each server operator can individually decide on their own whether to implement short-lived certs on their server.

Also, before anyone can specify a 48/72/etc. hour lifecycle of short-lived certs, we'd need more information on clock skew, current OCSP validity period, and caching. Although tolerable clock skew is up to the operator (working with their CA), if Mozilla will provide special treatment for short-lived certificates, they'll need a cap on the lifecycle that fits in this window. Gerv's suggestion to exclude a debate on the exact definition from this discussion is a good one*. First, decide on how (and whether) to handle short-lived certs policy-wise, then decide on what constitutes an acceptable lifecycle.

Jeremy

*Presuming that short lived at least means shorter than the typical OCSP validity period

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org] On Behalf Of Ryan Sleevi
Sent: Thursday, September 4, 2014 4:44 PM
To: Phillip Hallam-Baker
Cc: Gervase Markham; mozilla-dev-s...@lists.mozilla.org; Hubert Kario
Subject: Re: Short-lived certs

[Jeremy Rowley]

Sure - short lived certs are desirable where:
1) 50 bytes does matter, such as high traffic websites (it's why some CAs were issuing certs directly from the root)
2) Revocation information cannot be reliable obtained, such as areas with low internet connectivity - the cert simply expires instead of being revoked
3) the server is in a region with probable government influence/intervention - the government may block revocation checking or may seize control over the servers, in which case the issuer simply turns off the certificate issuance
4) the server is in a region where there is civil unrest - again, the server operator can abandon the server without having to worry about the sufficiency of revocation checking

I think the an expired short-term certificate should be treated as revoked, but I don't have strong feelings. The expired certificate interstitial will likely give site visitors sufficient notice that something is going wrong.

Jeremy

-----Original Message-----
From: fhw...@gmail.com [mailto:fhw...@gmail.com]
Sent: Thursday, September 4, 2014 12:33 PM
To: Jeremy Rowley; 'David E. Ross'; mozilla-dev-s...@lists.mozilla.org
Subject: Re: Short-lived certs

Hi Jeremy, 

Could you (or anyone) elaborate a bit on the use cases where short lived certs are desirable?

Are there really cases where the extra 50 bytes (or whatever) for the revocation info is t‎oo great a burden? Or is the desire really to short circuit the revocation checks? Or...?

I'm also wondering what the plan is for handling an expired short term cert. Will the user be given a choice of allowing an exception or does it get special handling? 


  Original Message  
From: Jeremy Rowley
Sent: Thursday, September 4, 2014 12:46 PM
To: 'David E. Ross'; mozilla-dev-s...@lists.mozilla.org
Subject: RE: Short-lived certs

They aren't subject to less stringent security in issuing the certificate. The benefit is that the certificate doesn't include revocation information (smaller size) and doesn't need to check revocation status (faster handshake). The issuance of the certificate still must meet all of the Mozilla root store requirements.

Jeremy

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org] On Behalf Of David E. Ross
Sent: Thursday, September 4, 2014 11:36 AM
To: mozilla-dev-s...@lists.mozilla.org

Subject: Re: Short-lived certs

On 9/4/2014 3:21 AM, Gervase Markham wrote [in part]:

> How should we approach the issue of short-lived certs?

Spammers change their E-mail addresses quite frequently, using the same address for only a day or two. Hackers also frequently change their "residence" so as to prevent tracing them. The same is true of distributors of malware.

If short-lived certificates are subjected to less stringent security by client applications, I would fear that they would become hacker and malware tools.

--
David E. Ross

The Crimea is Putin's Sudetenland.
The Ukraine will be Putin's Czechoslovakia.
See <http://www.rossde.com/editorials/edtl_PutinUkraine.html>.

[Phillip Hallam-Baker]

On Thu, Sep 4, 2014 at 6:43 PM, Ryan Sleevi
<ryan-mozde...@sleevi.com> wrote:
> On Thu, September 4, 2014 11:20 am, Phillip Hallam-Baker wrote:
>> Some constraints:
>>
>> 1) Any new scheme has to work equally well with legacy browsers and
>> enabled browsers.
>
> Sure. However, this requires a definition of legacy.
>
>>
>> 2) Ditto for legacy servers and this is actually a harder problem as
>> upgrading a server can force a complete redesign if they are using a
>> middleware layer that has changed radically.
>
> Respectfully, Phillip, I disagree. CAs MAY offer such short-lived certs as
> an option. No one's requiring they exclusively limit issuance to it.
> There's no concern for legacy servers. If you're a legacy server, you
> don't use this. It's that simple.

It is still a problem.

The point I am trying to get across here is that there are very few
good reasons for an end user sticking to an obsolete browser and
almost all would upgrade given the choice. This is not the case for
servers and there are lots of folk who will complain if they are
forced to upgrade their server because that might require them to
change their PHP version which in turn requires them to completely
rework a ton of spaghetti code piled on top.

>> Because of (1), the AIA field is going to have to be populated in EV
>> certs for a very long time and so we probably don't need to raise any
>> of this in CABForum right now. Lets do the work then let them follow
>> the deployment. A browser doesn't have to check the AIA field just
>> because it is there.
>
> I'm not sure I agree with your conclusion for 1. As noted elsewhere, a
> short-lived cert is effectively the same as the maximal attack window for
> a revocation response. That's it. The AIA can be dropped if they're
> equivalent.

It can be dropped as far as security is concerned. But that is only
going to save a few bytes and might cause legacy issues. So why make
being allowed to drop it a major concern at this point?

Dropping AIA is useful for the CA as I don't need to bother with OCSP
at all. But I can only drop AIA if it is not going to cause legacy
browsers to squeak about a missing OCSP distribution point.

If there are browsers that give appropriate treatment to short lived
certs then I am sure getting CABForum to update the BRs etc. is not
going to be hard. All I am saying here is that is not a critical path
concern.

>> Short lived certs are just as easy in theory BUT they require some new
>> infrastructure to do the job right. At minimum there needs to be a
>> mechanism to tell the server how to get its supply of short lived
>> certificates. And we haven't designed a standard for that yet or
>> really discussed how to do it and so it isn't ready to press the fire
>> button on.
>
> I disagree here. What's at stake is not the particular mechanisms of doing
> so, nor would I endorse going down the route of standardizing such
> mechanisms as you do. I would much rather see the relevant frameworks -
> Mozilla and the BRs - altered to support them, and then allow site
> operators and CAs interested in this model to work to develop the
> infrastructure and, based on real world experience, rough consensus, and
> running code, rather than idealized abstractions.

I am not interested in issuing any product until my customers can use
it. And I don't see how they can use it until the cert update process
can be automated.

>> What I suggest browsers do right now is
>>
>> 1) Join in the IETF discussion on the TLS/PKIX lists saying that you
>> support my TLS Feature extension proposal aka MUST STAPLE.
>>
>> 2) Read and comment on the proposal you have just committed to.
>>
>> 3) Implement an appropriate response to a certificate that specifies a
>> MUST STAPLE condition when the server does not staple. This could be
>> (1) Hard Fail immediately or (2) attempt to do an OCSP lookup and hard
>> fail if it does not succeed or (3) choose randomly between options 1
>> and 2 so as to disincentivize CAs misusing setting the flag to force
>> hard fail.
>
> This is something you should nail down before 1 or 2.

OK, if I have to nail it down I will pick 1.

> The correct answer is hard fail. Any other answers and we'll be back here
> again in 5 years with the same issues.

That is my preference.

>> 4) Implement a mechanism that regards certificates with a total
>> validity interval of 72 hours or less to be valid without checking. I
>> do not expect this feature to be used very soon but implementing the
>> feature in the browser is probably a gating function on starting the
>> server folk thinking about the best way to implement the cert update
>> feature.
>
> And implementing it in policy is the gating function before thinking about
> implementing it in the server or the browser.

I don't see the need to gate on policy changes. What do you think
stops me issuing a 72 hour certificate today? I can't think of
anything.

>> Rotating the server private key every 24 hours practically eliminates
>> key compromise due to a server or hard drive being disposed of within
>> the cert validity interval. It vastly increases the cost of pervasive
>> attacks against well known keys. It also works a lot better for cloud
>> computing.
>
> Which are a different, and valuable, set of mitigations, but orthogonal
> the key issue at hand.
>
> That is, I would like to see the world rotate keys on the regular, but I'm
> not at all willing to throw the baby out with the bathwater and require
> it.

Which is why I mentioned the simple approach.

[Gervase Markham]

On 04/09/14 14:14, Hubert Kario wrote:
>>From what I heard (and my limited personal experience matches), is that
> the vast majority of clients not only completely ignore failures in OCSP
> retrieval (soft-fail) but completely lack any mechanism for revocation checking
> (be it OCSP or CRL).

I believe all browsers have some mechanisms for revocation checking.
Firefox does indeed soft-fail OCSP; our revocation plan as referenced in
the parent post demonstrates how we are hoping to improve this, with
short-lived certs part of the mix.

Gerv

[Gervase Markham]

On 04/09/14 14:18, Rob Stradling wrote:
> Today, if an end-entity cert contains no AIA->OCSP URL and the server
> sends no stapled OCSP response, it's a violation of the BRs. I wonder
> if any clients out there would reject the cert in this situation? (I
> suspect not, but it's something to watch out for).

I'm not aware of any browser which enforces the presence of revocation
information, but if such a browser existed, that would of course affect
the viability of the option of updating the BRs to not require
revocation information for short-lived certs.

Gerv

[Gervase Markham]

On 04/09/14 14:25, Rob Stradling wrote:
> When attempting to access an HTTPS site with an expired cert on Firefox
> 32, you'll see a "This Connection is Untrusted" page that lets you add
> an exception and proceed.
>
> But when attempting to access an HTTPS site with a revoked cert, you'll
> see "Secure Connection Failed" and Firefox 32 does NOT let you proceed.
>
> Would it make sense to treat expired certs in the same way as revoked
> certs? (And if not, why not?)

Logically, it does make sense. In practice, revocation has a near-zero
false-positive rate, whereas expired sadly has a much greater
false-positive rate. Which is why Firefox treats them differently.

It might be good, in the future, to get CAs to guarantee to continue
providing revocation information for e.g. 3 months after expiry, and for
those 3 months, we treat as "Untrusted Connection", but after that we
switch to "Secure Connection Failed". What do you think of that idea?

Gerv

[Gervase Markham]

On 04/09/14 18:36, David E. Ross wrote:
> Spammers change their E-mail addresses quite frequently, using the same
> address for only a day or two. Hackers also frequently change their
> "residence" so as to prevent tracing them. The same is true of
> distributors of malware.
>
> If short-lived certificates are subjected to less stringent security by
> client applications, I would fear that they would become hacker and
> malware tools.

Can you explain in detail the differences you see in the threat model
between:

a) a cert with a lifetime of 3 days and no revocation pointers

b) a cert with a lifetime of a year whose OCSP responder's responses
have a lifetime of 3 days

?

It seems to me that, if either are compromised, the attacker has 3 days
to exploit the issue. (In case b), they can staple the good OCSP
response they have obtained, even if the cert is revoked.)

Gerv

[Gervase Markham]

On 04/09/14 19:20, Phillip Hallam-Baker wrote:
> 1) Any new scheme has to work equally well with legacy browsers and
> enabled browsers.

Yes; I think short-lived certs meet that criterion.

> 2) Ditto for legacy servers and this is actually a harder problem as
> upgrading a server can force a complete redesign if they are using a
> middleware layer that has changed radically.

I don't agree; as others have said, no-one is forced to use such certs.

> 3) The status vulnerability window needs to be no longer than 48 hours
> for a machine with an accurate clock

How do you come up with your figure of 48 hours?

> 4) The scheme must tolerate some degree of clock skew, though the
> amount might vary over time.

Investigation of clock skew still needs to be done. We think that the
problem may not be insurmountable.

> Because of (1), the AIA field is going to have to be populated in EV
> certs for a very long time and so we probably don't need to raise any
> of this in CABForum right now. Lets do the work then let them follow
> the deployment. A browser doesn't have to check the AIA field just
> because it is there.

As my original post noted, a lot of the advantage of short-lived certs
evaporates if they contain revocation pointers.

> Short lived certs are just as easy in theory BUT they require some new
> infrastructure to do the job right. At minimum there needs to be a
> mechanism to tell the server how to get its supply of short lived
> certificates. And we haven't designed a standard for that yet or
> really discussed how to do it and so it isn't ready to press the fire
> button on.

I don't think it necessarily requires a standard.

> 1) Join in the IETF discussion on the TLS/PKIX lists saying that you
> support my TLS Feature extension proposal aka MUST STAPLE.

We definitely support it.

> 3) Implement an appropriate response to a certificate that specifies a
> MUST STAPLE condition when the server does not staple. This could be
> (1) Hard Fail immediately

I think that's what we will be doing.

> or (2) attempt to do an OCSP lookup and hard
> fail if it does not succeed or (3) choose randomly between options 1
> and 2 so as to disincentivize CAs misusing setting the flag to force
> hard fail.

I don't quite understand the problem you are trying to mitigate here;
can you expand?

Gerv

[Gervase Markham]

On 05/09/14 00:06, Brian Smith wrote:
> Precisely defining a short-lived certificate is a prerequisite for a
> proper discussion of policy for short-lived certificates. It seems
> likely to me that short-lived certificates will be defined as
> certificates that would expire before the longest-acceptable-life OCSP
> response for that certificate would expire. Then it would be easy to
> understand the security properties of short-lived certificates, given
> that we understand the security properties of OCSP.

I strongly want to avoid ratholing on this discussion; if I say "OK,
let's say for the sake of argument that short-lived is the same as the
max OCSP lifetime", then someone else will say "but that's still too
long!" and so on.

I realise that this issue would need to be resolved precisely before
short-lived certs were allowed by policy; but I just don't want to focus
on it right _now_. I want to assume that we could come up with an
appropriate time window, and work out how Mozilla should push towards
making short-lived certs possible, using the options I outlined above.

> Previously, we decided it was important that we have evidence that the
> OCSP responder know about all certificates that were issued by the CA,
> so we made it a requirement that OCSP responders must return not
> return "Good" for certificates that they do not know about. But,
> accepting short-lived certificates is equivalent to an OCSP responder
> returning "Good" for all certificates, whether it knows about them or
> not.

Is that actually true? I am assuming that if a cert is mis-issued, for a
few minutes at least the CA will stand by their issuance, and that the
attacker can obtain a good OCSP response for it with a lifetime of X,
and staple that response during their attack. So the security properties
of that are about the same as those for a cert with lifetime X.

Hmm... is there some mileage in saying that OCSP responses for certs
during their first week of existence must have a max lifetime of
significantly less than for the rest of their lives? That wouldn't
increase OCSP server load much, but would perhaps mitigate this issue if
the CA were to discover the misissuance soon after it happened.

Gerv

[Gervase Markham]

On 05/09/14 01:32, Phillip Hallam-Baker wrote:
> The point I am trying to get across here is that there are very few
> good reasons for an end user sticking to an obsolete browser and
> almost all would upgrade given the choice. This is not the case for
> servers and there are lots of folk who will complain if they are
> forced to upgrade their server because that might require them to
> change their PHP version which in turn requires them to completely
> rework a ton of spaghetti code piled on top.

Why would anyone ever be forced to upgrade their server?

No-one is suggesting that browsers _only_ support short-lived certs!

> It can be dropped as far as security is concerned. But that is only
> going to save a few bytes and might cause legacy issues. So why make
> being allowed to drop it a major concern at this point?

The reason for dropping it is to save the N hundred milliseconds
(sometimes much more, if network is bad or server is down) that you have
to wait before you can actually go on and request data and display it to
the user. This is the big advantage of no-AIA. It's not the miniscule
cert size saving.

>> This is something you should nail down before 1 or 2.
>
> OK, if I have to nail it down I will pick 1.

Great :-)

> I don't see the need to gate on policy changes. What do you think
> stops me issuing a 72 hour certificate today? I can't think of
> anything.

Nothing, but they are no advantage to anyone unless you can also omit
the revocation pointers. Which is currently not permitted, hence this
discussion.

Gerv

[Gervase Markham]

On 04/09/14 19:32, fhw...@gmail.com wrote:
> Could you (or anyone) elaborate a bit on the use cases where short
> lived certs are desirable?

See other messages in this thread - it saves a significant amount of
setup time not to have to wait for a response from the OCSP server.

> I'm also wondering what the plan is for handling an expired short
> term cert. Will the user be given a choice of allowing an exception
> or does it get special handling?

What if I say it's treated the same as any other expired cert?

Gerv

[Rob Stradling]

On 05/09/14 10:30, Gervase Markham wrote:
> On 04/09/14 14:25, Rob Stradling wrote:

>> When attempting to access an HTTPS site with an expired cert on Firefox
>> 32, you'll see a "This Connection is Untrusted" page that lets you add
>> an exception and proceed.
>>
>> But when attempting to access an HTTPS site with a revoked cert, you'll
>> see "Secure Connection Failed" and Firefox 32 does NOT let you proceed.
>>
>> Would it make sense to treat expired certs in the same way as revoked
>> certs? (And if not, why not?)
>

> Logically, it does make sense. In practice, revocation has a near-zero
> false-positive rate, whereas expired sadly has a much greater
> false-positive rate. Which is why Firefox treats them differently.

Hi Gerv.

Yes, that is sad.

> It might be good, in the future, to get CAs to guarantee to continue
> providing revocation information for e.g. 3 months after expiry, and for
> those 3 months, we treat as "Untrusted Connection",

Unless the recently expired cert is found to be revoked, in which case
you'd show "Secure Connection Failed" I presume?

> but after that we switch to "Secure Connection Failed". What do you think
> of that idea?

If the false positive rate drops to near-zero by 3 months after expiry,
then I think that could work. However, it would need to work equally
well for both long-lived certs and short-lived certs. Therefore,
short-lived certs would still need to provide revocation info, even if
the browser only uses that revocation info if it encounters the
short-lived cert after its expiry date.

[Gervase Markham]

On 05/09/14 10:47, Rob Stradling wrote:
> Unless the recently expired cert is found to be revoked, in which case
> you'd show "Secure Connection Failed" I presume?

Yes :-)

>> but after that we switch to "Secure Connection Failed". What do you think
>> of that idea?
>
> If the false positive rate drops to near-zero by 3 months after expiry,
>