[cabf_netsec] Minutes for the NetSec meeting on 2020-09-17

[Neil Dunbar]

All,

A little bit later than I said it would happen (turns out that my
getting married stole a lot of my time!), but the minutes of the last
meeting are attached. Please review and suggest any changes to me and
I'll make them happen.

Thanks,

Neil

-------------- next part --------------
NetSec Meeting Minutes
2020-09-17

Attendees

Neil Dunbar (TrustCor) [Chair]
Corey Rasmussen (OATI)
Dustin Hollenback (Microsoft)
Tim Crawford (BDO)
Bruce Morton (Entrust Datacard)
Ben Wilson (Mozilla)
Tobias Josefowitz (Opera)
Janet Hines (SecureTrust)
Trevoli Ponds-White (Amazon)
Clint Wilson (Apple)
Aaron Poulsen (Digicert)
David Kluge (Google)
Daniela Hood (GoDaddy)
Joanna Fox (GoDaddy)
Aaron Poulsen (DigiCert)

Apologies

Mariusz Kondratowicz (Opera)

1. Review Agenda

The agenda was agreed, although Mariusz had sent apologies that he would be unable 
to attend and present the Threat Modelling Update.

2. Agree Minutes

Because the previous minutes were submitted late, it was agreed to request approval for both 
the 2020-09-03 and 2020-09-17 meetings at the next meeting.

3. Pain Points Subgroup Update

There was no update from Pain Points as the previous meeting did not happen, it
being on a public holiday in Switzerland.

4. Threat Modelling Subgroup

Mariusz was unable to present the update, so such people who attended the meeting
presented their views of the proceedings.

Ben had requested a meeting of those network security people who could reasonably
opine on the zones ballot terminology and security principles to attend from the
membership. While several did, as is normal in such occasions, they remained largely
quiet - not knowing the precise dynamics of the meeting, and that they would hopefully
present their views in the future.

Clint stated that a number of Apple network security professionals attended the
meeting, but as Ben stated, held their peace during the meeting, owing to unfamiliarity
with the history of the topic under discussion and a desire not to disrupt the
conversation which was ongoing. However, after the discussion, the Apple personnel
suggested a reordering of the principles in the discussion document as well
as a clarification of the language.

Ben suggested that the repetition of the text in the latest version could be collapsed
into a principal colon clause followed by four subclauses, the colon clause then being
applied to all of them. Clint replied that was possible, and that he considered the
ordering of clauses not to be vital.

Ben noted that clauses (c) and (d) had different prepositions "with and access to" from (a)
and (b) "with [and within]".

Trev asked if the collapsing gave any particular gain, saying that previous collapses
make text more difficult to iterate. Clint agreed that those coming to the text
without historical context might find it easier to scan. Ben thought that we gain
clarity since there is common phrasing up to the work "with" in each of the clauses,
although he noted that the subsequent prepositions make it more awkward to combine
while preserving their individual semantics.

Ben suggested that the text could remove "Protect the security of Certificate Systems" and replace
with "Protect the Certificate Systems by: ...". He thought there was some way to
make a concise structure. Trev preferred complete sentences.

Neil asked the meaning of "requiring communication with and within such systems
to be authenticated". He asked specifically if we mean that the sender and recipient
of all subsystems performing communication (even inside a single host) be identified,
even implicitly; or did this mean that even communications over localhost (127.0.0.1)
needed to have some explicit network authentication scheme.

Ben agreed that the latter case was quite an onerous requirement. Neil said that
it wasn't inherently a stupid idea - communications could be done via Unix domain
sockets (for example) which had particular permissions set such that only
well known system identities could communicate over those domain sockets. He thought
that the text of "within" needed some clarity.

Trev and Clint agreed that there could be some clarification for that section.

5. Document Structuring Subgroup Update

There was no update for Document Structuring, the Zones ballot taking up most
of this text.

6. Account Management Ballot

Neil asked Tobi if there was a new redline for the ballot. Tobi said that there
was a new PR generated for the latest text.

Tobi explained that the old order of the text did not lend itself to make it
obvious that two things are in play: managing access to accounts and access
permissions; and then to verify that such access is indeed managed correctly.

