[Servercert-wg] Ballots SC20 and SC21

[Ryan Sleevi]

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

> Hi Ryan,
>
>
>
> Here is a response from the Network Security Committee working on these
> revisions, which reach beyond what is covered in just these two ballots.
> In other words, the efforts of this group as a whole will result in
> anything but less rigor and we believe that they are indeed improvements on
> the existing language.
>

Note, it's a subcommittee (see SC10). My pedantry for precision is ever
present :)

I realize that the Netsec group has set up their own mail list (
https://cabforum.org/pipermail/netsec/
<https://cabforum.org/pipermail/netsec/2019-May/thread.html> ) for the
subcommittee - it might be easier to point to discussion and context that
discusses the evolution, which also helps understand individuals' positions
that might allow for easier follow-up. I hope this unease with "positions"
and such is unsurprising - it's the same response that has informed CA
incident responses in the public, but also discussions around, say, the
SHA-1 exceptions or the support for public mail lists in general. If we're
going to get this to a ballot, individual positions are going to be known
anyways - and individual positions need to be recorded anyways for purposes
of IP - so no need for aggregate submissions :)

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

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.

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


> 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 NSRs are silent as to how the relevant policies shall be defined and
> what they should contain.  Thus, some CAs might only review configurations
> whose alteration would result in a policy violation.
>
>
>
> Our proposal is that CAs should determine security relevance based on a
> systematic assessment. The assessment has to be documented in writing,
> which makes the applied methodology and the assessment results testable by
> the CA’s auditor.
>

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.


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


> List of 8 configurations
>
> The list of 8 configurations to review or monitor is not exhaustive. On
> the contrary, it names configurations which are considered
> security-relevant, irrespective of the CA’s assessment.
>
>
>
> During the discussion period, it is our hope that people will point out
> items that should be added in case there are elements we have overlooked.
>

As explained, I think this is a problematic approach that creates more
interpretative details. I'm glad that there's an "intent", but that intent
is not at all captured in the proposal, and so more work is needed here, to
either capture the principles or to clarify that intent unambiguously.


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


> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190530/e1756dac/attachment.html>