<div dir="ltr">Thanks Neil, this is all super-helpful context and an excellent summary of what is no doubt months of discussions, and greatly appreciated :)<div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 15, 2017 at 11:56 AM, Neil Dunbar via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ryan,<br>
<br>
I’ll take a stab at at least some of the rationale. Obviously, others will have different observations and priorities - so don’t take this as anything other than my musings on the NetSec discussions. The dominant notion was that the document which was the source of NetSec was an old one (from Symantec, I think?), and that the movement in technology meant that some of its stipulations had somewhat been obsoleted.<br>
<br>
1a - logical versus physical separation: I think that the view here was that VLAN tagging be orchestrated and enforced from dedicated managed network equipment (which must be accounted for, audited, configuration reviewed, change logged just as before), and not from a host based network stack, since that would necessitate the host being able to span the VLANs - in other words the host performing Certificate System work would - at least logically - exist in a bridging state, which violates the principle of isolation. Why is it being proposed? I suspect because the maturity of software defined networking (whether enforced via VLAN, IPSec, etc) has now reached the point where its isolation properties are deemed sufficiently trustworthy for CA work. However, I can see that others may have a markedly different view of this level of trust.<br></blockquote><div><br></div><div>I agree with this analysis, and my concern is wanting to make sure we've at least got the "please dear $DEITY don't do something stupid here" captured as well, with the "something stupid" being what you mentioned - a host that is bridged.</div><div><br></div><div>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".</div><div><br></div><div>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).</div><div>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)</div><div>For example: Is a switch handling VLAN tagging sufficiently segmenting? (Maybe, maybe not - popping the switch would be sufficient to gain lateral movement)</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
1b - “equivalent" versus “same”. Some deployments have different vendors (or different versions of equipment from the same vendor) which have different expressions of isolation enforcement (e.g. different routers having equivalent, but non-identical configuration data to enforce separation); the technical security properties desired remain the same, but the means of achieving them may differ. If I recall correctly (and I almost certainly don’t, or at least incompletely) the intention is to try and give some flexibility to CAs to have heterogeneous equipment setups within their environments, while retaining the requirement to establish to an auditor that the isolation properties are of equal value to a homogeneous environment. I’ll readily confess that my memory is less that solid on this point - so other NetSec people, please correct my errors.<br></blockquote><div><br></div><div>I see, and I understand that goal (and the challenge it can no doubt present). I'm curious whether this is something we can/should codify as a documentation exercise to be included as part of the (public) documentation. That is, my concern always exist with any form of closed-system evaluation of equivalence, since so far, every time we've allowed that, we (the broader PKI community) have allowed risk to be introduced, and no way to discover it until after the fact.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2m - Multi-party authentication. We had a long discussion on what constituted a “System” as far as issuing certificates was concerned (specifically around Root CA equipment, which is often offline and/or air gapped) - did it include the HSM as well as the computers which interface to it? Assuming that the HSM and computer falls within the boundary of the “System”, the question then arose about multi-factor authentication being difficult in such isolated environments, since often things like OTP/U2F involves synchronising with other online equipment, and some CAs might be very loath to expose their air gapped kit - even for a short while. Thus the suggestion arose that if the multi-party authentication to the HSM could be counted (e.g. by using USB keys, or some other means), then it wouldn’t really matter if the authentication to the computer used to talk to the HSM was single-factor. Now, since all HSM equipment is mandated to be FIPS-140 L3 or higher, a simple password level compromise would not be effective - the attacker would need to compromise the trusted inputs to the HSM too. Or so some of my thinking went.<br></blockquote><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2o - Removal of requirement to have remote access from a “pre-approved IP address”. Giving CAs the flexibility to perform trusted operations from systems in their direct control using MFA, but which may not have a persistent IP address. The idea being that the security is vested in the control of the device, network and authentication method, and no longer a specific external IP address. Given the prevalence of NAT within isolated networks, it could be argued that a pre-approved IP address yields no tangible benefit (IPv6 networks notwithstanding).<br></blockquote><div><br></div><div>Yup. This is something we (Google) raised as a concern in the very beginning discussions of the NetSec document, while Google was hosting, in part because it did not align with our own analysis of threat models or our expertise :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
4a - Intrusion Detection. This was to replace the overly prescriptive suggestions of anti-virus software with the notion of “something which detect unauthorised changes to the system”, which is I suspect what the anti-virus statement was intended to achieve all along.<br></blockquote><div><br></div><div>Yeah, this was another area of concern raised, so I think it's great to see progress being made here.</div></div></div></div>