[cabf_netsec] Minutes for NetSec meeting on 2020-05-28

[Neil Dunbar]

All,

Here are the minutes for the last meeting. Any comments or corrections,
do please let me know.

Note that there will be no meeting on Thursday 11th June, since the F2F
meeting will take precedence.

We will reconvene on Thursday, 25th June, at the regular time.

Thanks,

Neil


-------------- next part --------------
Minutes for NetSec Meeting - 2020-05-28

Attendees

Neil Dunbar (TrustCor) [Chair]
Bruce Morton (Entrust Datacard)
Tim Crawford (BDO)
Janet Hines (SecureTrust)
Daniela Hood (GoDaddy)
David Kluge (Google)
Trevoli Ponds-White (Amazon)
Clint Wilson (Apple)
Ben Wilson (Mozilla)
Tobias Josefowitz (Opera)
Wendy Brown (FPKI)
Corey Rasmussen (OATI)
Dustin Hollenback (Microsoft)

Apologies

Mariusz Kondratowicz (Opera)

1. Review Agenda

The agenda was reviewed and agreed.

2. Approve Minutes of Last Meeting

The minutes were approved.

3. Pain Points Subgroup Update

David reported that because of the public holiday on Monday 25th May, no pain points meeting was held.

Following on from the previous discussion, David continued the discussion on the outdated requirement
from 2.k, which requires CAs to lock out accounts after 5 consecutive authentication failures. The 
Pain Points group desired to get the state of the art on what current anti-brute force methods can
be deployed. There were no particular updates there, but David also wanted to solicit the reports from
CAs as to what methods they use to prevent brute forcing.

In his opinion, certain architectures make lockouts unnecessary, and wanted to know what architectures
other CAs use.

Neil volunteered what TrustCor use, which is to use SSH certificates (and public keys in some legacy
systems), combined with Duo Security authentication, tied to trusted devices to provide the second factor
authentication. Thus, since passwords are not used, and SSH public key authentications are not amenable
to brute force attacks. He said that it was certainly possible that a YubiKey OTP could be mistyped or a
Duo push could be sent to the wrong phone. He asked if failures such as the above would necessitate a
lockout. In his opinion, a lockout policy for that architecture is superfluous and would probably do more
harm than good.

David replied that such a description is consistent with architectures which are brute force resistant
by their nature, having multiple authentication factors and points. He said that five, or five thousand,
attempts to brute force the security would be operationally invisible, since it would not impact the
systems. The only effective brute force attack would be a denial of service flood, congesting the network.
Moreover, such an attack would be detected and mitigated by network monitoring, rather than the
authentication subsystems.

Neil thought that the five attempt lockout phrasing was predicated against a password as the sole
authentication factor. He gave a counterexample as a user having six SSH keys in his agent's keyring.
When logging into an SSH server, the client would rotate round each key until it found a successful
one. Should the authentication subsystem have locked out the account after the first five? In his opinion,
that would not be a reasonable policy, given that having multiple segments requiring different credentials
is a good thing - therefore a lockout policy acts against good security design, in some architectures.

Thus, he concluded, the lockout policy would be better replaced with a requirement not to use passwords,
but such a requirement would be very unlikely to succeed. He said that more likely was a requirement to
require all authentication failures to be monitored and acted upon if a configured threshold of failures
was passed, given that would flag a potential hostile act.

Trev asked if we really wanted to add yet another monitoring requirement - would a better solution not
be to require that authentication methods can repel or mitigate brute force attacks, whether through
multi-factor or alternative architectures.

David answered that we already have a requirement to monitor security relevant events, and that
authentication failures was at the top of the list of things to consider security relevant.

Neil also thought that the burden of monitoring was already present - all that a replacement 2.k would
state is the need to do something about potential hostile action.

Trev was resistant to monitor the commonplace occurrence of people mistyping their passwords. Neil replied
that it's more often people mistyping the account name, rather than a bad credential. Trev said that
if we think it is covered in security event monitoring, then we shouldn't need to worry about drawing
it out as an extra monitoring step, specific to passwords, since it's holistically covered; thus the
language should be changed to something which states that the authentication system architecture should
not be one which is easily brute-forcable.

Neil said that the document still needs some text around what CAs are currently doing, rather than
attempting to guess what might be the state of the art. David thought we could. Neil asked if exponential
backoff on passwords was a mitigation.

Trev thought we should try and avoid specific deployments, but make the requirement the goal - to
have a system which did not get brute forced. She wondered if the current requirements were drawn upon
a specific CAs deployments.

Neil thought not, saying that the requirements were the typical logic for account protection from 10
years ago. He concluded, asking Trev if she favoured, rather than a lockout, that the requirement should
be an authentication system which was resistant to brute force attempts, rather than an insistence on
a specific lockout policy.

Trev agreed that such would be her preference.

Ben suggested that the language could be expressed as "if a password is used as the credential, then...".

Neil offered "If a password is used as the sole factor of authentication, then sufficient provisions to
prevent brute force attacks shall be present". Ben thought that sounded good. Neil thought that it would
limit the scope of what 2.k addresses, which right now is every possible authentication method. Neil
added that he wouldn't know how to do a lockout on SSH public key failures, given how the SSH clients
work.

4. Threat Modelling Subgroup Update

This topic was skipped, owing to Mariusz being unable to attend.

5. Document Structuring Subgroup Update

Ben had three points to discuss.

On the last threat modelling call, there was a discussion on the log entries, and Trev followed up with
an email to the SCWG list, with some useful feedback.

With Document Structuring, Tim has come up with a cleaned up version of the Offline CAs ballot. He
would like this to be reviewed.

Lastly, Ben said that he would get the Zones ballot ready for review following the meeting.

Neil reiterated that he would be happy to endorse.

Trev said that we should not capitalise Physically Secure Environment. Neil said that they should not be
capitalised unless they are defined terms. Ben replied that they are in the new ballot.

6. F2F Presentation discussion

Neil has submitted a presentation on the Google Drive.

He presented the main points as being:

 - move away from periodic review as a staple of security, moving to continuous monitoring
 - replace outdate/poorly worded requirements
 - close unaddressed threats in the NCSSRs

followed by a one page summary for each of the subteams, and then the ballots

Neil asked if the various members could comment, with the notion of fitting it to the main
goals.

7. Account Management ballot

Tobi said that a new Github redline has been done and cleaned up the language.

The summary of changes still needs to be adjusted.

Some text around the intent of the ballot has been added to the discussion ballot. He stressed that
the goal remained to pursue continuous monitoring and automated threat mitigation.

Neil changed the text which referred to ballot SC20 and made it SC29.

Neil reminded Tobi that he had the two endorsers and then select a new ballot number from the wiki.

8. Any Other Business

Tobi asked if the F2F notes could be updated. He said that Continuous Monitoring is not the primary
goal, which is Security Automation. Continuous Monitoring was a means to an end, specifically
a properly implemented configuration management system would be a method to implement continuous monitoring.

We wanted to strongly enourage people to a continuous path, even though allowing manual reviews.

Neil said that as more CAs go down the automated route, the harder it will be for CAs to continue to
do periodic review.

Trev said that it would be harder, just ridiculous to continue down that path. Neil explained that what
he meant was that future ballots would come from the mindset of "Everyone is doing automated deployments
now", so the remaining manual review holdouts will have a harder time standing against such ballots, by
being outvoted.

Neil said that he would address that in the slides.

9. Adjourn

The meeting will be recovened in 4 weeks, since the F2F meeting will be over the next scheduled meeting.