Requiring OCSP for EV (was Re: [ct-policy] Proposed changes to EV/CT Plan)

262 views
Skip to first unread message

Ryan Sleevi

unread,
Nov 24, 2014, 9:19:00 AM11/24/14
to Rob Stradling, Richard Salz, Ben Laurie, net-dev, security-dev

bcc: ct-policy
cc: net-dev, security-dev

Responses inline.
On Nov 24, 2014 10:39 AM, "Rob Stradling" <robs...@gmail.com> wrote:
>
>
> On 20/11/14 21:37, Ryan Sleevi wrote:
>>
>>
>> On Thu, Nov 20, 2014 at 7:50 AM, Rob Stradling <robs...@gmail.com> wrote:
>>>
>>>
>>> On 20/11/14 15:46, Richard Salz wrote:
>>> <snip>
>>>>
>>>> And again, if there aren't enough logs out there, stapling does nothing. And by my reading of the spec and [trans] mailing list discussions, I took stapling to be a temporary thing until SCT embedding was done. Apparently that's not correct, but it sure does (did) seem like a reasonable interpretation of things.
>>>
>>>
>>> There are no plans to deprecate any of the 3 SCT distribution mechanisms (certificate extension, OCSP response extension, SCT TLS extension), so to label any of them as "temporary" is misleading IMHO.
>>
>>
>> There are indeed no plans to deprecate embedding SCTs. However, embedding SCTs is fundamentally more risky than stapling, because once issued, it cannot be changed. Stapling provides a robust means for ongoing transparency, but requires server operators to support it.
>>
>> Thus embedding is conceptually transitional until stapling becomes ubiquitous, after which stapling will be the "preferred" method.
>
>
> I fear that OCSP stapling will never become truly ubiquitous.  Even when the feature is available in the server software, some server operators don't want to allow outbound connections from their servers.
>
>
>> Note that for EV certificates, it is extremely likely that stapling will become mandatory in the future, so that too will address some of these issues.
>
>
> Ryan, could you explain this statement?
> Should we interpret it as an official announcement that Google intends to start requiring OCSP Stapling for EV in Chrom[e|ium] at some point in the future?

Rob, Surely you don't think I would slip in a requirement that subtlely, do you? :)

I would say that it's very much under early discussion, but there is hardly any commitment to require it. I would say we aren't alone in discussing it, though.

However, it is worth noting that this is not a CA concern so much as a site operator concern. CAs do not have to change any of their infrastructure to support stapling, beyond simply supporting OCSP, which is already required. This is about deployment considerations in order to have the browser signal high confidence and security signals to the user.

> Or are you saying that you intend to propose a CABForum ballot re: mandatory inclusion of the Must-Staple certificate extension in EV certs?
> Or what?
>

I think we are constantly evaluating ways to ensure that the security levels we communicate to users reflects both the degree of assurances we, as a UA, have, but also what user expectations are when using Chrome.

Consider, for example, that Chrome 41 now communicates when you're using outdated crypto (e.g. non-AEAD, non-PFS, TLS <1.2), rather than wording that implies that 256-bit CBC is better than 128-bit GCM. Support for these bare minimum modes is already required by HTTP/2, for example (Section 9.2.2), and is increasingly the only level of TLS in which we have reasonable confidence. You can already see this in the TLS 1.3 drafts.

For users, the expectation is that an EV certificate represents not just assurances of the site's identity, but some degree of security. Regardless of whether or not that is truly possible with EV (since it suffers the "same origin problem" of being the same origin as DV, ergo DV is the true security level of EV), it definitely does not align with users' perceived expectations to have a site serving an EV certificate over SSL3 (as an unfortunate number do...)

I expect that as we discuss more, we will have more concrete proposals for the community at large. However, I would say the zeitgeist is very much that EV should represent the "meeting the minimum of high security" - which would be PFS, AEAD, and TLS1.2+.

For certificates, we know revocation is broken in many practical ways. I think similar to ciphersuites, it may be treated that EV evaluation is implicitly (not explicitly) Must-Staple. If a site fails to staple a fresh OCSP response, downgrading to DV seems an eminently reasonable course of action, since we lack the assurances as to certificate's freshness and accuracy. This is the same as downgrading to DV when we lack confidence and assurance that the CA is operating according to their stated policies and in the public interest; that is to say, when we lack SCT information.

> For Chrome, AIUI you already aim to have your CRLSets cover all EV certs, so why demand OCSP Stapling for EV as well?
>

This is not correct, and something we have repeatedly clarified. CRLSets first and foremost has been a means to deal with emergency revocations outside of the binary updates, such as those employed by Firefox, or system updates, such as those employed by Microsoft (prior to certificate distrust lists, which operate comparably) or Apple. Our commitment is to rapid response, and the focus here is on intermediates and certificates with powerful/dangerous capabilities that put a broad base of users at risk.

