[Servercert-wg] Ballots SC20 and SC21

[Ryan Sleevi]

On Fri, May 31, 2019 at 1:02 PM Tobias S. Josefowitz <tobij at opera.com>
wrote:

> On Fri, 31 May 2019, Ryan Sleevi wrote:
>
> > Let T=0 be the time I perform my weekly review.
> > Let T=7 be the time I'm required to perform my next weekly review
> >
> > If a configuration change is made, authorized or not, at T=3, then under
> > the existing 1.h, it will be detected at T=7
> > Under the proposed change, it may not be detected until T=10, which is +7
> > from the introduction.
>
> Practically speaking, assuming compliance with the proposed changes,
> detection at T=10 for this is only possible if the CA performed a check at
> the instance right before T=3, or else an unwanted change introduced at
> one instance before T=3 would not be detected within 7 days, i.e. an
> instance before T=10. Whatever the implementation would be (unless maybe
> in case it is designed solely to fulfil the requirements in the most and
> obvious degraded ways),


This is my operating assumption, which has been borne out of the incident
reports and issues seen.


> you would have to assume it checks configuration
> necessarily in certain minimum units, so I do not see how you could be in
> compliance, and detect a T=3 change at T=10 only while detecting an
> instance before T=3 change an instance before T=10. Or in other words, the
> "laziest" implementation would check configurations short of weekly.


> Furthermore, I would argue that CAs have nothing to gain by designing a
> system that is degraded and nonsensical and only detects changes in the
> last possible instance, hence I really don't see why they would go through
> the *effort* of doing that anyway.
>

I don't share this optimism. As a practical matter, I expect the time
between checks to be *greater* - that is, rather than checking every T=7
days, they'll move to check every T=10 or T=14. As long as nothing goes
wrong, they're wholly in compliance with the /new/ requirements, whereas
they'd be out of compliance under the /existing/.

Now, yes, obviously, if they have an issue, they're in violation. But I
don't have the view that many CAs optimize to ensure no violations, but
rather optimize to make sure their violations to costs are something that
the CA determines is acceptable, which is often disproportionate with how
Browsers/Relying Parties view the same risks/costs. A classic example has
been the approach to domain validation, or the laxness thereof, which has
been a significant undertaking for the validation group.

If your assumption is that CAs will implement a weekly check, then it needs
to be stated as such. I think that makes a good /additive/ change, but
that's why I don't think replacing the requirement is great.


>
> Ideally, CAs would clearly monitor configurations *continuously*, but CPUs
> have a frequency, and the tools that come to mind for use in an
> implementation also typically operate periodically, and there has thus
> been a bit of a scare in the SC about requiring "continuous", because it
> is impossible to do with strict enough interpretations of what that means.
>
> Furthermore, the intention of SC20 is for human review/implementation/...
> still being a valid implementation, which is especially relevant for
> transition to the new rules as well as offline systems, which is another
> reason why the timeline even is set as high as seven days.
>
> Back to the point, I still do simply not see how a CA would be in
> compliance while having implemented a process/system that detects after
> min=max=7d; or even how "detect within at most 7 days" can in this case be
> worse than "review weekly".
>

Hopefully the above shows how, as a practical matter, the proposed changes
would create a deferral of detection of non-compliance to being when
there's an issue and a NetSec violation, rather than the current approach,
which would flag it during audit. As I said, I can see value in both
approaches, but that's why I think it needs to either be clearly stated
both the implementation and the result, which is additive, rather than
replacing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190531/3a968a8a/attachment.html>