<div dir="ltr"><div>On Thu, May 30, 2019 at 3:32 PM Ben Wilson <<a href="mailto:ben.wilson@digicert.com">ben.wilson@digicert.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US">
<div class="gmail-m_8232550529275604339WordSection1">
<p class="MsoNormal">Hi Ryan,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">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.</p></div></div></blockquote><div><br></div><div>Note, it's a subcommittee (see SC10). My pedantry for precision is ever present :)</div><div><br></div><div>I realize that the Netsec group has set up their own mail list ( <a href="https://cabforum.org/pipermail/netsec/2019-May/thread.html">https://cabforum.org/pipermail/netsec/</a> ) 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 :)</div><div><br></div><div>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. :)</div><div><br></div><div>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.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_8232550529275604339WordSection1"><h3><u></u></h3>
<p class="MsoNormal">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.</p></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_8232550529275604339WordSection1">
<p class="MsoNormal">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).</p></div></div></blockquote><div><br></div><div>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'.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_8232550529275604339WordSection1">
<p class="MsoNormal">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.
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">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.</p></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_8232550529275604339WordSection1">
<p class="MsoNormal">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.</p></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_8232550529275604339WordSection1">
<h3><a name="m_8232550529275604339__cabpr2tm4q2m"></a>List of 8 configurations<u></u><u></u></h3>
<p class="MsoNormal">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.
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">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.</p></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_8232550529275604339WordSection1">
<h3 style="margin-bottom:10pt"><a name="m_8232550529275604339__poz4wb6oyws2"></a>7-day response timeline<span style="font-family:Roboto;color:rgb(131,131,132)"><u></u><u></u></span></h3>
<p class="MsoNormal">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. </p></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_8232550529275604339WordSection1"><p class="MsoNormal">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. </p></div></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_8232550529275604339WordSection1"><div><blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
</blockquote>
</div>
</div>
</div>

</blockquote></div></div>