Neil asked if the sections which had been moved (leaving blank sections) would
be closed up. Tobi replied that there would be references in the text which
would then refer to inapplicable sections. He also pointed out that many CAs
documentation might have references to the older sections; thus requiring
a lot of rewriting in those CA's internal documentation.

Neil also asked if the six month review window could be adjusted downwards
to three months. Tobi said that it could be two weeks; Neil thought that would
be a burden.

Trev said that something like a two week review would devalue any review process.
The only situation which would need such a review would be a highly unstable
work environment. She want on to explain that the context in which configuration
review happens is all important. David agreed, saying that the shortening of
the window of review reduces the chances that a reviewer will pick up on a
change to an account list which is unlikely to change frequently.

Neil recapped that the review was not to say "Did the configuration Management
system take out Joe's account after his leaving", but rather "Is the
configuration management correctly set up to take out any and all accounts
which are marked as no longer needed?"

Trev said that description was more an architectural analysis; rather than
something which should be regarded more like a penetration test or security
review.

Neil said that he still needed to examine the ballot further. While the reordering
helps, he was unsure if it addresses the comments made. David agreed that it
was unclear what the comments actually mean.

David broadened the discussion, saying that many critics have an implied assumption
of a set of rules in force which are not actually there in the text, and that
each CA has an army of security engineers looking at all configurations day and
night to establish their correct function. Thus any attempt to move to automation
risks losing this imaginary force acting to prevent misbehaviour. David said that
any large computing environment cannot be monitored by a large contingent of spot
checks; it needs to be a correctly configured monitoring system.

Neil said that he would start a discussion on SCWG asking for a clearer enunciation
of this issues.

7. Discussion on Pan Working Group NetSec

Neil summarised the brief discussion that happened on the SCWG. The question was
raised as to how the NetSec committee could make its work more available to
other working groups. Neil mentioned that Bruce had said that the Code Signing
working group already made direct reference to the NCSSRs.

Neil continued saying that Tim Hollebeek had observed that if a party wishing
to influence the NCSSRs who was not a member of the SCWG, then they would need
to join the SCWG as an interested party; but this then can cause IP related issues
which might stop this. Ryan Sleevi had then said the problem is that much of
what is in the NCSSRs are server certificate targetted - the example of the SC28
limitation of logging requirements differ (ie, server certificate data can disappear
for two years, but a timestamping authority log needs to stay around for longer)
Neil said that he didn't find that argument compelling, but it wasn't the
right forum to engage without discussing with NetSec first.

Bruce agreed that he didn't want to push back either in that forum. In his view
if there was a specific requirement for a type of certificate, it belongs in the
requirements documents for that working group; meaning that NetSec would be only
the common factors in security for any sort of certificate issuance process.

Neil replied that in his understanding, SC28 was not to talk about server certificates
per se, it was to say that the metadata surrounding any loggable activity should be
stored for two years past the end of the lifecycle of the entity being logged.

Ben thought that the logging discussion wasn't particularly germane to the
overall thrust of the audience for the NCSSRs. However, he did think that
adding details like Trusted Roles into the BRs, thus freeing up the NCSSRs to
be more applicable, would be a better approach.

Neil replied that the idea of making NetSec a working group was a long term goal
if it's even a likely contingency. Ben said that it could take many years and
that members of other groups could refer to their own BRs or the NCSSRs as they
see fit, for the near future.

Tim (Crawford) said that WebTrust is designed to be applied across many different
environments, so it would be unlikely to apply the NCSSRs outside of the
background against which they were written.

Bruce asked if the NCSSRs could be closed out as a static document after a couple
of years. After understanding Bruce's point, Ben agreed.

Neil suggested that the NCSSRs could stop being updated when they stop prescribing
particular behaviours and describe the processes which need to be in place in order
to underpin secure operations. The entire point of the NetSec group was to ensure
that the document can be applied to the computing environments that exist today
(virtualized, cloud, containerized) versus the older model of on-premises physical
boxes performing all the work. He didn't know if there was a particular end date, but
there was an end goal.

8. Any Other Business

Ben said that he would try to finalise the Offline CAs ballot - he asked for endorsers.
David was listed, and he wasn't sure who the others were. Thus he suggested re-circulating
the text and picking up another endorser.

9. Adjourn

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