[cabf_netsec] Minutes of meeting on 2020-10-01

[Neil Dunbar]

All,

Enclosed are the minutes of the meeting on 1st October. As always - let
me know of mistakes or omissions and I'll get them sorted.

Thanks,

Neil

-------------- next part --------------
NetSec Meeting Minutes
2020-10-01

Attendees

Neil Dunbar (TrustCor) [Chair]
Clint Wilson (Apple)
Corey Rasmussen (OATI)
David Kluge (Google)
Mariusz Kondratowicz (Opera)
Bruce Morton (Entrust Datacard)
Tobias Josefowitz (Opera)
Aaron Poulsen (Digicert)
Dustin Hollenback (Microsoft)
Trevoli Ponds-White (Amazon)
Tim Crawford (BDO)
Ben Wilson (Mozilla)
Wendy Brown (FPKI)

1. Review Agenda

The agenda was reviewed and approved without change.

2. Agree Minutes (2 sets)

Both previous sets of minutes were approved.

3. Pain Points Subgroup Update

David recapped the last meeting where they discussed the desires of Neil and Ben
to reach out to those who had provided feedback on SC34 to gain a better understanding
of the nature of possible objections.

The latter part of the meeting was focussed on the Cloud CA discussion document,
which led to a technical discussion on the possible directions to be followed.

One area was to clarify the scope of the overall effort - in other words to target
whether (for example) a cloud RA system could be fielded, or whether the backend
CA systems could be hosted in cloud environments. Another discussion point was in
differentiating the operating models in which a CA could run cloud based services
in their hosting. This leads into what levels of assurance a CA could obtain in
such deployments, whether additional audits would be required and what forms of
logging would be needed to maintain such assurance.

Trev had shared a useful link on the Microsoft Shared Responsibility Model, but
while it was noted, there was not the time to discuss it much further. Other
points which had been noted in the minutes which need exploration are what aspects
of a Cloud environment can better be done than traditional on-premises deployments
(e.g. Monitoring, Availability, large repeatable deployments, security event
triggering.) 

4. Threat Modelling Subgroup

Mariusz commented that since the NetSec recap in SCWG covered most of the material which
was discussed at the last meeting, there was little to add.

Mariusz said that he had been considering reviewing the approach of Threat
Modelling to focus on more immediate needs of the NetSec team, and would be
discussing with the Subgroup how best to focus those activities towards particular
modelling of threats covered by current and upcoming ballots.

5. Document Structuring SG Update

Ben didn't have much to add, except wishing to address Ryan's comments in SCWG and
other fora.

6. Suggestions for F2F 51

Neil recapped the discussion from SCWG, with Ryan (Sleevi) having expressed concern
about the direction of NetSec and specifically more recent ballots; and that Ryan
asked for a statement at F2F 51 regarding which areas NetSec sees as being the ones
to address. Ryan had specifically highlighted the Zones discussion and the shift
from physical isolation to logical isolation properties; as well as the proposal to
examine the issues in running CA services in Cloud environments.

Ben said that he was going to send an email to Ryan and Wayne regarding SC34 to get
a better feel for where their concerns lie.

Neil suggested that NetSec was trying to derive better guidelines for operating the
computing machinery of today, versus some of the implicit properties in the traditional
physical hosts in a dedicated data centre which applied to many environments in the
past.

Clint replied, saying that the cocern was less about updating the rules to fit a newer
world, rather than the fact that new concepts of operation introduce new complexities
(which in turn can lead to new vulnerabilities) and that perhaps we [NetSec] need to do
more groundwork in making clear that we have examined these new complexities and their
interaction with the threat landscape. Clint gave the example of having logical separation
as an isolation property, which then introduces new systems to manage those logically
separated units. Thus, he surmised, we need to put time and focus into new dependencies
which are introduce.

Neil asked, as an example, were we to introduce a control of encrypted communications
between logically separated units, which takes the place of physically separating those
units as might have been done in the past; does this then require better explanation of
how key management, rotation, encryption strength etc. is managed, in order to be able
to state that the communication separation in a logical sense has equivalent strength
to physical separation. Clint thought this was a reasonable example to bring up.

Clint continued, saying that if we fail to introduce adequate explanation of the
dependencies and additional controls which obtain (in a logically separated structure)
then a poorly acting CA could use that vagueness to operate their CA system in a
way that is actively harmful to the WebPKI, by weakening their security.

Tobi added that the nature of logical separation comes into scope; since we
need to know that the mechanisms used to define and enforce logical separation of
infrastructure actually do a good job of ensuring that the separation is efficient.
Mere terms like "state of the art" won't really fly.

