[cabf_validation] Draft Ballot SCXX: Improve Certificate Lifetimes

[Ryan Sleevi]

On Thu, Aug 1, 2019 at 11:56 AM Doug Beattie via Validation <
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/26c29711/attachment.html>