In the course of developing this, we saw an opportunity to optimize some of the CRL delivery for end-entity certs, but this was merely opportunistic. While we still employ it, especially for CAs that can provide meaningful revocation information, this is a "nice to have", and may be removed in the future. While I'm sure this would kick off a centithread alone, I don't think we should focus on this.

> What about when the RFC6962 TLS extension is being used - would OCSP Stapling still be mandatory then?

For EV treatment, I think the discussion of CT would be independent of OCSP. That is, treating EV as implicitly OCSP Must-Staple is NOT for CT purposes (although it IS quite convenient for these), but for basic assurances of the EV certificate itself, and to allow CAs the ability they desire, which is the ability to revoke such certificates in a way that actually works for the WebPKI.

As a CA, nominally, this requires no action - any such changes would be server deployment. However, as gatekeepers of a secure Internet, whose business models and marketing depend very much on the promotion of security, this is a fantastic opportunity for CAs to invest in meaningful improvements towards the infrastructure of their customers. Solutions like Let's Encrypt and SSLMate show there are ample opportunities for CAs to help their customers meaningfully move the needle of security further.

For example, if you know of customers of yours who are wary to deploy positive technologies like OCSP stapling, perhaps you can work with them to understand their needs and find alternative ways for OCSP deployment, such as push-models rather than pull. Many CAs have invested heavily in solutions to facilitate air gapped networks and offline signing use cases, and I can think of few people more qualified to understand the problems, challenges, and possible solutions for these sets of issues than the CAs themselves.

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

Richard Salz

unread,
Nov 24, 2014, 10:08:15 AM11/24/14
to Ryan Sleevi, Rob Stradling, Ben Laurie, net-dev, security-dev
>>> Note that for EV certificates, it is extremely likely that stapling will
>>> become mandatory in the future, so that too will address some of these
>>> issues.

When you say OCSP staple, do you mean staple with SCT's?

> However, it is worth noting that this is not a CA concern so much as a site
> operator concern. CAs do not have to change any of their infrastructure to
> support stapling

If you mean SCT-OCSP then I'd think that this would be a responder
change. But yes, the bigger impact is probably on those running the
web server.

> For certificates, we know revocation is broken in many practical ways.

I'd go stronger than that -- fundamentally broken or essentially
non-existent. :)

Once the cert is CT-logged, then a standard OCSP response should
suffice, rather than an SCT-OCSP, right?

Ryan Sleevi

unread,
Nov 24, 2014, 10:14:35 AM11/24/14
to Richard Salz, Rob Stradling, security-dev, net-dev, Ben Laurie


On Nov 24, 2014 4:08 PM, "Richard Salz" <rich...@gmail.com> wrote:
>
> >>> Note that for EV certificates, it is extremely likely that stapling will
> >>> become mandatory in the future, so that too will address some of these
> >>> issues.
>
> When you say OCSP staple, do you mean staple with SCT's?

No, stapling in general. That is, how SCTs are treated is independent of how revocation is treated.

>
> > However, it is worth noting that this is not a CA concern so much as a site
> > operator concern. CAs do not have to change any of their infrastructure to
> > support stapling
>
> If you mean SCT-OCSP then I'd think that this would be a responder
> change.  But yes, the bigger impact is probably on those running the
> web server.
>

Exactly so, but I can't see us requiring this. That is, it offers a path for CAs to deal with a variety of a logs without having to make a one time decision on which logs to use at issuance.

> > For certificates, we know revocation is broken in many practical ways.
>
> I'd go stronger than that -- fundamentally broken or essentially
> non-existent. :)
>
> Once the cert is CT-logged, then a standard OCSP response should
> suffice, rather than an SCT-OCSP, right?

Correct. But a requirement of OCSP stapling on the deployment side should hopefully make it easier for CAs to deal with SCT issuance in the future, by deferring it to OCSP response time (whether online or offline is up to the CA)

Richard Salz

unread,
Nov 24, 2014, 10:22:21 AM11/24/14
to Ryan Sleevi, Rob Stradling, security-dev, net-dev, Ben Laurie
Thanks Ryan, that all makes sense to me.

(Er, we just agreed; must be a cold day in hell today :)

Rob Stradling

unread,
Nov 24, 2014, 4:59:57 PM11/24/14
to rsl...@chromium.org, Richard Salz, Ben Laurie, net-dev, security-dev

On 24/11/14 14:18, Ryan Sleevi wrote:
<snip>
>> Note that for EV certificates, it is extremely likely that stapling will become mandatory in the future, so that too will address some of these issues.

>
>
> Ryan, could you explain this statement?
> Should we interpret it as an official announcement that Google intends to start requiring OCSP Stapling for EV in Chrom[e|ium] at some point in the future?

