[cabf_validation] FW: FW: Draft Ballot SCXX: Improve Certificate Lifetimes

Thu Aug 1 12:26:56 MST 2019

I replied to a couple of points below, but to summarize this discussions:

1.	The Proposer/endorsers will provide a good write up of why these changes are needed and why they are needed in the specified timeframe
2.	Shortening the certificate validity and domain-re-use together is necessary to meet the intended goals
3.	The reuse period for Organizational data is open for discussion and doesn’t necessarily need to be the same as the validity period

Most of the other discussion topics relate to why the change is needed, and that will be written up as part of #1 above.

Doug

From: Doug Beattie <douglas.beattie at gmail.com> 
Sent: Thursday, August 1, 2019 3:03 PM
To: Doug Beattie <doug.beattie at globalsign.com>
Subject: Re: FW: [cabf_validation] FW: Draft Ballot SCXX: Improve Certificate Lifetimes

On Thu, Aug 1, 2019 at 2:58 PM Doug Beattie <doug.beattie at globalsign.com <mailto:doug.beattie at globalsign.com> > wrote:

From: Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> > 
Sent: Thursday, August 1, 2019 2:43 PM
To: Doug Beattie <doug.beattie at globalsign.com <mailto:doug.beattie at globalsign.com> >; CA/Browser Forum Validation WG List <validation at cabforum.org <mailto:validation at cabforum.org> >
Subject: Re: [cabf_validation] FW: Draft Ballot SCXX: Improve Certificate Lifetimes

On Thu, Aug 1, 2019 at 2:28 PM Doug Beattie via Validation <validation at cabforum.org <mailto:validation at cabforum.org> > wrote:

On Thu, Aug 1, 2019 at 1:50 PM Doug Beattie <doug.beattie at globalsign.com <mailto:doug.beattie at globalsign.com> > wrote:

From: Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> > 
Sent: Thursday, August 1, 2019 12:33 PM
To: Doug Beattie <doug.beattie at globalsign.com <mailto:doug.beattie at globalsign.com> >; CA/Browser Forum Validation WG List <validation at cabforum.org <mailto:validation at cabforum.org> >
Subject: Re: [cabf_validation] Draft Ballot SCXX: Improve Certificate Lifetimes

On Thu, Aug 1, 2019 at 11:56 AM Doug Beattie via Validation <validation at cabforum.org <mailto:validation at cabforum.org> > wrote:

Ryan,

GlobalSign is not in favor of this ballot for a number of reasons, but maybe some changes or improved reason for your changes will help.

Over the past several years, this topic has come up many times and the proponents have made their cases.  What would help us is a consolidated set of security/ecosystem benefits of this change.  I know you’ve provided lots of reasons in the past, but a static blog or announcement page with the complete set of driving reasons would help everyone understand exactly where you’re coming from.  We can use this as we communicate the change to our customers and then everyone has the same understanding of the importance of this change.

Sure, I can totally appreciate the value in that. Do you want to take the lead on that, to help articulate some of the benefits as you see them?

Not really…  Google, Mozilla and others are leading the initiative to reduce the maximum validity period and data re-use policies, so I think this is best done by those pushing for this change.  I don’t think many/any CAs support this change.

Ok, I can understand that.

The way you framed it, suggesting changes can help, led me to believe you think there's a path forward for GlobalSign to support this, and this was one of the things that would help ensure that. It sounds like that may not be the case, and that such an exercise may not actually help CAs?

I don’t want to rule out GlobalSign’s support of this ballot.  As a CA, we can issue short or long validity certificates, we can ask customers to update their domain validation more frequently – it’s not an issue for us.  We hear from our customers that this is an issue.  I think that a good argument for shortening the period will show why this is a good idea to CAs and to the community in general.  As it stands, we end up not being able to articulate positions that we don’t necessarily agree with, so having a statement from you detailing the need for this change at this time will help.  Also providing justification for the timeline (March 2020 vs. March 2023)

This ballot proposes changes to several components and not just the maximum validity period.  I’d like to understand the reasons for each, perhaps in the above proposed blog.

*	Maximum validity period: Yes, this is the driving reason for the ballot, I understand that.
*	Maximum re-use of domain validation data: Is limiting this to 13 months necessary?  If this is the primary reason for the ballot, then is the reduction in certificate validity necessary?  How do these 2 changes relate to each other?  Do these have to match, and if so, why?

I actually think we need to get this particular bit down as aggressively as possible. From a security point of view, the ideal end state is zero reuse of domain validation data. We already have that for CAA, and it has not caused significant harm.

 It’s not clear how you’re relating CAA and domain validation checks when it comes to realtime checks.  For CAA the domain owner may, at their discretion, may put in a record one time, then CAs check it each time.  Having a challenge response for domain validation is operationally completely different since it requires the domain owner to take action on every request.

