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

[Ryan Sleevi]

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

>
>
>
>
> On Thu, Aug 1, 2019 at 1:50 PM Doug Beattie <doug.beattie at globalsign.com>
> wrote:
>
> *From:* Ryan Sleevi <sleevi at google.com>
> *Sent:* Thursday, August 1, 2019 12:33 PM
> *To:* Doug Beattie <doug.beattie at globalsign.com>; CA/Browser Forum
> Validation WG List <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> 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?


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


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


>
>
> 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/ac67aaf3/attachment.html>