Rob, Surely you don't think I would slip in a requirement that subtlely, do you? :)


Ryan, I don't think you would do that intentionally.  But I would like to avoid a repeat of the SHA-1 deprecation policy kerfuffle, where none of the CAs were aware of your alleged "announcement" for several months!


I would say that it's very much under early discussion, but there is hardly any commitment to require it. I would say we aren't alone in discussing it, though.

However, it is worth noting that this is not a CA concern so much as a site operator concern.


It's very much a CA concern!  i.e. How many of our EV cert customers whose servers can't do OCSP stapling would ask us for their money back, because they can't achieve the EV indicator in Chrome?


CAs do not have to change any of their infrastructure to support stapling, beyond simply supporting OCSP, which is already required. This is about deployment considerations in order to have the browser signal high confidence and security signals to the user.

> Or are you saying that you intend to propose a CABForum ballot re: mandatory inclusion of the Must-Staple certificate extension in EV certs?
> Or what?
>

I think we are constantly evaluating ways to ensure that the security levels we communicate to users reflects both the degree of assurances we, as a UA, have, but also what user expectations are when using Chrome.

Consider, for example, that Chrome 41 now communicates when you're using outdated crypto (e.g. non-AEAD, non-PFS, TLS <1.2), rather than wording that implies that 256-bit CBC is better than 128-bit GCM. Support for these bare minimum modes is already required by HTTP/2, for example (Section 9.2.2), and is increasingly the only level of TLS in which we have reasonable confidence. You can already see this in the TLS 1.3 drafts.

For users, the expectation is that an EV certificate represents not just assurances of the site's identity, but some degree of security. Regardless of whether or not that is truly possible with EV (since it suffers the "same origin problem" of being the same origin as DV, ergo DV is the true security level of EV), it definitely does not align with users' perceived expectations to have a site serving an EV certificate over SSL3 (as an unfortunate number do...)

I expect that as we discuss more, we will have more concrete proposals for the community at large. However, I would say the zeitgeist is very much that EV should represent the "meeting the minimum of high security" - which would be PFS, AEAD, and TLS1.2+.

For certificates, we know revocation is broken in many practical ways. I think similar to ciphersuites, it may be treated that EV evaluation is implicitly (not explicitly) Must-Staple. If a site fails to staple a fresh OCSP response, downgrading to DV seems an eminently reasonable course of action, since we lack the assurances as to certificate's freshness and accuracy. This is the same as downgrading to DV when we lack confidence and assurance that the CA is operating according to their stated policies and in the public interest; that is to say, when we lack SCT information.

> For Chrome, AIUI you already aim to have your CRLSets cover all EV certs, so why demand OCSP Stapling for EV as well?
>

This is not correct, and something we have repeatedly clarified.


Thanks for clarifying again then.  I must have missed your earlier clarifications.


CRLSets first and foremost has been a means to deal with emergency revocations outside of the binary updates, such as those employed by Firefox, or system updates, such as those employed by Microsoft (prior to certificate distrust lists, which operate comparably) or Apple. Our commitment is to rapid response, and the focus here is on intermediates and certificates with powerful/dangerous capabilities that put a broad base of users at risk.

In the course of developing this, we saw an opportunity to optimize some of the CRL delivery for end-entity certs, but this was merely opportunistic. While we still employ it, especially for CAs that can provide meaningful revocation information, this is a "nice to have", and may be removed in the future. While I'm sure this would kick off a centithread alone, I don't think we should focus on this.

> What about when the RFC6962 TLS extension is being used - would OCSP Stapling still be mandatory then?

For EV treatment, I think the discussion of CT would be independent of OCSP. That is, treating EV as implicitly OCSP Must-Staple is NOT for CT purposes (although it IS quite convenient for these), but for basic assurances of the EV certificate itself, and to allow CAs the ability they desire, which is the ability to revoke such certificates in a way that actually works for the WebPKI.

As a CA, nominally, this requires no action - any such changes would be server deployment. However, as gatekeepers of a secure Internet, whose business models and marketing depend very much on the promotion of security, this is a fantastic opportunity for CAs to invest in meaningful improvements towards the infrastructure of their customers. Solutions like Let's Encrypt and SSLMate show there are ample opportunities for CAs to help their customers meaningfully move the needle of security further.

For example, if you know of customers of yours who are wary to deploy positive technologies like OCSP stapling, perhaps you can work with them to understand their needs and find alternative ways for OCSP deployment, such as push-models rather than pull. Many CAs have invested heavily in solutions to facilitate air gapped networks and offline signing use cases, and I can think of few people more qualified to understand the problems, challenges, and possible solutions for these sets of issues than the CAs themselves.


Although it's still very new, I'm more optimistic right now about the chances of our CRL compression [1] [2] proposal fixing the revocation problem than I am about the chances of OCSP stapling fixing it.  Because CRL compression wouldn't need server software changes and wouldn't rely on server operators being convinced to enable server features.


