[cabf_netsec] Minutes of meetings: 2020-01-05 and 2020-01-19

[Neil Dunbar]

All,

Here are the minutes for review. Please give me any feedback if any 
changes are needed.

Best,

Neil


-------------- next part --------------
Network Security Subcommittee Meeting
2021-01-09

Attendees

Neil Dunbar (TrustCor) [Chair]
Ben Wilson (Mozilla)
David Kluge (Google)
Corey Bonnell (DigiCert)
Corey Rasmussen (OATI)
Tim Crawford (BDO)
Clint Wilson (Apple)
Trevoli Ponds-White (Amazon)
Aaron Poulsen (DigiCert)

1. Agenda

The Agenda was approved

2. Approve Minutes

The last three sets of minutes were approved

3. Cloud Services Group Update

At the last meeting of the Cloud Services team, the development of the components
component analysis continues. This will continue into the next meeting.

In the meantime, David had asked Google's compliance department to perform
an analysis between the various security standards documents which pertain
to Cloud security and compare with the NSRs. The document is very new and
the full analysis has not been performed. David hopes that the team will be
able to join the 2020-02-01 meeting.

David is also preparing a report on the DigiNotar breach analysis and how the
NSRs match up to threats and errors highlighted by that report.

Neil said that he would be very interested to see the comparisons document. David
said that it is a lot of data, and he wants to see it presented in a high level
format, rather than risk information overload.

4. SC38 Updated Ballot

Neil presented a newer version of SC38, which addresses the concerns which Ryan
brought up in the SCWG meeting. The new version removes reference to 5.5.2 in
sections 1.3.2 and 4.1.1, instead placing the referring sections with explicit
duties on the CAs.

In the case of 1.3.2, the new text mandates that an RA must retain information
for seven years.

In the case of 4.1.1, the new text pushes the suspicious activity details into
5.4.1 and its retention into 5.4.3.

Then 5.4.1 and 5.4.3 requires a new category of "suspicious requests" with
different requirements.

This means that 5.5.2 serves no purpose, and is then withdrawn in the text.

Trev commented that the requirement to maintain a database seems a very strange
one, and it should not exist in the BRs. There followed some discussion on
the nature of suspicious activity and its use.

In particular, Trev noted that the revocation of certificates does not form
a good basis for suspicious activity tracking. She suggested that there are
many other pieces of information which would be used as bad actor detection.

Neil asked for review of the document from the team.

Tim asked about 1.3.2 - does this mean external RAs only. Neil replied that 
the section refers to Delegated Third Parties. Trev thought this strange that
CAs should need to police DTP activity. Tim replied saying that the CAs
merely need to ensure that their contract with the RAs has a clause that the
RA will retain certificate issuance and revocation information.

Neil added that the CA will not know exactly what information the RA has,
hence the need for retention.

Aaron commented that the only information which CAs are required to refuse
issuance on would be weak key checks. 

Ben commented that the motion text deletes an entire section, but the
new text merely replaces a subsection. That needs fixing.

He also thought that the 1.3.2 text should apply to all RAs, not just
DTPs. Neil said that he would address that.

Tim commented that the 5.4.3 retention period might need to be changed into
a separate section.

5. SC39 Updated Ballot

Neil explained that the new text forces CVSS version to 2.0, but keep the
threshold the same (7.0).

The discussion turned to the distinction between the 96 hour and 6 month
patch window. Neil commented that addressing that would be a different ballot.

6. Any Other Business

There was no other business.

7. Adjourn

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

-------------- next part --------------
Network Security Subcommittee Meeting
2021-01-19

Attendees

Neil Dunbar (TrustCor) [Chair]
Wendy Brown (FPKI)
Corey Bonnell (DigiCert)
Tim Crawford (BDO)
Tobias Josefowitz (Opera)
Ben Wilson (Mozilla)
Aaron Poulsen (DigiCert)
Corey Rasmussen (OATI)
Dustin Hollenback (Microsoft)
David Kluge (Google)
Cezary Cerekwicki (Opera)
Trevoli Ponds-White (Amazon)
Janet Hines (SecureTrust)

1. Review Agenda

The Agenda was agreed.

2. Cloud CA Subteam Update

Neil asked if the Cloud CA Subteam meeting was per the wiki (14:00 UTC). David thought that
might have been the case, but Tobi said it was 15:00 UTC. David said that he would resend
the meeting invitations.

David presented the current report, with the analysis into components which could be exported
into Cloud environments, with axes on likely impact versus "core-ness" to a CA. Examples
include log archival, which could be exported to a cloud provider: this would have a relatively
low impact, but it is very close to a core CA service.

Each component has a page which details the type of service, which risks and benefits a
cloud deployment might have, and which assumptions and unsolved challenges remain. Current
pages, still under development, included logging, source code management and network load
balancing.

