<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 30, 2020 at 12:56 PM Ben Wilson <<a href="mailto:bwilson@mozilla.com">bwilson@mozilla.com</a>> wrote:<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 dir="ltr"><div dir="ltr">Hi Ryan,</div><div dir="ltr"><br></div><div>See responses below.</div><div><br></div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 26, 2020 at 1:40 PM Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>> wrote:<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 dir="ltr"><div>Thanks for sharing this, Ben. I appreciate the detailed motivations.</div><div><br></div><div>This seems like a rather significant and substantial change to the security properties of CAs. I'm a bit nervous about the "or Delegated Third Party" inclusions here, this seems like it would reduce the effective security controls rather substantially, right?</div><div><br></div></div></blockquote><div>
<font size="2"><span style="line-height:107%;font-family:Calibri,sans-serif">The
NCSSRs have always applied to Delegated Third Parties (DTPs), and DTPs are
required to comply with them. For this ballot, we're trying to minimize the
changes by focusing on the removal of the term “zone” and thereby limit the
number of changes that we are making to the NCSSRs as much as possible. DTPs are
mentioned at the beginning of section 2, and were already mentioned in section 2.n.
“Enforce Multi-Factor Authentication for all Trusted Role accounts on
Certificate Systems (including those approving the issuance of a Certificate,
which equally applies to Delegated Third Parties) ….”<span> </span>By adding “the CA’s or Delegated Third
Party’s network” we are only replacing “Secure Zone” and “High Security Zone”.</span></font></div></div></div></div></blockquote><div><br></div><div>Right, but that "replacing" is actually substantive, and it's not an equal substitution; it's being replaced with something potentially more lax. By replacing the Zone terminology, you're replacing the physical separation that was inherently extended onto DTPs and substituting it something that is purely logically controlled.</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 dir="ltr"><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 dir="ltr"><div></div><div>There's also a host of other things that I think merit raising an eyebrow. For example, "lockable enclosures" doesn't require that they actually be secured in locked enclosures, just that they could be. For example, if I always left my cage unlocked, it still seems like it would be fully compliant.</div><div><br></div></div></blockquote><div>
<font size="2"><span style="line-height:107%;font-family:Calibri,sans-serif">This
point was discussed in the committee. We noted, for instance, that as amended, section
5.1.2 would say, “CAs SHALL ensure that CA Equipment is protected by physical
locks equipped with access control devices”.<span> We believed that common sense and that this and other language would not lead CAs to believe that they could leave cages, etc., unlocked.
</span>However, we can reword this amendment to BR section 5.1.1. and use the
term “locked enclosures.”</span></font></div></div></div></blockquote><div><br></div><div>Sure, but I suspect some CAs will then complain they can't unlock and now they're violating the NCSSRs. I understand that concern, but I think it captures what I think is the underlying issue: you have a steady state of security and you want any reduction of that (e.g. bringing an offline system online, unlocking a cage/server) to be done ONLY with the appropriate controls and only for the time necessary. The steady state isn't that something merely exists, but that it exists and is in use to achieve the result.</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 dir="ltr"><div class="gmail_quote"><div><font size="2"><span style="line-height:107%;font-family:Calibri,sans-serif"> </span></font>
</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 dir="ltr"><div></div><div>I'm quite worried about the introduction of "trusted networks" into the NSRs. This was, of course, a concern Google raised as far back as 2012 when discussing the NCSSRs, as trusted networks generally encourage unsafe assumptions. This concept appears in several places (1.e, 2.g, 2.n)</div><div><br></div></div></blockquote><div>
<font size="2"><span style="line-height:107%;font-family:Calibri,sans-serif">The
NCSSRs have always recognized a distinction between a CA’s network and an outside
network. We can address the issue you raise in a subsequent ballot. </span></font></div></div></div></blockquote><div><br></div><div>I think it's actually fundamental to any removal of Zones. The consequence of this proposal is that it seems to remove the important physical and logical separation, with access controls, and move it into purely logical separation, and with no clearly specified controls. Moving from VLAN tagging at Layer 2 into Firewalls at Layer 3 is, itself, a degree of non-trivial scope change.</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 dir="ltr"><div class="gmail_quote"><div><font size="2"><span style="line-height:107%;font-family:Calibri,sans-serif">Here, in
this ballot, we have only added the "non-trusted network" distinction
in section 1.e. (as an alternative to "public network").<span> </span>We believe that “non-trusted network” is a good
alternative to “public network”.<span> </span>In
response to your concern, however, there is nothing to suggest that
"trusted" networks peculiarly suffer from insecure practices just
because they are considered "trusted". </span></font></div></div></div></blockquote><div><br></div><div>I don't think we'll agree here. The problem with the "trusted" / "untrusted" is that the moment a beachhead is possible, you can horizontally pivot throughout that trusted network. Treating some IPs as trusted, for example, is not really as secure as treating everything as hostile and requiring appropriate authentication proof. You limit the ability to laterally pivot by requiring continuous authorization.</div><div><br></div><div>This gets to the heart of the above comments about zones encompassing both physical and logical controls. I worry that one effect of this ballot is that it would be seen as acceptable for CAs to wire up their issuing root or intermediate directly to the Internet. Using a firewall doesn't really provide much assurance here, both in terms of the quality of firewall software, both from bugs and insider risk (e.g. Juniper Networks), and yet this seems to shift all the presumed security there.</div><div><br></div><div>Similarly, sticking it in a datacenter rack on the same shared network is exactly the sort of thing I would think we would to discourage, as much as possible.</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 dir="ltr"><div class="gmail_quote"><div><font size="2"><span style="line-height:107%;font-family:Calibri,sans-serif">Similar to what is allowed for
a Trusted Role to perform, a trusted network is one in which different security
policies are allowed to exist. A non-trusted network would be one that is not managed,
owned and operated, by the CA. It is non-trusted because the CA is not in a
position to control or detect anomalous behavior occurring within it. So there
is a monitoring element to the distinction between the two. In a perfect world,
we would not have any trusted networks and rely entirely on strongly attestable
properties of endpoints communicating across the non-trusted substrate, but the
state of the technology is not there yet, so enclaves of traffic restricted
communications are the current state.<span> </span>We
would be interested in knowing why you think that trusted networks are inadequately
secure in light of the NCSSRs; and in future iterations, we can build in
additional requirements.</span></font>
</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 dir="ltr"><div></div><div>It's not clear to me that this, overall, is a net improvement. That is, it seems to weaken the logical security controls, while allowing a substantial mixing of the physical security controls. I would think that, in general, we would be better served by ensuring such zones are both logically AND physically distinct, but this seems to allow mixing such access entirely; as you note, High Security Zone and Secure Zone are now functionally indistinguishable.</div><div><br></div></div></blockquote><div>
<font size="2"><span style="line-height:107%;font-family:Calibri,sans-serif">The
current NCSSRs never had a High Security logical zone. "High
Security" was defined as a physical location. We are working on improving the
distinction between physical and logical security and strengthening logical
security requirements. In fact, we have a draft ballot for offline CAs that separates
out physical and logical security.<span> </span></span></font></div></div></div></blockquote><div><br></div><div>I don't follow this, and I'm worried about the direction it portends. The High Security Zone and the Secure Zone are logically distinct zones, by virtue of Secure Zone's definition. While the requirements on the High Security Zone in the definitions are described in the physical, I hope CAs weren't treating it as the same logical zone as the Secure Zone, particularly when thinking about 1.c / 1.e. While I definitely welcome the clarity, I worry that folks might not have been observing the necessary airgaps set forth in 1.c if they're treating the High Security Zone as part of the same logical zone as the Secure Zone?<br></div></div></div>