[1] http://www.ietf.org/proceedings/91/slides/slides-91-trans-6.pdf

[2] https://tools.ietf.org/html/draft-hallambaker-compressedcrlset

Ryan Sleevi

unread,
Nov 25, 2014, 12:46:41 AM11/25/14
to Rob Stradling, security-dev, Richard Salz, net-dev, Ben Laurie


On Nov 24, 2014 10:59 PM, "Rob Stradling" <robs...@gmail.com> wrote:
>
>
> On 24/11/14 14:18, Ryan Sleevi wrote:
> <snip>
>>
>> >> Note that for EV certificates, it is extremely likely that stapling will become mandatory in the future, so that too will address some of these issues.
>>
>> >
>> >
>> > Ryan, could you explain this statement?
>> > Should we interpret it as an official announcement that Google intends to start requiring OCSP Stapling for EV in Chrom[e|ium] at some point in the future?
>>
>> Rob, Surely you don't think I would slip in a requirement that subtlely, do you? :)
>
>
> Ryan, I don't think you would do that intentionally.  But I would like to avoid a repeat of the SHA-1 deprecation policy kerfuffle, where none of the CAs were aware of your alleged "announcement" for several months!
>

Well, I can't help that CAs present and discussing the matter then claimed ignorance of the very topic they spent an hour discussing and raising concerns on.

>
>> I would say that it's very much under early discussion, but there is hardly any commitment to require it. I would say we aren't alone in discussing it, though.
>>
>> However, it is worth noting that this is not a CA concern so much as a site operator concern.
>
>
> It's very much a CA concern!  i.e. How many of our EV cert customers whose servers can't do OCSP stapling would ask us for their money back, because they can't achieve the EV indicator in Chrome?
>

If you sell a product that promises something will appear a certain way in a third party product, both now and in the future, then yes, you're selling something beyond your ability to support.

It would certain be a concern for CAs if customer deployment was something you insured against. The reality is you will have sold them a product that meets all of your technical obligations, and it is a matter for the customer to operationally deploy.

>
>> CAs do not have to change any of their infrastructure to support stapling, beyond simply supporting OCSP, which is already required. This is about deployment considerations in order to have the browser signal high confidence and security signals to the user.
>>
>> > Or are you saying that you intend to propose a CABForum ballot re: mandatory inclusion of the Must-Staple certificate extension in EV certs?
>> > Or what?
>> >
>>
>> I think we are constantly evaluating ways to ensure that the security levels we communicate to users reflects both the degree of assurances we, as a UA, have, but also what user expectations are when using Chrome.
>>
>> Consider, for example, that Chrome 41 now communicates when you're using outdated crypto (e.g. non-AEAD, non-PFS, TLS <1.2), rather than wording that implies that 256-bit CBC is better than 128-bit GCM. Support for these bare minimum modes is already required by HTTP/2, for example (Section 9.2.2), and is increasingly the only level of TLS in which we have reasonable confidence. You can already see this in the TLS 1.3 drafts.
>>
>> For users, the expectation is that an EV certificate represents not just assurances of the site's identity, but some degree of security. Regardless of whether or not that is truly possible with EV (since it suffers the "same origin problem" of being the same origin as DV, ergo DV is the true security level of EV), it definitely does not align with users' perceived expectations to have a site serving an EV certificate over SSL3 (as an unfortunate number do...)
>>
>> I expect that as we discuss more, we will have more concrete proposals for the community at large. However, I would say the zeitgeist is very much that EV should represent the "meeting the minimum of high security" - which would be PFS, AEAD, and TLS1.2+.
>>
>> For certificates, we know revocation is broken in many practical ways. I think similar to ciphersuites, it may be treated that EV evaluation is implicitly (not explicitly) Must-Staple. If a site fails to staple a fresh OCSP response, downgrading to DV seems an eminently reasonable course of action, since we lack the assurances as to certificate's freshness and accuracy. This is the same as downgrading to DV when we lack confidence and assurance that the CA is operating according to their stated policies and in the public interest; that is to say, when we lack SCT information.
>>
>> > For Chrome, AIUI you already aim to have your CRLSets cover all EV certs, so why demand OCSP Stapling for EV as well?
>> >
>>
>> This is not correct, and something we have repeatedly clarified.
>
>
> Thanks for clarifying again then.  I must have missed your earlier clarifications.
>
>
>> CRLSets first and foremost has been a means to deal with emergency revocations outside of the binary updates, such as those employed by Firefox, or system updates, such as those employed by Microsoft (prior to certificate distrust lists, which operate comparably) or Apple. Our commitment is to rapid response, and the focus here is on intermediates and certificates with powerful/dangerous capabilities that put a broad base of users at risk.
>>
>> In the course of developing this, we saw an opportunity to optimize some of the CRL delivery for end-entity certs, but this was merely opportunistic. While we still employ it, especially for CAs that can provide meaningful revocation information, this is a "nice to have", and may be removed in the future. While I'm sure this would kick off a centithread alone, I don't think we should focus on this.
>>
>> > What about when the RFC6962 TLS extension is being used - would OCSP Stapling still be mandatory then?
>>
>> For EV treatment, I think the discussion of CT would be independent of OCSP. That is, treating EV as implicitly OCSP Must-Staple is NOT for CT purposes (although it IS quite convenient for these), but for basic assurances of the EV certificate itself, and to allow CAs the ability they desire, which is the ability to revoke such certificates in a way that actually works for the WebPKI.
>>
>> As a CA, nominally, this requires no action - any such changes would be server deployment. However, as gatekeepers of a secure Internet, whose business models and marketing depend very much on the promotion of security, this is a fantastic opportunity for CAs to invest in meaningful improvements towards the infrastructure of their customers. Solutions like Let's Encrypt and SSLMate show there are ample opportunities for CAs to help their customers meaningfully move the needle of security further.
>>
>> For example, if you know of customers of yours who are wary to deploy positive technologies like OCSP stapling, perhaps you can work with them to understand their needs and find alternative ways for OCSP deployment, such as push-models rather than pull. Many CAs have invested heavily in solutions to facilitate air gapped networks and offline signing use cases, and I can think of few people more qualified to understand the problems, challenges, and possible solutions for these sets of issues than the CAs themselves.
>
>
> Although it's still very new, I'm more optimistic right now about the chances of our CRL compression [1] [2] proposal fixing the revocation problem than I am about the chances of OCSP stapling fixing it.  Because CRL compression wouldn't need server software changes and wouldn't rely on server operators being convinced to enable server features.
>
>
> [1] http://www.ietf.org/proceedings/91/slides/slides-91-trans-6.pdf
>
> [2] https://tools.ietf.org/html/draft-hallambaker-compressedcrlset
>
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
>