Believe it or not, there are a lot of enterprises that manually request certificates and don’t want or use automated systems for domain validation or issuance (2 separate topics).

Having been responding to so many of the Incident Reports, I'm pretty aware that there are a lot of organizations that manually request certificates. Sometimes that's because that's the only path the CAs offer, sometimes because they haven't seen the benefits in changing, and sometimes for arguably legitimate reasons. I think one of the takeaways that a number of CAs seemed to touch on in their responses, in terms of their ability to respond timely to security incidents, was their desire to reduce their certificate lifetime to reduce the impact of incidents and the challenges folks encountered. I highlight this because I'm not sure there's industry consensus that manually requesting is good; but, luckily, this proposal doesn't prohibit it, just internalizes some of those externalized costs.

Regarding the comment about reduced validity periods to reduce the scope of revocations:  I don’t agree with that.  Most revocations are for certificates issued in the recent past and that that wouldn’t change.  Yes, there are some exceptions, but I don’t think that is a driving factor in wanting shorter validity periods.

Regarding manual issuance: Yes, automated systems are good, but not everyone wants to put agents on their servers communicating out to CAs, or in building reliance on this within their datacenters.  Change control is important and not everyone has moved to fully DevOps managed systems.  When they do, then sure, automation is the way. 

The reasoning for this should be obvious, as we had an entire presentation about this at a past CA/Browser Forum F2F - BygoneSSL. The attacks demonstrated there are real and practical, and an artifact of the reuse of domain validation data. We've always treated these in lockstep together, and so this isn't a new trend.

While it’s possible for this to happen, I’m suspicious this is a real threat that has, or could be, used to cause real harm on the internet.  The attacker needs to track all domain expiration dates then needs to take control of the abandon service in addition to the domain (so they can access the users private key).  Am I missing the point here?   If this is the basis for moving to shorter validity and shorter domain validation periods, then it’s a very weak case.

Yeah. It may be worthwhile to revisit the presentation. There's no requirement to access the user's private key. That is, the attacks are (and have been; as in real harm) carried out by relying on CAs reusing domain validation data that is 'stale' and not accurate. This is especially important as the ecosystem continues to involve, such as some of the proposals with the HTTP/2 ORIGIN frame or TLS Secondary Certificates. The reuse of domain validation, as presently practiced, dramatically alters the security and threat model for these technologies that could significantly improve the speed and stability of the Internet. Unfortunately, because the costs of the reused validation are externalized, it's often difficult to realize this impact.

Yes, I acknowledge that stale domain validation data has been used, but I don’t know of any malicious attacks leveraging that.  In the whole scheme of things, way more harm is done via phishing sites and malware that a couple of stale domains getting SSL certificates provisioned.

Hopefully the blog, post or whatever that is written to describe why these changes are needed will include accurate descriptions of the BygoneSSL

A non-trivial amount of the security value of reducing lifetimes is missed if we don't reuse validation lifetimes here. 

OK, I can see that the certificate validity and domain re-use are coupled.

*	Maximum reuse of Organizational data: Is this necessary to be done every 13 months?  Would you accept a proposal of keeping this at 27 months while reducing the above 2 items?

To the extent we believe the organizational information is bound to the domain, it's difficult to treat these independently. That said, I can understand and appreciate the challenges involved with vetting the organization information from a QIIS and QGIS. I think there may be opportunities to improve how CAs monitor QIIS/QGISes for informational changes - similar to how CAs are required to respond to changes in WHOIS information.

As a practical matter, because browsers don't make use of OV-vetted information, I admit, I haven't paid close attention to the validation rules there. I suspect there may be an opportunity to allow reuse of the QGIS/QIIS information, provided the CA vetted it was current, and provided the CA vetted the relationship with the domain operator (i.e. no reuse of validation data for the domain portion). That could allow extended reuse of organization information, while ensuring it's not stale, as we saw with BygoneSSL.

I’m not following this.  Are you saying that you’re open to discussing keeping the reuse of QGIS/QIIS information at 27 months?

I'm suggesting there's a path to keep some of the information reusable on a different timescale as the domain validation, yes. I'm acknowledging that domain information and organization information fundamentally change at different rates, and the steps involved in validation move at different rates. I'm open to finding ways to decouple these, which might allow the validity periods to reflect that, but I'm also wanting to make sure it's done securely. I tried to sketch out what 'securely' would mean here, if CAs would like to further develop it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20190801/8f022cba/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5701 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20190801/8f022cba/attachment-0001.p7s>