[Servercert-wg] Ballot SC40: Security Requirements for Air-Gapped CA Systems

[Ryan Sleevi]

I'll readily admit that we're not entirely sure that 5l and 5m are good
approaches.

That is, there is a world in which they absolutely make sense, and having
5a do the same might make sense, but it's not clear that's a world we're in.

One of the recurring issues with the NetSec subcommittee that we've tried
to grapple with, on our side, is a confidence in logical security controls
that can easily fall over (e.g. VLAN tagging by trusting the client to be
honest, firewalls [like DigiNotar had] to limit ingress and egress
traffic). The change in 1.c is one of those that while I think it's meant
well, but perhaps highlights this disconnect. It moves from "physically
separated (High Security Zone) and (in an offline state air-or gapped from
all other networks)" to "kept offline or otherwise air-gapped and separated
from other systems", which can either parse as "(kept offline) or
(otherwise air-gapped and separated from other systems)" or "(kept offline
or otherwise air-gapped) and (separated from other systems)".

This is particularly important when thinking of the logical security
controls: because I can easily see a CA interpreting the changes in 1.c as
meaning they can put their Root CAs on the same internal network, as long
as they keep them offline "most of the time". There's no functional
requirement for separation, and it seems for at least some members of
NetSec, that's a feature, not a bug (I think we'd disagree).

As a consequence of this, wording like in 5.l/5.m would be itself a huge
security regression, because it would mean periodically connecting to a
(potentially) hostile network, yet only having to review when the
organization determines they've "used" a CA (e.g. issued something), versus
when they brought it online. Even a review of configuration may be too late
for a DigiNotar-style compromise.

As I said, I think this is mostly meant well, but I think we need to
"literal genie"-proof the overall thing a bit more. Assuming there was more
robustness in place, I agree that something like 5.l/5.m might make sense
for 5.a.

Yet, even then, the downside is one we've seen play out in countless CA
incidents: "Due to human error, we failed to review the configuration for
all changes made to the BRs since we last reviewed the configuration, and
thus we misissued. Oops". The annual cadence, at least there, helps CAs
create a bit more definition about the changes that need to be considered
(exactly one years changes), rather than have it be variable based on usage
(and possibly exceeding several years of changes).

On Wed, Feb 3, 2021 at 7:31 PM Aaron Gable <aaron at letsencrypt.org> wrote:

> Indeed! But to achieve that end, it could be phrased in the same manner as
> 5l and 5m: requiring that configuration be reviewed when (or more strictly,
> immediately prior to when) the air-gapped system is used, or on a yearly
> basis, whichever is less frequent.
>
> On Wed, Feb 3, 2021 at 12:51 PM Ryan Sleevi <sleevi at google.com> wrote:
>
>>
>>
>> On Wed, Feb 3, 2021 at 3:46 PM Aaron Gable via Servercert-wg <
>> servercert-wg at cabforum.org> wrote:
>>
>>> Thanks! Just one questions on specifics:
>>>
>>> > 5a. Review configurations of Air-Gapped CA Systems at least on an
>>> annual basis;
>>>
>>> Regular review of configuration of air-gapped systems seems good, but
>>> this sounds like it requires CAs to retrieve and turn on air-gapped systems
>>> which would otherwise be able to remain untouched. Is there another form of
>>> configuration review which does not require access to the system itself
>>> that is intended here?
>>>
>>
>> How would you know they had indeed actually otherwise remained untouched?
>> :)
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20210203/fc87346a/attachment.html>