Hi Rob,

I'm far, far less optimistic at all about CRL compression, which I've shared before publicly during IETF 91 and privately, and would rather focus on the technology we have - which not only works, but works rather well - than on inventing yet another mechanism.

If your challenge is figuring out whether to invest R&D into CRL compression or to work with your customers to help encourage a wider adoption of OCSP Stapling, I would absolutely encourage you to focus on the latter.

Cheers,
Ryan

Rob Stradling

unread,
Dec 1, 2014, 8:52:02 AM12/1/14
to rsl...@chromium.org, security-dev, Richard Salz, net-dev, Ben Laurie
On 25/11/14 05:46, Ryan Sleevi wrote:

On Nov 24, 2014 10:59 PM, "Rob Stradling" <robs...@gmail.com> wrote:
>
>
> On 24/11/14 14:18, Ryan Sleevi wrote:
> <snip>
>>
>> >> Note that for EV certificates, it is extremely likely that stapling will become mandatory in the future, so that too will address some of these issues.
>>
>> >
>> >
>> > Ryan, could you explain this statement?
>> > Should we interpret it as an official announcement that Google intends to start requiring OCSP Stapling for EV in Chrom[e|ium] at some point in the future?
>>
>> Rob, Surely you don't think I would slip in a requirement that subtlely, do you? :)
>
>
> Ryan, I don't think you would do that intentionally.  But I would like to avoid a repeat of the SHA-1 deprecation policy kerfuffle, where none of the CAs were aware of your alleged "announcement" for several months!
>

Well, I can't help that CAs present and discussing the matter then claimed ignorance of the very topic they spent an hour discussing and raising concerns on.


Ryan, AFAIK nobody who was present at the CABForum F2F during which that discussion occurred has tried to claim that that discussion did not occur.  I wasn't there, but I see from the minutes that that discussion did occur!  But that's all it was: a discussion.  You did not make a policy announcement at that time.  AFAICT, you didn't say "we're definitely going to do this at some point" and you didn't indicate any intent to effect any changes sooner than the timescale that Microsoft had already published.

Then, 6 months later, you did make a policy announcement about your SHA-1 deprecation plan, with a timescale that most (if not all) of the CAs considered to be unfairly aggressive.  You used the fact that a discussion had taken place 6 months earlier to justify that aggressive timescale.

I don't understand why you think it was reasonable to expect the CAs to divine your future, not-yet-announced policy from a discussion about what Chrome might possibly do at some point in the future.

Possibilities are indistinguishable from noise.  Policies are what count.

That said, I'm optimistic that we won't see a repeat of this sort of kerfuffle, on the basis of your post to the ct-policy list a few days ago that said:
"When a change to the policy is announced to this list, it will be quite clear that the policy has changed. Until then, the policy HAS NOT changed - it is merely being discussed."

