[cabfpub] Ballot 210: Misc. Changes to the Network and Certificate System Security Requirements

Neil Dunbar ndunbar at trustcorsystems.com
Tue Aug 15 16:54:44 UTC 2017


> On 15 Aug 2017, at 17:08, Ryan Sleevi <sleevi at google.com> wrote:
> 
> The challenge, which I think is worth articulating even as I try to form a suggestion, is that it creates ambiguity as to what's "sufficiently not stupid".
> 
> For example: Is a physical host running a hypervisor sufficiently isolated from its guests? (Maybe, maybe not - and if not, popping the hypervisor is sufficient to gain lateral access).
> For example: Is a physical host with two dedicated NICs, each going to different segments, sufficiently isolated? (Arguably, no, it's effectively a bridging state - but that may be non-obvious to some CAs, based on past evidence)
> For example: Is a switch handling VLAN tagging sufficiently segmenting? (Maybe, maybe not - popping the switch would be sufficient to gain lateral movement)
> 
> Even if we have roots in a fully (physically) airgapped configuration, for the online issuance, we need to have some interaction between the untrusted 'outside' and the trusted 'inside' - and wanting to make sure we've got something sufficient enough that it would survive a pentest seems a reasonably low bar. The problem is articulating that.

I think that’s it’s a reasonable context to say that no host can be allowed to even logically bridge networks - but that, IMO, is an addition to the existing NetSec rules. A perfectly reasonable one, but outside the scope of “clean up some obsolete text”.

So a dual NIC’ed host can have bonded NICs, or failover NICs - but they must all hook to the same network segment. *For the moment* I take the view that hypervisors can only hold guests which are part of the same logical network. There is further discussion on virtualisation and cloud stuff to come, but we’re not there yet.

[Note: here I’m talking about hypervisors as standard hosts. Not TPM’ed hosts running launch controlled attestation, or stuff like that]

The question of pen testing air gapped configs did come up: there is reasonable resistance, though, to connecting the airgapped system to an outside network *purely* for pen testing to happen. In other words, pen testing is a reasonable thing to request *on the assumption that the core architecture is not changed*. Otherwise you’re not actually pen testing the system under description.

For instance, if using a USB storage device to export CRLs, for instance, it’s probably reasonable to ensure that the device isn’t carrying executable content, or at least that such content cannot execute. I guess that a security sweep could cover that.

> 
> Yeah, another perspective I can totally appreciate, although not without risk :) I think we'd be in agreement that an 'admin' password and an 'operator' password is a terrible idea - but as worded, it'd be permitted (unless I'm misreading). Is the concern limited to HSMs (which, as you note, may have physically distinct controls)? Is there a way to encompass that single-factor is permitted if it's physically distinct (e.g. two different physical devices / "something you have"), but otherwise, multi-factor is required ("something you know" + something else)? Does that strike the right balance, conceptually?

I think that two physical devices required as keying material for authentication is a reasonable understanding, since that’s where we were going. Like I said, it stems from the notion that you might well have a crappy laptop which is responsible for hooking to the Root HSM for generating CRLs, etc. But the security isn’t vested in the laptop really, it’s in the HSM activation protocol. But, as things stand, your laptop would need to have MFA because that’s what the NetSec rules state. And even providing that MFA on an isolated system can be very tricky, given how OTP/U2F etc works.

The problem statement, as a whole, for this ballot was [paraphrased]: “Some of the text here is obsolete, or highlights security postures which are, at best, of limited utility, given what we know today. Can we propose some low controversy changes which don’t make the position materially worse?”. There are many other discussions and future requirements to come. This was only a first stab.

Cheers,

Neil




More information about the Public mailing list