[cabf_netsec] Minutes for NetSec Meeting 2021-03-30

[Neil Dunbar]

All,

Please find attached the (rather long) minutes for the 30th March 
meeting for consideration. If there are any corrections or observations, 
as always, do let me know.

Thanks,

Neil

-------------- next part --------------
Network Security Subcommittee Minutes - 2020-03-30

Attendees

Neil Dunbar [TrustCor] (Chair)
Aaron Poulsen [DigiCert]
Corey Bonnell [DigiCert]
Corey Rasmussen [OATI]
Bruce Morton [Entrust]
Trevoli Ponds-White [Amazon]
Ben Wilson [Mozilla]
Clint Wilson [Apple]
Tobias Josefowitz [Opera]
Dustin Hollenback [Microsoft]
Janet Hines [SecureTrust]
Tim Crawford [BDO]

1. Review Agenda

The Agenda was reviewed and agreed. Clint asked for a little time to cover some
additional queries he had around definitions of OCSP Entries and IP addresses in
logs. Neil added that time to Item 5 on the Agenda.

2. Agree Minutes

The minutes from the previous meeting were approved.

3. Cloud Services Team Update

David was absent from the attendees and there was no Cloud Services Team meeting
scheduled, so there was no update.

4. SC40 Update

Subsequent to an email to the list, Ben summarized that he had come up against a
brick wall while trying to improve the language. He was unable to determine a good
path forward to a version 4 of the ballot, so decided to let the ballot fail, and
attempt to bring back an altered text which could address the issues covering the
points raised on the list.

Ben reported that the NCSSRs currently demand that the Root CA system be "offline"
but no clear definition of "Root CA System" exists outside of an intuitive model.
It was unclear if the HSM was the offline part, or even just partitions being
deactivated, or whether the entire software stack of all components is included. If
a proper definition of scope can be constructed perhaps it will become easier to
address the points raised.

Neil commented that for some HSMs, activation of partitions is the only method by
which multi-person/party control can be maintained; therefore deactivation would
be an essential component.

Trev asked whether systems was included within the WebTrust language, brought up
via GoDaddy, and that the language was overly broad. Ben replied that it was more
the definition of "Certificate System" which was deemed overly broad. Ben continued
that isolating down the definition of CA system to its bare essentials would be
helpful. 

He asked if an HSM which was disconnected from anything, activated or not, would
still be allowed, since no signing activity can be performed until other equipment
is connected to the HSM. Neil said that might depend on the type of HSM - Network
/USB/PCI. Neil added that it might indeed be useful to start from the bottom up.