BTW, it seems odd that the Chrome Root Certificate Policy page [1] doesn't even mention your SHA-1 deprecation plan!  Does that mean it's not actually your policy yet?!?

[1] http://www.chromium.org/Home/chromium-security/root-ca-policy


>> I would say that it's very much under early discussion, but there is hardly any commitment to require it. I would say we aren't alone in discussing it, though.
>>
>> However, it is worth noting that this is not a CA concern so much as a site operator concern.
>
>
> It's very much a CA concern!  i.e. How many of our EV cert customers whose servers can't do OCSP stapling would ask us for their money back, because they can't achieve the EV indicator in Chrome?
>

If you sell a product that promises something will appear a certain way in a third party product, both now and in the future, then yes, you're selling something beyond your ability to support.

It would certain be a concern for CAs if customer deployment was something you insured against. The reality is you will have sold them a product that meets all of your technical obligations, and it is a matter for the customer to operationally deploy.


That the CA has met all of their technical obligations isn't much of a sales pitch for EV certs, unfortunately.

Like it or not, customers buy EV certs because they want the green bar to appear in their customers' browsers.

<snip>

Hi Rob,

I'm far, far less optimistic at all about CRL compression, which I've shared before publicly during IETF 91 and privately, and would rather focus on the technology we have - which not only works, but works rather well - than on inventing yet another mechanism.

If your challenge is figuring out whether to invest R&D into CRL compression or to work with your customers to help encourage a wider adoption of OCSP Stapling, I would absolutely encourage you to focus on the latter.

Cheers,
Ryan


Thanks for sharing your opinion.  Leaving aside for a moment the question of which approach to fixing revocation checking is the best approach...

What, if any, are your fundamental objections to CRL compression?

Thanks.

Ryan Sleevi

unread,
Dec 2, 2014, 8:24:11 AM12/2/14
to Rob Stradling, Ryan Sleevi, security-dev, Richard Salz, net-dev, Ben Laurie
On Mon, Dec 1, 2014 at 1:51 PM, Rob Stradling <robs...@gmail.com> wrote:
On 25/11/14 05:46, Ryan Sleevi wrote:

On Nov 24, 2014 10:59 PM, "Rob Stradling" <robs...@gmail.com> wrote:
>
>
> On 24/11/14 14:18, Ryan Sleevi wrote:
> <snip>
>>
>> >> Note that for EV certificates, it is extremely likely that stapling will become mandatory in the future, so that too will address some of these issues.
>>
>> >
>> >
>> > Ryan, could you explain this statement?
>> > Should we interpret it as an official announcement that Google intends to start requiring OCSP Stapling for EV in Chrom[e|ium] at some point in the future?
>>
>> Rob, Surely you don't think I would slip in a requirement that subtlely, do you? :)
>
>
> Ryan, I don't think you would do that intentionally.  But I would like to avoid a repeat of the SHA-1 deprecation policy kerfuffle, where none of the CAs were aware of your alleged "announcement" for several months!
>

Well, I can't help that CAs present and discussing the matter then claimed ignorance of the very topic they spent an hour discussing and raising concerns on.


Ryan, AFAIK nobody who was present at the CABForum F2F during which that discussion occurred has tried to claim that that discussion did not occur.  I wasn't there, but I see from the minutes that that discussion did occur!  But that's all it was: a discussion.  You did not make a policy announcement at that time.  AFAICT, you didn't say "we're definitely going to do this at some point" and you didn't indicate any intent to effect any changes sooner than the timescale that Microsoft had already published.

Then, 6 months later, you did make a policy announcement about your SHA-1 deprecation plan, with a timescale that most (if not all) of the CAs considered to be unfairly aggressive.  You used the fact that a discussion had taken place 6 months earlier to justify that aggressive timescale.

I don't understand why you think it was reasonable to expect the CAs to divine your future, not-yet-announced policy from a discussion about what Chrome might possibly do at some point in the future.

Possibilities are indistinguishable from noise.  Policies are what count.

To avoid another centithread on the matter, there's a number of statements here that are not accurate presentations of what occurred or what the reactions were.

I think the most important point to note is that the dates and timescale are the exact same as what Microsoft had already published months before even the discussion. I'll also note that CAs were able to agree to a ballot (although not unanimously) to a ballot that was similar in timescale and preparation, so it is not without saying that CAs are indeed capable of such changes.

However, rather than focus on the past, let's focus on the future.
 

That said, I'm optimistic that we won't see a repeat of this sort of kerfuffle, on the basis of your post to the ct-policy list a few days ago that said:
"When a change to the policy is announced to this list, it will be quite clear that the policy has changed. Until then, the policy HAS NOT changed - it is merely being discussed."

