[cabf_netsec] NetSec Subcommittee Meeting 29-Nov-2018

[David Kluge]

Thank you for writing and sharing the minutes Ben.

I would like to volunteer for working on the asset classification part
(Define components of a Certificate Management System).

Also I wanted to elaborate a bit on my question about having one document
or two. I agree that ultimately it is the content that matters and not so
much whether it is maintained in one document or two. The actual reason why
I brought this point up is that I wanted to address the structure of the
current NCSSR document. I agree with Dimitris that it is "weird" and in my
experience this weird structure can have negative side effects. For example
the document is not straightforward to apply in the CA system design
process because the question which controls are to be implemented arises by
asset. In contrast, the current structure is based on control type (general
controls, controls for specific roles, logging monitoring etc.).


Organizing it by asset-type would could make it easier to add and modify
requirements and to reference them back to the threat analysis based on
which they were defined.

I think that while we are aiming for a "fresh" structure for the root CA
requirements it would be useful to do the same for the NCSSR doc.


I look forward to our call tomorrow.




On Sun, Dec 2, 2018 at 9:12 PM Ben Wilson via Netsec <netsec at cabforum.org>
wrote:

> Here are the draft minutes for your review.
>
> 29 November 2018
>
> Present:  Ben Wilson, Dimitris Zacharopoulos, Corey Chapeski, Tim
> Crawford, Mark Ruchie, Fotis Loukos, Neil Dunbar, Thomas Connelly, Marcelo
> Silva, Trev Ponds, Stephen Hillier, Tim Hollebeek, Tobias Josefowitz, Pavan
> Chander, Ken Myers, Peter Miskovich, David Kluge
>
> Ben noted that a Trello board had been created (
> https://trello.com/b/GPdBnML4/network-security-committee), and he
> reviewed the charter (
> https://cabforum.org/working-groups/scwg/network-security/), which says
> this about the Subcommittee’s deliverables: “shall propose ballots to the
> SCWG to improve the minimal security standards within the mission defined
> above. This includes modifying the existing Network and Certificate System
> Security Requirements (NCSSR) or to create new requirements, guidelines, or
> best practices. Among other activities, the Network Security Subcommittee
> shall perform security analysis on typical CA Management Systems offering
> options to the Server Certificate Working Group for establishing minimal
> security standards. Risk analysis will also be used to provide a better
> understanding of threats and vulnerabilities in Certificate Management
> Systems. This process can be used to provide better reasoning and
> justification of existing or future security guidelines”
>
> Dimitris suggested that the “shalls” would be the “minimal security
> standards” above and mandatory, whereas the “shoulds” would be “best
> practices”. We would start with the basics and then build from there.
>
> Fotis asked whether we would try to get to business that the previous
> working group was unable to complete.  It was agreed that we would review
> the previous work on the threat model for CAs and the identification and
> mitigation of threats, and build upon that work.
>
> Neil noted that we focused on the Root CA system, and that the online CA
> system has high vulnerabilities. Ben asked about attacks targeting issuance
> systems. Dimitris noted that he would like to create a new guideline for
> root CA management systems that addresses the risks but uses a model that
> is easier to understand.
>
> Fotis asked whether we would be looking at supply-chain threats or
> similar, like connection of USB sticks.
>
> Trev suggested that we identify all of the threats and then rank them.
>
> Dimitris asked how the ranking would work, based on likelihood, harm, etc.?
>
> Trev agreed that it would be based on factors like recoverability,
> likelihood and impact. She asked to review the previous work on risk
> identification, and Neil re-circulated the link to the Google Doc -
> https://docs.google.com/spreadsheets/d/16kRPobK31Qb7L4ooq4SJE6K6OmfPOizdtV9M-m475WU
>
> Dimitris explained the reason for wanting to re-write requirements for
> Root CA Systems—the current NCSSRs aren’t clear on how they apply to Root
> CA systems, whereas they are more geared toward online systems.
>
> Tim Crawford expressed concern that different controls for different
> layers of CA systems would create confusion.
>
> Ben said we might be able to work through that with the way we structure
> the documents.
>
> David asked why create a separate document.
>
> Dimitris responded that the current NCSSRs were a response to the
> Diginotar incident and had weird structuring—the idea is to start fresh
> with a better structure.
>
> Trev asked whether it would be better to work on content first, and then
> structure.
>
> Neil noted that the work product of this committee would go before the
> Server Certificate WG as a ballot.
>
> Fotis noted that we could use Mozilla’s Sea Sponge to work on the threat
> model. It was agreed that we should take a look at it, and Neil said he
> would play with it to see more about its capabilities. Fotis had additional
> notes that he would send to Neil.
>
> Dimitris responded to Trev that he was going to try and follow RFC 3647
> for the structural outline.
>
> Fotis asked if we would have sub-sub-committees, and Neil suggested that
> we only do that when we have a ballot to work on. Dimitris clarified that
> no one is prohibited from informally grouping up to work on items within
> the scope or charter of this subcommittee.
>
> Thomas noted that the last time we worked on this we  didn’t focus as much
> on the offline root. We should identify the controls and see if they are
> still valid and still work.
>
> Dimitris said we would try to address and accommodate a variety of
> deployment models, and mainly the most common ones. He also said we cannot
> be over-prescriptive.
>
> Neil noted that in the end, we need to have auditable criteria, and
> everyone agreed that it was good thing to have auditors participating in
> the group.
>
> Next meeting is December 13, 2018, meanwhile we’ll continue to conduct our
> work on the mailing list.
> _______________________________________________
> Netsec mailing list
> Netsec at cabforum.org
> http://cabforum.org/mailman/listinfo/netsec
>


-- 

David Kluge | Technical Program Manager | kluge at google.com |  +41 44 668 03
54
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/netsec/attachments/20181212/c16d9714/attachment.html>