<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<pre>All,</pre>
<pre>I've drafted minutes for the meeting on the 6th August and from today's meeting.
The 6th August one was compiled on the 7th August, but my swiss cheese brain forgot to actually send it to the list :-(.</pre>
<pre>Anyway, as always, comments/adjustments gratefully received.
Thanks,
Neil
</pre>
<pre>===============2020-06-08=========================
Minutes of NetSec Meeting : 2020-08-06
Present:
Neil Dunbar (TrustCor) [Chair]
Corey Rasmussen (OATI)
Tim Crawford (BDO)
Daniela Hood (GoDaddy)
Clint Wilson (Apple)
Ben Wilson (Mozilla)
Trevoli Ponds-White (Amazon)
David Kluge (Google)
Dustin Hollenback (Microsoft)
Tobias Josefitz (Opera)
Janet Hines (SecureTrust)
Tomofumi Okubo (DigiCert)
Aaron Poulsen (DigiCert)
Apologies:
Mariusz Kondratowicz (Opera)
1. Review Agenda
The agenda was approved, although since Mariusz was absent, the Threat Modelling section was donated to Pain Points.
2. Agree Minutes
The previous minutes were agreed.
3. Pain Points Subgroup Update
David reported that the team had worked through their ballot backlog, with the authentication
controls ballot being the only one requiring further work.
The question which followed was "what next?", to see what areas required further attention.
One item was an attempt to clarify the NSRs regarding critical vulnerabilities, following
from a request from Entrust Datacard at the beginning of thePain Points team establishment.
While a draft ballot was prepared, but not shared, the team were wondering if there was
still interest in pursuing this area, or whether the team should move on.
The next item considered was the definition of "firewall events". While ballot SC28 alleviates
some of the definition challenges, the team wondered if it was possible to go a little further.
The consensus was that it is very difficult to define what a "security firewall event" was or
what their practical relevance was. The team further considered that it might be possible to
take other approaches to firewall event logging, rather than looking for a priori "security events",
to take a shorter window approach of logging everything, then overwriting after a time.
[ND - presumably using the information written to detect anomalies in network behaviour?]
After considering those tactical points, the team considered medium to long term strategies.
One focus might be to look towards access management in detail, specifically how the principle
of least privilege could be codified, as well as segregation of duties.
The team then looked at the longer term vision of how a CA system should look in a few
years time - specifically what a "Cloud CA" might look like and how that would integrate
with the NSRs. Today, they would not, but there might be work to do in order to make such
technology meet up with the requirements of the NSRs in the future.
Neil commented that a lot of CAs use cloud providers at the moment, but maintain them at
arms length, since a generic CA could not inspect a cloud provider's data centre and processes
in order to pass the basic audit requirements.
David agreed that many CAs use cloud services, like logging, databases and so on. The
consideration was whether CAs could use container environments, and Cloud HSMs. For the
moment, it's unthinkable - but in a few years time it might work.
Neil said that it was a fascinating area to explore, but that the individual meetings were
too infrequent to consider this, and perhaps a separate working document would be a good base
point, asking the questions of "what stops us doing Cloud CA today" and then "what would
be needed to make it happen".
David said that he was happy for that approach to be taken.
Neil said that it seemed like a long term project, which might not be a Pain Point.
David agreed that it was more of a general CA architecture discussion than a true
Pain Point.
4. Threat Modelling Subgroup Update
This agenda item was skipped.
5. Document Structuring Subgroup Update
Ben reported that there wasn't a lot of progress made so far.
The Offline CA document is still in preparation - a comment had been received in June
which needs to be addressed. David had asked for a little more time on to check some
points before endorsing the ballot, but that he was now satisfied that it is ready to
proceed.
One comment that had been received was that in 1(c), we had proposed no modifications to
the requirement that the CA maintain the CA equipment in High Security Zones in an offline
and airgapped state.
Ben wondered if we should make the change to assert that the requirement should be made
to match in accordance with Section 5 (being the new Offline CA section)
Neil asked whether we were using the term "offline" to be interchangeable with "airgapped",
or did we mean it as being "normally powered down".
Ben replied that it was indeed meant to mean "airgapped". Trev asked Neil if it might be
better to use the term "airgapped" instead of "offline". Neil replied that he was simply
asserting that there is confusion around that term, but that if the definition in the document
is clear, he had no problem with its use.
Trev advocated that we use airgapped, because it's clear what it means.
Ben then asked to what degree we eliminate "offline" in the document, or do we use the defined
term Offline to indicate airgapped.
Neil pointed out that in 1(c), offline is specified as an alternative to airgapped, albeit
that its not using a defined term. Ben said that we could amend 1(c) to say that "Root CAs
shall be maintained as an Offline CA System in accordance with Section 5".
Neil thought that currently 1(c) says that you could have Root CAs on a network but
in a normally powered down state (as opposed to airgapped); he would be fine with a
requirement to have Root CAs specified to be airgapped only.
Trev said that offline equipment still comes with a need to periodically validate it,
since it would not be amenable to continuous monitoring.
Ben then asked if we should simply replace offline with airgapped.
Tomofumi replied that offline was a term for the CA industry, whereas airgapped is a
networking term. He thought we should keep "offline" but be clear that it encompasses
a definition of "airgapped".
Tim said that the more he thought about it, the less useful the term "offline" becomes,
since to bring it online, you need to airgap it.
Tomofumi suggested that "online" doesn't mean it's "on" - it means it's connected to the
Internet, which is undesirable.
Neil replied that "offline", to him, meant that there is no possible path to the
equipment to a hostile network, and that offline meant that no connection to any other
network other than its own local area is possible (whether via Bluetooth or some
other method).
Neil asked, for the purposes of understanding, given that Root CAs need to be in a
offline state, was there any other CA system which would live in an offline, airgapped
state.
Ben replied that a CA using pathLen 1 could be an example of that.
Trev asked if Neil was asking whether he was suggesting that we just use "Root CA System"
rather than "Offline CA". Neil indicated that he was, but Ben replied that there are
other CA systems which could live in that offline state. Trev then said we would be
defining a Root CA by what its security controls were, rather than its function.
Tomofumi said that it wasn't just root CA operations - generation of keys for intermediate
CAs happens there, as well as signing their certificates.
Neil asked if this were true - is there something which prohibits key generation for
intermediate CAs on an online system?
Ben then said that he was happy to change 1(c) as above, and then seek two endorsers.
We held a straw poll to determine whether we should keep the term offline or use
airgapped. The end result was a narrow majority in favour of "airgapped".
There has been a little progress made on the eliminations of the Zone terminology.
David also mentioned that was a provision on the logical security aspect which required
further discussion.
Ben replied that indeed, there had been a pivot towards a more logical security outlook
with respect to the Zones ballot.
Neil mentioned that, in respect of communications with Dimitris, what should be done
with the pace of ballots, and that Dimitris had indicated that we might like to propose
pre-ballots to the SCWG for discussion before they become formal ballots, to gain more
insight on issues arising from proposed changes.
The other proposal was to keep it in circulation in NetSec for longer, but that he
(Neil) was not a fan, since it meant circling the drain a lot more, covering no new
ground. Neil asked Ben what he wanted to do with the Offline CA ballot.
Ben replied that he would consult the SCWG with the document as a pre-ballot.
6. Account Management Ballot
Neil asked Tobi if the Account Management ballot was ready to go. Tobi thought that it
was, although he noted Dimitris request. Neil said that ultimately, it was Tobi's ballot
and he would support putting it forward. Neil thought that it was pretty small and self
contained; although Tobi thought that it could be interpreted as being further reaching
than it was.
Neil said that the ballot didn't really impose new duties, other than to say that if a CA
is performing continuous monitoring, that monitoring was required to cover account provision
and decommisioning. Tobi said that while we in NetSec might know that, the document could
do with a bit more explanation to cover misapprehension as to the duties imposed by the
ballot.
Neil asked Tobi if he could grab a ballot number from the wiki, since he had two
endorsers. Tobi edited the wiki page and associated the ballot with SC34.
7. Authentication (Lockout) Ballot
Neil asked David if we still needed a redline for that ballot. David agreed, but
also needed endorsers. Neil said that he was still happy to endorse.
Neil asked whether David could propose the ballot, if not the voting member for Google.
After a short discussion regarding the term Voting Member, David said that it was fine,
he could propose, but Ryan S would vote for Chrome.
8. Offline CA Ballot
There was no need for further discussion.
9. Other Ballots
There was no other ballots to discuss.
10. Any Other Business
There was no other business.
11. Adjourn
The meeting was adjourned and will recommence on 2020-08-20.
</pre>
<pre style="margin: 0in; font-size: 11pt;">===============2020-06-20=========================
Minutes of NetSec Meeting: 2020-08-20</pre>
<br>
<pre style="margin: 0in; font-size: 11pt;">Participants:</pre>
<br>
<blockquote>
<pre style="margin: 0in; font-size: 11pt;">Neil Dunbar (TrustCor) [Chair]</pre>
<pre>Ben Wilson (Mozilla)</pre>
<pre>Bruce Morton (Entrust Datacard)</pre>
<pre>Dustin Hollenback (Microsoft)</pre>
<pre style="margin: 0in; font-size: 11pt;">Tim Crawford (BDO)</pre>
<pre>Trevoli Ponds-White (Amazon)</pre>
<pre style="margin: 0in; font-size: 11pt;">Tobias Josefowitz (Opera)</pre>
<pre>Aaron Poulsen (DigiCert)</pre>
<pre>David Kluge (Google)
</pre>
</blockquote>
<pre>Apologies:
</pre>
<blockquote>
<pre style="margin: 0in; font-size: 11pt;">Mariusz Kondratowicz (Opera)</pre>
</blockquote>
<pre><span style="font-weight: normal; font-style: normal; font-size: 11pt;">1. Review Agenda</span>
</pre>
<pre style="margin: 0in; font-size: 11pt;">The agenda was agreed.
</pre>
<pre style="margin: 0in; font-size: 11pt;"><span style="font-weight: normal; font-style: normal; font-size: 11pt;">2. Agree Minutes</span>
</pre>
<pre style="margin: 0in; font-size: 11pt;">Neil explained that owing to an oversight, the last minutes were not sent
out (though they were prepared); they would be considered at the next meeting
along with the current minutes.
</pre>
<pre><span style="font-weight: normal; font-style: normal; font-size: 11pt;">3. Document Structuring</span>
</pre>
<pre style="margin: 0in; font-size: 11pt;">Ben reported that the Offline CA document ready for pre-ballot discussion on
the larger SCWG. He didn't have two endorsers, but both Trev and Neil commented
that because it's a pre-ballot discussion, that's not needed.</pre>
<pre><span style="font-weight: normal; font-style: normal; font-size: 11pt;">4. Pain Points </span>
</pre>
<pre>Ben and David confirmed that Threat Modelling team is being asked to consider
equivalent network controls to avoid relaxation of rules in logical zoning
versus physical zones, perhaps taking from the Cloud Security Alliance controls
as indicated by comments by David in the Zone Removal document.
</pre>
<pre>David reported on the last Pain Points meeting.
</pre>
<pre>There was some discussion on the phishing revocation talk on
mozilla.dev.security.policy, even if that wasn't strictly a pain point.
</pre>
<pre>David brought up the critical vulnerability discussion, which had begun
with Tim, as to when the 96 hour window for remediation should start, and
that the discussion had moved onto what the scope of the vulnerability
scanning should be. Specifically "private" vs "public" IP addresses; it
was considered that such a distinction might not be meaningful boundary
from a security scanning perspective.
</pre>
<pre style="margin: 0in; font-size: 11pt;">The Authentication Lockout ballot now has a redline, so discussion can
continue on this.</pre>
<pre><span style="font-weight: normal; font-style: normal; font-size: 11pt;">5. Account Management Ballot</span>
</pre>
<pre style="margin: 0in; font-size: 11pt;">Tobi confirmed that he is ready to go with ballot SC34, but that he was
double checking the GitHub rules so that the redline met all the guidelines
for the SCWG process. Once this is done, he will be submitting the ballot
for SCWG discussion.</pre>
<pre><span style="font-weight: normal; font-style: normal; font-size: 11pt;"></span><span style="font-weight: normal; font-style: normal; font-size: 11pt;">6. Authentication (Lockout) Ballot</span></pre>
<pre style="margin: 0in; font-size: 11pt;">This was covered in the Pain Points section.</pre>
<pre><span style="font-weight: normal; font-style: normal; font-size: 11pt;">7. Offline CA Ballot</span>
</pre>
<pre>On the process of the Offline CA ballot, Ben did express some confusion with regard to the
heartbeat rules, saying that it makes things easy to lose via the 21 day rule;
but the old 7 day rule was too short.
</pre>
<pre>Bruce said that pre-ballot discussion was the method used in the past to
avoid heartbeating, and the 7 day rule didn't impact as much because of the
fact that the discussion had already taken place.
</pre>
<pre>Trev indicated that she would want to see at most one heartbeat, then things
go into discussion.
</pre>
<pre style="margin: 0in; font-size: 11pt;">Neil said that on September 1, SC28 will go into a 7 day discussion phase
followed by a 7 day voting period. Trev commented that the Byelaws were
probably not meant to cope with pandemics.</pre>
<pre><span style="font-weight: normal; font-style: normal; font-size: 11pt;">8. Cloud CA Discussion</span>
</pre>
<pre>Neil put forward a draft discussion document on the integration of CAs with
Cloud Service providers. It is just a set of notes at this point, and needs
structure; it is not meant as a ballot source, since there will be many views
on even the desirability of running CA operations via cloud providers.
</pre>
<pre>The document is available on the Google Drive, and Neil asked for contributions
and edits to help shape the discussion, and that he would leave discussion
time open if the team decided it was worth taking this long term effort further.
</pre>
<pre><span style="font-weight: normal; font-style: normal; font-size: 11pt;">9. Any Other Business</span>
</pre>
<pre style="margin: 0in; font-size: 11pt;">There was no other business to discuss.</pre>
<pre>10. Adjourn
</pre>
<pre style="margin: 0in; font-size: 11pt;">The meeting was adjourned and will reconvene on 2020-09-03</pre>
</body>
</html>