I do want to highlight a distinction here between what we're talking about here versus SHA-1. Chrome can and will change its UI over time, for any number of reasons, and these reasons are not always preannounced, especially not at the "three year" timescale that some CAs have requested.

Our process for deprecating Web Platform features in Blink is described at http://www.chromium.org/blink#TOC-Launch-Process:-Deprecation , and by and large, Chromium (and the network stack) try to follow this. SHA-1 deprecation is right in line with our stated policies - we notify developers of a deprecated feature and eventually remove support. We are not removing support for SHA-1 until 2017. Likewise, none of this discussion is about dropping support for TLS1 or TLS1.1, non-PFS TLS, non-AEAD TLS (although that would be nice to drop soon), nor rejecting certificates that don't have OCSP stapling.

It's about finding a gradual degradation point where insecure practices are not the norm, and secure is the default.

To put this more concretely, in light of your response on SHA-1 and other CAs' requests for multi-year commitments on insecure behaviours being supported, it is entirely possible that some policies could change as soon as Chrome 41 or Chrome 42. In particular, changes to UI or communicating via DevTools to developers are the first steps in orderly deprecations, and so they will necessarily happen on a more aggressive timeframe than any CA desires (since all CAs have market incentives for nothing to ever change). It's the final removal that would be more pressing.
 

BTW, it seems odd that the Chrome Root Certificate Policy page [1] doesn't even mention your SHA-1 deprecation plan!  Does that mean it's not actually your policy yet?!?

[1] http://www.chromium.org/Home/chromium-security/root-ca-policy