What remains to be decided is whether the next steps would be to look at various scenarios
and the risk analyses for each segment. Should the document be brought into NetSec proper
for further development, or remain in Cloud Services for the time being?

Neil said that he would still like to see the analysis which Google's compliance team
have performed on the various relevant cloud standards versus the NCSSRs. Specifically, the
question would be if a known bad actor (like DigiNotar) had been measured against these
requirements, where would they (if at all) have been detected?

Once this was done, it might be possible to bring this into NetSec and examine which
NCSSRs conflict with Cloud Services. David replied that one thing which was yet to be
decided was whether Cloud Services should merge its content into the NCSSRs or spin off
a new document of requirements. David's personal inclination was to define a new
standards document; the current NCSSRs are more directed to an on premises deployment.

Neil commented that, assuming SCWG adopted that document, then the audit teams would
need to develop criteria based upon it.

3. SC39 Update

Neil presented the latest SC39 discussion document. He has sent this new version to the
SCWG, and will move it into the voting stage once it has passed the discussion phase.

4. SC38 discussion

Neil reported on a discussion he had with Clint Wilson of Apple, regarding SC38.
One issue that Clint brought up was that audit log is not a well defined term, but
also what is expected from sections 1.3.2 and 4.1.1 does not coincide with what
many people expect out of an archive log.

A concrete concern was that section 4.1.1 seems to serve little, if any, purpose.
Firstly because of a lack of duty to do anything with the certificate/request database.
This developed into a discussion onto what would cause a CA to refuse a (potentially
suspicious) request: and that this would most likely be a violation of the Subscriber
Agreement between applicant and CA.

Clint intended to reach out to the other browser root programs to see if that attitude
was shared. Neil asked the browser members if that communication had been received,
but Ben and others replied that it had not come yet.

Clint also thought that the entire audit vs archive sections needed to be restructured.
Neil said, were that the case, such a restructuring goes well beyond the original
intent for SC38 which was merely to bring retention periods into alignment.

Neil continued saying that it may not make much sense to proceed with SC38 as is, but
rather to introduce new, smaller ballots to deal with 4.1.1 and 1.3.2 separately,
and then to address the 5.4/5.5 contents accordingly.

Ben replied that he had examined RFC 3647 to see if any guidance exists for 5.4 and 
5.5 exists. The only guidance seems to be on content (archive records) versus
audit logs. There doesn't seem to be a good answer.

Neil was interested in knowing from the root programs what they see as the value of
the suspicious certificate database. He said that if there was a requirement that
Subscriber Agreements contain clauses to refrain from fraudulent or phishing style
behaviour, that would be an easily auditable criterion.

Neil said that the answers which he submitted as audit evidence, there was a requirement
to identify suspicious activity, but that no questions exist to enforce any sort of
behaviour from that database. He asked Tim if WebTrust has any guidance to practitioners
regarding this database.

Tim replied that there is a control to maintain such a database but not to do anything
with it.

Neil said that he would prefer that there was a set of requirements for good hygeine
in the WebPKI, and to that effect the following controls should exist - then that would
be a more concrete auditing proposal.

Trev commented that she was also surprised about 4.1.1, since it concerns who can apply
for a certificate. It would make more sense for the section to specify which sources
that a CA would consult into deciding whether to allow the request or not.

Neil replied that it seemed absurd to have a record of certificate requests which were turned
down owing to suspicious activity; would the re-presentation of such a CSR automatically
be suspicious?

Ben said that in his expectation, he would want the database to inform malicious application.
In response to Trev, he replied that it throws out a requirement with no expectations.

Trev said that this seemed to be a strange thing, since a large company could easily
have a single certificate rejected for bad behaviour - would that then contaminate the
entire company from receiving certificates?

Neil moved on, saying that the example of Parler was that it was removed from Google, Apple
and AWS because it had violated Terms and Conditions of its agreements, not because of
any particular activity relating to certificates.

Neil finished, saying that the tight scope around SC38 has ballooned now, to include the
dangling references, which makes the ballot unwieldy. The correct approach might be
to attempt piecewise remediation of the issues and then address the structural issues.

5. Offline CA Ballot progress

Ben said that the discussions over the text have probably reached the end. He hadn't yet
had time to fix up the text, but he wondered who was willing to second the ballot. He
knew that David had indicated support, but was unsure of a second endorser.

Neil had said that he would take a look at the finished text and would endorse if the
text seemed appropriate.

6. Any Other Business

On the "zones" ballot, Ben had withdrawn that ballot and would rephrase it all with the
text of "logical and physical controls".

Ben also mentioned that Ryan's forthcoming proposed edits to "pandoc"-ify mean that the
NCSSRs definitions move from the top to the bottom of the document. Ben asked if there
were any questions. Neil said that he was happy with the proposed changes.

7. Adjourn

The meeting was adjourned and will reconvene on 2020-02-02