[Servercert-wg] SC32: Remove “zone” from NCSSRs and add provisions to BR 5.1

[Ryan Sleevi]

On Tue, Jun 30, 2020 at 12:56 PM Ben Wilson <bwilson at mozilla.com> wrote:

> Hi Ryan,
>
> See responses below.
>
> On Fri, Jun 26, 2020 at 1:40 PM Ryan Sleevi <sleevi at google.com> wrote:
>
>> Thanks for sharing this, Ben. I appreciate the detailed motivations.
>>
>> 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?
>>
>> 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) ….”  By adding “the CA’s or Delegated Third Party’s
> network” we are only replacing “Secure Zone” and “High Security Zone”.
>

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.


> 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.
>>
>> 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”.  We
> believed that common sense and that this and other language would not lead
> CAs to believe that they could leave cages, etc., unlocked. However, we
> can reword this amendment to BR section 5.1.1. and use the term “locked
> enclosures.”
>

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.


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

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.


> Here, in this ballot, we have only added the "non-trusted network"
> distinction in section 1.e. (as an alternative to "public network").  We
> believe that “non-trusted network” is a good alternative to “public
> network”.  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".
>

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.

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.

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.


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

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200630/7038d264/attachment.html>