Ben replied that where a group of HSMs (referring to Wendy Brown's observation)
were disconnected, this still would count as an offline system for the purposes of
SC40; even if one was connected up for essential operations for a short time.

Ben does not wish the text to languish indefinitely, but he does think that the
21 day limit is too tight for this sort of ballot. Neil agreed, saying that it
was a large ballot and needed to be properly digested, and the list server unavailability
for some days meant that the ballot could not have been discussed anyway.

Ben said if anyone had definitions which would help, to get in touch with him.

5. Replacement ballots for SC38 sections

Clint introduced some ballots which he had been working on to replace the abandoned
SC38 ballot. These touch on logging and archiving; looking back on SC38, one of the
problems was that in reviewing the BRs/NCSSRs/RFC 3467, there was no real alignment
with real world expectations on how logging and archiving were supposed to happen;
specifically around audit logs and retention and data archive and its retention -
there is no clear link between the archive and the audit log material.

Clint introduced three ballots, and desired feedback on direction and specifics.

The first ballot simply removes BR Section 4.1.1 in its entirety. No matter what
better requirements were substituted, the goal was the same: a fruitless endeavour
with no clear gains. In particular, there is no clear premise on the meintenance
database of suspicious activity which makes sense to the Apple Root Program.

The second ballot replaces Section 4.1.1 with a requirement to maintain a database
of known compromised key in perpetuity. While this might already be assumed as a
duty on CAs, there is no clear requirement to maintain this database. The language
is sufficiently general as not to demand a particular technology, but the intent
is that the CAs must reject certificates which are known to be compromised.

Neil asked if the language covered the case where a certificate is revoked for a
reason which is _not_ key compromise; and later the CA discovers that the key has
indeed become compromised. Since the CA cannot re-revoke the certificate, the key
can be placed into the database; it also covers the case where private keys have
been leaked. There is no requirement to monitor a specific source of compromised
keys, the CA has a duty to add that to their database.

Trev said that she was a fan of deleting 4.1.1; she asked if the compromised key
database belongs in 4.1.1, or whether it belongs elsewhere. Clint replied that
much of the text could go elsewhere, but that the requirement to reject a certificate
does belong there.

Trev also asked if the word database could be removed, since it defines a specific
technology. Trev suggested "CAs should maintain a mechanism by which certificate
requests will be rejected if their keys are known to have been compromised". Clint
agreed, saying that the text needed to focus on what the CAs should be preventing,
rather than how they should go about preventing it.

Corey (Bonnell) mentioned that the ROCA vulnerability is more of an online check for
vulnerability, rather than a defined table; and so suggested that the language
encompass that model of operation, as well as a local discrete store. Clint
agreed that the text should reflect that model too.

Clint asked if there were any other places where the text should belong. Bruce
suggested that 6.1.1.3 should be included, but that Section 4 should define the
practice to detect weak keys. Clint added that he wanted it early on the process
since CAs should be checking early on.

Bruce asked that if a CA revokes a certificate due to key compromise, and that
the CA knows about another certificate it has issued which shares the same key,
that second certificate should be revoked too. Clint said that was a definite
yes. Neil suggested some language and Clint thought he could adjust to fit.

Clint introduced the third ballot, which consolidates and clarifies Sections
5.4 and 5.5 of the BRs in respect of types of events retained and retention
periods. The new 5.4.1 (2) now includes the requirement to retain documentation
for events.

The second set of changes moves 5.4.3 (retention for audit logs) into 5.5.2
(Retention period for archives). The intent here is that long term retention
is a function of archive, rather than audit log, which could be stored in,
for example, Splunk for 30 days or 90. Clint stressed that this was down to
his reading of RFC 3647, but other interpretations exist.

Clint explained further that the need for documentation was because the previous
5.5.2 required the retention of documentation for certificate events; he
believes that the majority of what was required covers much of documentation,
but by explicitly including it, the full scope of what must be retained does
not change.

Finally, a statement in 5.5.1 was introduced, which states that audit log
records must be retained per 5.5.2's retention period.

Trev asked if an archive was a second copy of data; Clint replied that it was not
defined as such, but it could be.

Tim said that perhaps 5.5.1 could simply state that everything in 5.4.1 should
be stored per 5.5.2, to make the type of data explicit to avoid the text
mirroring.

Trev said that it was unclear from the text if the expectation is that a CA
has an archive for disaster recovery perspective, or rather if the CA can produce
the logs. Clint replied that the current BRs imply the latter, because no backup
requirement is defined. Trev suggested that then "archive" is synonymous with
"store".

Neil asked if 5.5.2 should state "The CA and each Delegated Third Party", in
order to mirror the existing text from 5.4.1. Clint suggested that the DTP
would be sending the logs back to the CA for storage. Neil said that would be fine,
but wanted to avoid a "get out of jail free" scenario where a CA could simply
say that a DTP with no duty to retain the logs was the sole storer of the
relevant data.

Trev suggested some text that spells out the duty that either the DTP or the CA
should store the data; but the CA is solely responsible for the data being retained.

Clint then introduced two more questions for the group to opine upon.

The first question was the meaning of "OCSP Entries" as mentioned in 5.4.1 for
Subscriber Lifecycle Certificate Management. What are CAs logging and retaining.

Neil said that WebTrust imposes a duty to retain old CRLs, but not OCSP Entries.

Clint then asked if an OCSP Entry is the signed OCSP response? Or is it the Entry
in the database which marks the certificate as good or revoked.

Trev asked why we would care about old OCSP entries. Clint stated that there is
a reason to care that a CA reached a determination that a certificate needed to
be revoked; but do we care if OCSP Entries are retained - Clint didn't know what
an OCSP Entry _is_.

Trev suggested we start from "what do we care about" and work backwards into
stipulating what gets stored or mandated from that. Neil replied that one of the
reasons that we might care is that a certificate does not get "un-revoked" per OCSP;
a certificate should either expire or get revoked, but never revert to a "good"
status. Neil suggested that the section might have been designed for CRLs, rather
than OCSP; that his company logs the production of OCSP Entries in their batches
and the success/failure thereof, but not each individual OCSP Response in a log
entry.

Bruce suggested that it might be to give the CA backup to prove that they had
revoked a certificate. 

Trev said that one interpretation would be that we need to record OCSP generation
so that evidence can be adduced regarding latency and availability of OCSP responses
during the certificate life cycle. Trev noted that there is no requirement to record
the _result_ of an OCSP response generation. Clint noted that such a requirement would
be theoretically valuable, but such an effort would be huge. He added that he sees
the value as being the act of moving a certificate from trustworthy to revoked is the
key piece of information as to what to record.

Clint asked the question as to whether this means that all OCSP response generations
should be recorded, or merely the first one after a determination that a certificate
should be revoked. The BRs do not contain the context to determine that unambiguously.

Corey said that he could see the value of each response, because the log of the
use of CA key material is valuable. Clint then asked if that meant the logging of
the signing of a response, but not the actual response. Trev thought this was the case
since its not about OCSP, but rather key usage.

Clint thought this was a reasonable interpretation.

Trev brought up Sections 4.9.9 and 4.9.10, which talks about revocation entries on a
response not being removed until the certificate expires. She suggested that a similar
duty obtains to OCSP.

Neil suggested that with the logging of revocation, and logging of a response which
states that an OCSP response containing that revocation is being generated, an upper
bound on time to publish, and time to cache expiry (if using a CDN) can be deduced,
meaning that the CA can establish that a relying party had all the information needed
to calculate that a certificate should not be trusted.

Clint asked if the text should reflect this intention. Trev thought yes, and Neil
agreed. Trev suggested that the text be split out into the things we care about,
and that section 5.4.1 specify the obligations of revocation latency from 4.9.

Clint asked if this needed a separate ballot; Neil thought not - that the 5.4 and
5.5 ballot could contain this text.

Clint then asked about IP addresses. Should audit logs record the IP addresses of
each entity which accesses a CA service?

Trev said that she had seen it defined as being recordable where the IP address can
serve as a method to identify an accessing system. Clint asked if that then replaced
the recording of the "person making the entry". Trev stated that the guidance she had
was a unique identifier; so the IP address has no special status - it might be a
unique identifier, or it might not, depending on situation.

Clint agreed; it is not needed in itself. Trev argued that she did not like IP
addresses, since they rarely serve as persistent unique identifiers. Neil agreed, saying
that the meaning of 10.1.2.3 could mean anything, and the prevalence of NAT hardware
meant that the its value as an identifier was excessively low.

Clint asked if the text should clarify this interpretation; he thought not since
it seemed like the interpretation of IP as a unique identifier was the dominant one.

Neil replied that the drive should be "If I [a CA] have an IP address from an
accessing system, and I have good reason to think it determines a persistent identity,
I should record it", since what we really want to record is "Who did this thing";
and something like an RFC 1918 address does not serve that.

Dustin did mention that a network could be strongly constrained to allocate IP addresses
to individual hosts and their services. Neil agreed, adding that IPv6 could strongly
bind to an individual or service; however, since IPv4 is still widespread, most IP addresses
will be gross categorisations of devices making API calls, rather than specific and unique.

Clint said that he was happy with the input.

6. Discussion on ballots for file monitoring

Owing to the discussion above, this discussion was delayed until next meeting.

Neil said that two discussion documents on draft ballots were in the Google Drive 
and members could look at them.

This ballot is an attempt to mandate file system monitoring or read only file systems.

7. Discussion on ballots for vulnerability patching

Owing to the discussion above, this discussion was delayed until next meeting.

This ballot is intended to close up the leeway given in the NSRs, with exceptions
for air-gapped systems.

8. Any Other Business

There was no other business.

9. Adjourn

The next meeting would occur on 2021-04-13.