[Servercert-wg] VLANs

[Ryan Sleevi]

(Removing the netsec list due to posting)

On Thu, Oct 17, 2019 at 11:31 AM Ben Wilson via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> Apologies in advance for cross-posting
>
>
>
> We can make sections 1.d. and 1.e. of the Network and Certificate Systems
> Security Requirements a lot more clear if we can replace “Secure Zones”
> with two separate definitions – one for the logical zone / network (topic
> of this email) and another for the physical location of equipment. (Current
> definition is “Secure Zone:  An area (physical or logical) protected by
> physical and logical controls that appropriately protect the
> confidentiality, integrity, and availability of Certificate Systems.”)
>
>
>
> As mentioned on today’s Server Certificate group call, I’d like for the
> Network Security subgroup to consider incorporating the concept of VLANs
> (or, if not, a high-level reference to other current concepts of segmenting
> logical network space) into a new definition of logical zones.  See -
> https://en.wikipedia.org/wiki/Virtual_LAN .
>

Consistent with the remarks on today's call,  and with the previous mail (
https://cabforum.org/pipermail/servercert-wg/2019-October/001147.html ),
it'd be useful to capture a bit of the problem, or describe a bit about
what you think the "good solution" is that might be inadvertently
prohibited.

For example, under today's NCSSR, 1.c requires that Root CAs be in a High
Security Zone, offline or airgapped from all other networks. It's unclear
if that's a "problem" or something intended to keep.

If it's something you want to get rid of, that creates risk, because if you
have your High Security Zone and your Secure Zone, separated by VLANs but
not physically, then you've got the ability to pivot from the Secure Zone
to the network equipment that manages the VLAN tagging and routing, and
from there, into the High Security Zone.

This is to emphasize that there is a lot of risk with segmenting logical
network space and relying on, say, the tagging of packets. You can think of
all of our requirements having a floor (e.g. anything below this level is
forbidden) and a ceiling (e.g. better things cannot be done because of this
limit). To put random numbers (since I can't draw a picture), it might be
that a given requirement has a floor of 4 and a ceiling of 6. We might say
that 3 would be fine, or we might really want to do 8, and the current
requirement doesn't allow it, so instead, a new requirement is proposed:
one that has a floor of 2 and a ceiling of 10.

If you're a CA wanting to do the right thing, you might say "Look at how
this new requirement lets me do 7, 8, 9, or 10!"
However, from a browser wanting to manage risk, what I see is "look at how
this allows 2 and 3" and wonder if that's a good.
It's also a risk that someone might /think/ they're implementing a 7, but
they're implementing a 2 - and that's what some of the discussion around
intent/goals is trying to flush out.

Hopefully that makes sense and captures the concern. Knowing that you're
trying to do 7, and running into that ceiling, super-helps - it shows how 6
is the ceiling, and it allows evaluation to make sure it's not 2, and it
allows discussion about how maybe 3 is fine, but that's where the floor
should be - not 2, not 0.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191017/88ef6ddd/attachment.html>