Trev agreed that the scoping issue was the crux; the goal is not to say "we wish CAs 
to deploy into the cloud", rather it is to say that we are trying to ensure that
the NCSSRs and BRs don't inhibit CAs making use new technology which improves their
logical security. The example she gave would be for a CA to be able to say "I wish
to make use of this service which the provider can dedicate a large number of support
engineers to monitor and administer, which I [the CA] could not afford to do so from
existing resources".

Neil suggested that there were two strands; one was to perform the thought experiment
which said that, since other sectors could use cloud resources for secure, regulated
businesses, what is it that stops CAs doing so? The other strand was the recognition
that the old model of all information security segregation coming from physically 
separate hosts communicating on Ethernet is not aligned with modern computing
deployments.

Neil added that some of the concerns expressed by Ryan came from the discussion of
ballot SC29, when there was concern regarding CAs having the ability to fetch their
OS patches directly from OS vendors without a CA decision being made over what the
patch was, what it fixed and whether it should be deployed, in favour of a blanket
trust from an internet hosted OS vendor repository. Neil suggested that SC29 did not
actually touch this aspect; but this gave rise to the perception of NetSec wishing
to allow CAs to hook all their systems to the public internet - a view which Neil
thought was not accurate.

Neil added that we do need to set down in a document our guiding directions, adding
in that any new dependencies must be adequately explored in discussion documents
prior to ballots being put forward.

Wendy said that the concerns regarding cloud deployments are probably massively
dependent on the ownership of management of the cloud environment. Outsourcing of 
cloud service management imposes a duty to explain exactly how the risks are managed
in a way that does not weaken from a wholly owned and operated cloud.

Trev agreed, but added that "outsourcing" is perhaps not quite the right term, since
outsourcing does not absolve the responsibility of the outsourcer to check that
the work is done, as well as how it is done. She suggested some examples might help;
since the perception is one of "all or nothing" for a cloud deployment. Trev
provided the example of secondary log retention. The CA owns the responsibility of
owning the data, securing the data, picking the regions for storage and so on.

Neil gave the example of a technology which TrustCor operates within their dedicated
hardware, but would like to operate using cloud infrastructure; multi-aspect DNS lookups
are undoubtedly how domain control can be validated - the more aspects, the harder it
is to fool. But so far, TrustCor has held off deploying this technology to a cloud
environment, since it is not clear that the BRs and NCSSRs would permit such a deployment
absent a lot of supporting evidence regarding how those cloud environments are
assessed and audited.

Clint asked if this would form part of the F2F presentation. Neil said that they would
indeed be part of the presentation.

Tobi suggested that this should be part of the discussion of NCSSR inadequacy, regardless
of cloud deployment.

Trev said that the NCSRRs were not bad as such, more that, structurally, they
don't support the concept of microservices, which is a fundamental deployment.
Tobi said that the NCSSRs just don't help to make a deployment one way or the other;
they don't describe processes, and so often a CA wants to make a deployment but is
unsure whether the NCSSRs allow it or not.

Neil said that from a F2F perspective, perhaps it would be a good idea to draw out the
dichotomy of the NCSSRs allowing too much which we think is undesirable, and the NCSSRs
prohibiting too much that is not actually a bad idea. Tobi thought this was reasonable
and added that sometimes people seem to think that the NCSSRs provide more than they
actually do, which leads to pushback on new ballots thinking that by definition the NCSSRs
must be being weakened.

David agreed with that last point; that too often the response is that the status quo
is the optimum position (which it isn't). While new dependency consideration is good, merely
saying that the system is being weakened doesn't give us enough to address concerns.

Neil said that, in his opinion, some of the concerns are that when we introduce a
possible change, we (NetSec) should be reading that change from a pathological perspective,
in terms of "If I were a badly behaving CA, what does this allow me to get away with?"
However, we in NetSec do not see it that way, which means that we need a better conversation.

Neil suggested that the next step was to sketch up a F2F presentation for the Google
Drive and get feedback from the team as a whole as to whether we addressing the relevant
concerns.

Dustin asked if we could come up with a problem statement now as a starting point for the
presentation. The themes he heard were "Clarifying the NCSSRs", another was "Being 
Technology Neutral". Neil added "Recognizing New Complexities in New Technology".

Mariusz asked if we would want to focus on "known good practice" versus "cutting off the
possibilities of bad CAs abusing the NCSRRs"; he suggested that discussing this on the
wider forum - which approach would align with the forum as a whole? Neil said that he
would take it under consideration.

7. Any Other Business

There was no other business discussed.

8. Adjourn

The meeting was adjourned and will reconvene on 2020-10-15