Chrome still accepts SHA-1, and CAs are still permitted to issue SHA-1 (until the CA/Browser Forums' deprecation date of 1 Jan 2016). Heck, Chrome still accepts SHA-1 beyond the "must not expire after" date of 1 Jan 2017, to permit the pre-BR 1.2.3 certs that existed with SHA-1. The only thing changed is that the UI indicates that this is a deprecated algorithm and will, in the future, (on 1 Jan 2017, to be precise), be removed.

This is perhaps the longest deprecation warning in Chrome's history to date, precisely because it's going to take that long for everyone to make an orderly migration.

Peter Bowen

unread,
Dec 2, 2014, 11:01:17 AM12/2/14
to Ryan Sleevi, Rob Stradling, security-dev, Richard Salz, net-dev, Ben Laurie
On Tue, Dec 2, 2014 at 5:24 AM, Ryan Sleevi <rsl...@chromium.org> wrote:
> On Mon, Dec 1, 2014 at 1:51 PM, Rob Stradling <robs...@gmail.com> wrote:
>>
>> You did make a policy announcement about your SHA-1
>> deprecation plan, with a timescale that most (if not all) of the CAs
>> considered to be unfairly aggressive. You used the fact that a discussion
>> had taken place 6 months earlier to justify that aggressive timescale.
>>
>> That said, I'm optimistic that we won't see a repeat of this sort of
>> kerfuffle, on the basis of your post to the ct-policy list a few days ago
>> that said:
>> "When a change to the policy is announced to this list, it will be quite
>> clear that the policy has changed. Until then, the policy HAS NOT changed -
>> it is merely being discussed."
>
>> Earlier, Ryan Sleevi wrote:
>>> I would say that it's very much under early discussion, but there is
>>> hardly any commitment to require it. I would say we aren't alone in
>>> discussing it, though.
>>>
>>> However, it is worth noting that this is not a CA concern so much as a
>>> site operator concern.
>>
>> It's very much a CA concern! i.e. How many of our EV cert customers
>> whose servers can't do OCSP stapling would ask us for their money back,
>> because they can't achieve the EV indicator in Chrome?
>>
>>> If you sell a product that promises something will appear a certain way in
>>> a third party product, both now and in the future, then yes, you're selling
>>> something beyond your ability to support.
>>>
>>> It would certain be a concern for CAs if customer deployment was something
>>> you insured against. The reality is you will have sold them a product that
>>> meets all of your technical obligations, and it is a matter for the customer
>>> to operationally deploy.
>>>
>> That the CA has met all of their technical obligations isn't much of a
>> sales pitch for EV certs, unfortunately.
>>
>> Like it or not, customers buy EV certs because they want the green bar to
>> appear in their customers' browsers.

From this thread and others, it seems clear there is not a general
agreement on what product the browsers are asking CAs to provide. It
does appear that customers (both browser users and server operators)
are asking for a product that allows them to cause the browser to
provide certain UI features, namely a "secure" icon (for all "SSL
certificates") and a "green bar" (for "Extended Validation"
certificates).

Is there a clear statement of what Chrom(e|ium) expects of CAs? The
root certificate policy page has a little of it, but it does not
appear to clearly convey the full picture.

Thanks,
Peter

Ryan Sleevi

unread,
Dec 2, 2014, 11:38:23 AM12/2/14
to Peter Bowen, Ryan Sleevi, Rob Stradling, security-dev, Richard Salz, net-dev, Ben Laurie


On Tue, Dec 2, 2014 at 4:01 PM, Peter Bowen <pzb...@gmail.com> wrote:

From this thread and others, it seems clear there is not a general
agreement on what product the browsers are asking CAs to provide.  It
does appear that customers (both browser users and server operators)
are asking for a product that allows them to cause the browser to
provide certain UI features, namely a "secure" icon (for all "SSL
certificates") and a "green bar" (for "Extended Validation"
certificates).

Is there a clear statement of what Chrom(e|ium) expects of CAs?  The
root certificate policy page has a little of it, but it does not
appear to clearly convey the full picture.

Thanks,
Peter

I guess whether or not it's clear depends on where the ambiguity is, nor does it fully consider that there's additional parties here as well - namely, the server operator and the content author.

TL;DR: CAs are expected to not just follow industry "best practices" - which they define - but to adapt to evolving cryptographic threats. Server operators are similarly expected to follow not just "cryptographic best practices" but to avoid "deprecated things". Content authors are also expected to follow "content best practices" and not combine insecure practices on secure pages.

TL;DR the TL;DR: CAs are expected to follow the Root Policy as stated. But that doesn't guarantee UI treatment. It's the combination of (Certificate Issuance [CA], Server Deployment [Server Operators], and Content [Content Authors]) that collectively determine the UI.


WARNING: Here be long explanation with lots of links to past or ongoing work.

The expectations of the server operator are spread in a variety of places, and I don't see that necessarily changing, since it's a context dependent operation.

For example, https://w3c.github.io/webappsec/specs/mixedcontent/ details a set of expectations on content authors, which are then transitively inherited by work such as https://fetch.spec.whatwg.org/

Similarly, specifications such as http://http2.github.io/http2-spec/index.html#TLSUsage set expectations on server operators (which may, and frequently are, different than the content authors)

There are also specifications that attempt to place requirements that are largely ignored. A prime example of this is the CA/B Forums original requirements for EV processing, which as of Ballot 89, was downgraded to a "guideline" of best practices ( see https://cabforum.org/wp-content/uploads/Recommendations-for-the-Processing-of-EV-SSL-Certificates.v.2.0.pdf for the revised version, although I can't find the original that was last modified by Ballot 24 ). Another example is the WSC-UI work - http://www.w3.org/TR/wsc-ui/

The expectations of server operators changes over time. For example, SSL3 is no longer acceptable for a server operator to use and expect a secure indicator (in fact, it won't work). Similarly, for content authors that were delivering content via wss:// or XHR, which were previously treated as 'optionally blockable' (to use the term from the Mixed Content draft - https://w3c.github.io/webappsec/specs/mixedcontent/#category-optionally-blockable ) are now treated as 'blockable' ( https://w3c.github.io/webappsec/specs/mixedcontent/#category-blockable ). 

Mixed Content (which is under active evolution) has a term for what we're discussing here in the general case - see https://w3c.github.io/webappsec/specs/mixedcontent/#deprecated-tls-protection , which builds / expresses a similar concept to the WSC-UI's mode of weak TLS - http://www.w3.org/TR/wsc-ui/#def-weak-tls

The items under discussion are areas that the IETF HTTP/2 WG has recognized as "minimum security, going forward". They're also recognized by the IETF TLS WG as the minimum going forward for future iterations of TLS (see http://tlswg.github.io/tls13-spec/#major-differences-from-tls-12 and draft-02 ). The OCSP stapling requirement is very much in line with the CA/Browser Forum's Recommendations for the Processing of EV SSL certificates, as OCSP Stapling is the only existent, reliable means for leaf certificate revocation.

My point in this lengthy message is that we're not discussing requirements or expectations of CAs, but of content authors and server operators. Further, we're using messaging channels available to signal that some practices are deprecated. There's no question that the lack of such signaling for things like SSL3 has lead to POODLE, or for TLS1 has lead to BEAST. Going forward, we (as an Internet community) must do better at adapting to emerging threats, deprecating insecure practices, and ensuring that when communicating something as secure, it has a reasonable chance at meeting users' expectations.

Now, to cycle back on your original question, what does Chromium expect of CAs? Well, the expectations of CAs (but neither content authors nor server operators, as they are DIFFERENT parties) are indeed spelled out there. CAs are expected to follow the EV guidelines. They're expected to support to Certificate Transparency (through either of the two methods available specifically to CAs). They're expected to follow cryptographic best practices.

However, that doesn't guarantee special UI. If Chrom(e|ium) is going to communicate that a resource is "secure", then it's also contextually dependent upon the server deployment (which includes TLS versions, ciphersuites, extensions, as well as state such as revocation or CT) and the content author (mixed content, for example)

Reply all
Reply to author
Forward
0 new messages