[cabf_validation] [EXTERNAL]Re: Draft Ballot SCXX: Improve Certificate Lifetimes

[Bruce Morton]

Binding the domain to the organization is a good approach. We used to do that when we used Method 1. Need to think about the new methodology and challenges.

Bruce.

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

Bruce,

Thanks for explaining! It seems like a pre-validation approach like that will inherently create cliffs, and is a bit of an implementation approach. Even though half would need to be revalidated, it's not clear to me if y'all have details about the actual issuance rate; that is, it's not like all of it would need to be vetted by day 0.

I guess, put differently, is it valid to question whether pre-validation approaches like that are supportable by the ecosystem? They seem to externalize the costs (e.g. the cliff we're discussing), while internalizing the benefits.

That said, I'm curious how you feel about the suggested approach I offered - ensuring a timely binding of the domain to the organization, ensuring the organization information is fresh and accurate (e.g. similar to how we check when the WHOIS information changed), while being less aggressive with some of the overall validation of that information. Would something like that work? What would be the challenges there?

On Thu, Aug 1, 2019 at 2:18 PM Bruce Morton <Bruce.Morton at entrustdatacard.com<mailto:Bruce.Morton at entrustdatacard.com>> wrote:
Regarding organization validation, there is a cliff scenario with pre-validation. In this case, a customer can have an account where their organizations are validated and available for use for 825-days. When the 397-days of reuse ballot kicks in then about half of the organization data would have to be re-validated to allow all accounts to continue to use all organization names.

I assume that if we continue to reduce the validity period, then we would create this cliff over and over again. As such, I would agree with Doug’s suggestion separate at least the organziation reuse period from the certificate validity period.

Thanks, Bruce.

From: Validation <validation-bounces at cabforum.org<mailto:validation-bounces at cabforum.org>> On Behalf Of Ryan Sleevi via Validation
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: [EXTERNAL]Re: [cabf_validation] Draft Ballot SCXX: Improve Certificate Lifetimes

WARNING: This email originated outside of Entrust Datacard.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________


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?

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.

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.

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


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


  *
  *   What’s special about 13 months, vs, say 20 months (splitting the difference)?  Can we have a more gradual reduction in the validity periods over the next ~3 years to get down to 12 or 13 months?
I think if this is the path CAs wanted to take, it would have been more useful when Gerv and I suggested this as a possible intermediate path. However, I think it's important to highlight that 13 months is the intermediate step - if we treated lifetimes the same way we, as an industry, were able to collectively address the many security holes in existing CA practices around validation, then I think we'd be moving to an end state closer to, say, 94 days.

From a browser perspective, note that we work dates backwards - trying to figure out what the latest date that insecure method X or insecure certificate Y still needs to be supported by the UA. From that perspective, the current means that it wouldn't be until Fall 2021 that we'd have reasonable confidence in the freshness of the domain information and that certificate lifetimes were bounded. That's on the upper-bound of where I've heard browsers are comfortable with. If that sort of gradual stepdown were proposed, I think it'd have the effect that practical of delaying meaningful improvement to 2024-or-later, and I think that's not really viable.

If/when the changes to domain validation and organizational data re-use go into effect, I hope that domains/organizations verified prior to a certain date can have the data re-use for the full 27 months and that on the effective date, new validations must not be re-used for longer than the new date.  This effective date can even be prior to the reduction of the maximum certificate validity period.  We want to avoid a cliff where customers and CAs have a mass number of domain and OrganizationSSL verifications to do all at once.  Been there, let’s not do that again.

I think that'd undermine a lot of the very real and pragmatic security goals here. Consider how many CAs we've seen have validation issues; if we assume (and I think it's fair to assume) there will be more validation issues in the future that are discovered retrospectively, I don't think we really end up getting much security benefit. Further, as a practical matter because of how and when certificates expire, I don't really see how we'd run into the 'cliff' scenario you mentioned - it'd only apply as people are replacing existing certificates that expired. Have I misunderstood the math?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20190801/96e1fe9f/attachment-0001.html>