[cabf_netsec] Minutes of Network Security Subcommittee Meeting 2021-03-16

[Neil Dunbar]

Colleagues,

I've attached the minutes taken from the 2021-03-16 meeting. If anyone 
spots anything incorrect or missing, please notify me and I'll adjust 
accordingly.

Thanks,

Neil

-------------- next part --------------
Network Security Subcommittee Meeting - 2021-03-16

Present
=======

Neil Dunbar (TrustCor) [Chair]
Ben Wilson (Mozilla)
Bruce Morton (Entrust)
Corey Rasmussen (Digicert)
David Kluge (Google)
Janet Hines (SecureTrust)
Trevoli Ponds-White (Amazon)
Aaron Poulsen (DigiCert)
Niko Carpenter (SecureTrust)

Apologies
=========

Clint Wilson (Apple)

1. Review Agenda

Because of mailing list server issues, the meeting was unable to review the agenda, and
proceeded upon the draft agenda Neil displayed on screen.

2. Minutes

Because the last meeting was at the face to face meeting, no minutes needed to be reviewed.

3. Cloud Services Subteam Update

David summarised the previous days meeting, stating that the team had concentrated
on load balancer (cloud) configurations, used to balance traffic to backends or to
make routing decisions or terminate TLS, or authenticate principals to services. This
work is being split up into a risk analysis for all four of these deployment domains.

David mentioned in the previous NetSec call that he wanted to make an outline of the
Cloud Security document available. He has not got to that yet, but is hopeful that we
can see the initial draft by next week, since the component analysis will take some
time. Aaron Poulsen had offered to draft an initial architecture; so that everyone can
share the same vision that the team are producing - as an illustrative diagram rather
than a normative document.

David hoped that the Cloud documents were presented at the F2F by Neil.

Neil replied that he did present David's slides - some were a little too detailed for
general consumption - those slides have been uploaded to the wiki. The only thing which
emerged was a request from Ryan, asking if there was an intention to keep the SCWG
abreast of what is going on with the Cloud Security document as it matures; but the
notion of having this document as a work product was generally welcomed.

Neil had indicated that the document would be socialized early and often, but with
the caveat that it is a draft document, and we (NetSec) reserve the right to tear
up sections and reconstruct them as we see fit. It is our general policy to socialize
document early on large matters, to avoid the spectre of dumping a large document as
a fait accompli which can then generate material objections later.

Neil reported that the component by component analysis was also well received. He
added that David was missed at the F2F.

David replied that he was happy to see the document presented early as it evolves.

4. SC40 Update

Ben stated that since the last update there had been feedback from various quarters.
In particular Wendy Brown (FPKI) had observed that the phrase "system separate from
all other CA systems" could introduce problems. Ben drew the idea of two HSMs - one 
Thales, one Luna with different operating parameters and client software. In an offline
environment one could have those plugged in (and on) at the same time [e.g. key
generation on one, but signing on another] - this could be prohibited by the current
language, but is not actually intended to be prohibited.

Ben continued, saying that we do wish things to be physically and logically secure,
but not overly prescriptive in the architecture. Ben was hopeful that we can tweak 
the language to address this issue.

Neil suggested that the dispute here was the boundary of the word "system". Jos
(Purvis) had raised the notion of having a computer with 2 VMs, one authorized to 
talk to HSM1, and VM2 authorized to talk to HSM2, does the powering of the hypervisor
mean that (VM1, HSM1) and (VM2, HSM2) is consider a single system, or can the powering
of the VM states be considered separable in terms of being "a system".

Ben replied that he did not have time to consider further language, but would do so
soon. He did not want the ballot to fail on the 21 day rule. Neil said that he would
want to claim a minimum of 4 days grace, since the mailing lists have been down.

Ben mentioned that even on the Infrastructure Slack, he hadn't seen anything since
Friday (March 12th). Neil mentioned that he had mailed Jos and he was looking into
it.

Neil agreed that this is a solvable issue in terms of the language.

Ben added that there was a suggestion that the requirements be separated from the
definition.

Neil said that was his suggestion, since definitions are supposed to be transposable
within the language itself.

5. Post SC38 Ballot Update

Clint had a meeting conflict which stopped him introducing the text of his proposed
ballots, so Neil summarised the content.

Ballot 1 will remove the requirement of Section 4.1.1 of the BRs for CAs to maintain
(but not actually consult) a database of "suspicious" certificate requests or
revoked certificates. The feeling is that (1) having a database which is not mandated
to be used is a pointless burden and (2) the framing of this "suspicious bit" database
is not actually particularly useful in identifying risks to the WebPKI. CAs already
have Subscriber Agreements which can be used to delimit unacceptable uses of certificates
and can block applicants based on agreement violations.

Ballot 2 will introduce the requirement for CAs to maintain a database of known compromised
keys _permanently_ (ie, for as long as the CA exists). Since there is no mechanism by
which a compromised key can become uncompromised, it stands to reason that if a CA is
aware of a compromised key, it should never issue a certificate bearing that key in the
future. Note that there is no requirement on the CA to proactively determine whether a
key is compromised, merely that there is a duty to permanently note a compromised key
once notice of compromise is brought to the CA's attention.

Ballot 3 attempts to note those pieces of information which should be stored in an
archive log (as opposed to the audit log); it sets out a new Section 5.4 and 5.5 which also
lays down retention periods for such data.

6. Any Other Business

No other business was discussed.

7. Adjourn

The meeting was adjourned and will reconvene on 2020-03-30.