[Servercert-wg] Ballots SC20 and SC21

[Tobias S. Josefowitz]

On Thu, 30 May 2019, Ryan Sleevi via Servercert-wg wrote:

> On Thu, May 30, 2019 at 3:32 PM Ben Wilson <ben.wilson at digicert.com> 
> wrote:

[...]

> Having it on GitHub (or even a Word doc) helps understand the evolution of
> the space, much like our many "V1 / V2 / V3" ballots do. All of these
> promote more active and productive collaboration. If the intent is for
> subcommittees to respond "as a group", then I think that may inform how
> Google views subcommittees going forward. :)

There are "Google Doc"s that have a record of the respective evolution, as 
well as attribution, for the (maybe to be) ballots SC20, SC21. The ballots 
have been developed as ballots, not by editing the NSRs and making a 
ballot of the edit. Shareability of "Google Docs" cannot compete with 
public GitHub-hosted git repositories, in fact I do not have the 
permission bits to share the documents with you. I would however not 
fundamentally refute any claim that could hypothetically be made as to 
"Google Docs" being the more suitable tool when it comes to editing 
documents, as compared to GitHub+git+...

Possibly a better process needs to be found for sharing these documents, 
or maybe we should simply refrain from using proprietary cloud-based 
service offerings for collaboration.

> One way we can perhaps improve transparency is if you want to open up pull
> requests, which at least allows for the use of GitHub to engage in more
> direct comments and feedback, and to track its evolution.

"Google Docs" was however used in exactly this way.

>> We want to encourage CAs to monitor system configurations instead of
>> reviewing them manually. Under the current section 1(h) a CA might only
>> detect a security-relevant configuration change after 6 days without
>> violating the NSRs. In contrast, a CA that monitors system configurations
>> continuously can react to such a change within hours or minutes.
>> Additionally, they will be able to perform more in-depth analyses than the
>> routine, broad analyses they might otherwise perform.
>>
>
> I do not believe this is correct. The proposed change does not change the
> requirements positively in this way. Instead, it reduces the obligations
> (and thus extends the maximum timeline before remediation), as explained
> previously.

When you say "explained previously", do you refer to "I worry that it 
actually does the opposite, by giving significant more leeway to the 
interpretation of CAs and auditors as to what constitutes security 
relevant", or to "7 days to deviation detection [...] I believe [...] will 
be more harmful than good.", to both, or to something else?

>> It is not our intention to provide more discretion to CAs or auditors, but
>> to gain clarity as to what monitoring is the minimum requirement. This is
>> important because in order to design their system monitoring controls, CAs
>> require a definition of which security metrics should be monitored.  Ballot
>> SC-20 outlines those configurations that the NetSec committee considers
>> security-relevant (as a minimum).
>>
>
> Then the ballot needs to be changed, because as written, it allows for
> subsetting the existing systems and thus excluding, from scope, items which
> are presently in scope. Further, it does not clarify that it serves as a
> minimum, nor does it express the principles for what might be seen as
> appropriate for additional scoping, which has the consequential effect
> (with the previous change) of thus being seen as setting a 'maximum'.

The mechanism that you refer to/propose for "exlcuding items from scope" 
would here be by going from "Review configurations" to "shall identify 
which configurations [...] are security relevant. [...] violations shall 
be detected within at most seven (7) days", or do you see another one 
even?

> Except, for relying parties - and importantly, for browsers - this removes
> a degree of transparency and certainty in interpretation, and instead
> replaces it with ambiguity and discretion. This is why I say this change is
> also a net-negative.

The mechanism leading to loss of transparency and certainty in 
interpretation also being ... moving away from "Review configurations"?

>> It is likely that under the current NSRs, CAs already make determinations
>> on how the term ?configuration? should be understood in the context of
>> their system environment. Thus, we do not see our proposal to reduce
>> security. Rather, we aim to make a common process visible and measurable.
>>
>
> Visible and measurable to whom? I see nothing to improve confidence of
> Browsers and Relying Parties, and I see that as problematic, in combination
> with the previous remarks.

To whoever would be tasked to perform an audit.

>> 7-day response timeline
>>
>> The 7-day timeline is not intended to prolong the permissible response
>> time, it is intended to enhance the response time. A CA which performs
>> configurations ?on a weekly basis? will in the worst case not notice a
>> configuration change earlier than within 7 days after it occurred. If the
>> ?weekly basis? is applied as ?once per week? it might even be longer.
>>
>
> As noted, the math here shows the worst case is now the 'minimum'
> requirement under this proposal. The existing requirements, while sharing
> the 'worst' case, have a significantly better 'best' case, which is more
> auditable as such.

Well, except, how do you systematically *not* detect an issue in your 
configuration for six days? If you have to detect within seven days, I 
would suppose you have to check ... within seven days, i.e. at least 
weekly, and once you detect, you detected.

>> The current requirements only define the timeline for a review, but do not
>> provide a timeline to address any potential issues identified from the
>> review or require that CAs have a process by which they review and act upon
>> any deviations. The proposal requires that CAs proactively investigate and
>> react in accordance with the CA?s incident response procedures.
>>
>
> I'm not sure the relevance of the first sentence to the second sentence.
> The second sentence does not change any of the statement of the first
> sentence. It's possible that this is an issue where what the ballot
> proposes, and what the language says, are misaligned, which is why I draw
> attention to this.

It is not unfathomable one could hold the opinion that binding CAs to 
action in the event of detection of policy-violating (or "unwanted") 
configuration changes would make up for slightly prolonging a mandatory 
timeline in certain cases if a changed overall approach to the base 
problem makes it necessary, or makes it inconvenient to match the previous 
timeline in all cases.