[cabf_netsec] NetSec Meeting Minutes for 2021-02-16 meeting
ndunbar at trustcorsystems.com
Wed Feb 17 14:12:17 UTC 2021
These are my draft minutes from the meeting on 16 February.
As always, read through - comment and correct anything which I might
have got wrong or missed, and I'll adjust the minutes.
-------------- next part --------------
Network Security Subcommittee Meeting Minutes
The Agenda was accepted with no amendments
The set of the last three meeting minutes were approved.
3. Cloud Services Team Update
David said that the team had met earlier to discuss the next steps of the work;
whether to continue with the case by case risk analysis or to focus on other document
preparation. No firm conclusions were reached at the meeting, but the work is ongoing.
One topic which was discussed was the notion of a baseline standard, that is not to
try and produce a complete standalone document, but to reference an existing standard
like ISO documents or other SDO produced documents for high security environment.
Tim had mentioned that the current (WebTrust) audit framework does not allow for
carveouts, where a component of an organization under audit outsources a section of
the work, and the compliance documents for that outsourcing provider are used as
evidence of controls in place. The team discussed whether this would be possible in
a long form audit report, or whether it would be necessary if other oversight controls
were in place to attest to the outsourcing provider's performance.
Discussion continued on the report regarding the DigiNotar breach, which had first
been presented two weeks ago. The discussion focussed on areas where the NCSSRs could
be more specific: for instance, mandated log data separation between log producing components
and log storage/integrity analysis components; other issues surrounded secure system
architecture and file system monitoring, such that system libraries and binaries
should be monitored for change on an ongoing basis.
4. SC40 Discussion
Ben reported that he had hoped to move the ballot forward now that the wording around
"Air Gapped" was more or less settled. However, it would appear that current SCWG
discussion focussed around the notion of unidirectional flow of inputs and outputs
to an Air Gapped system. It was acknowledged that the same mechanism could be needed
initially for input (say of CSRs) and then output of signed artifacts (certificates
or CRLs, for example). This would make the flow temporarily bi-directional until
the Air Gapped system had completed its signing functions.
In the case where the HSM is producing a self signed object which lives on that HSM
then the flow is indeed unidirectional, but in most scenarios, the objects need to
be exported from the Air Gapped system for publication in some other online state
(for example CRLs, or Sub-CA certificates). Ben reported that Ryan (Sleevi) still had
concerned about the security of that process. It was unclear whether we can
wordsmith the ballot on the call.
Neil said that one could have two devices - one for input and one for output, thus
preserving a unidirectional flow from inputs to outputs. To answer Ryan's question
as to whether the input device is bringing some undesired material to the Air Gapped
system. Neil said that the threat models defined the appropriate response. If the
threat was that the CA had lost custody of the CSR input device, then there is a
much bigger problem than the existence of a USB. Therefore one model would be to have
a read only input device, with all forms of auto-run functionality disabled, as well
as executable content disabled on the file system of the USB; and then for the
Air Gapped system to erase all content on the output USB device upon its being connected
to the Air Gapped system.
Ben replied that this might be difficult to put into succinct language, which then
upsets the balance of the text in the ballot. Neil said that the critical point is the
unidirectional flow of the data, rather than explicit controls around possible I/O
In response to further questions on that matter, Neil replied that he would expect a
system to sanitize any inputs it receives, by disallowing any capacity to execute content
from that device - reading only data. Neil also suggested that the output flow could
be made unidirectional by printing the data out and scanning it later via OCR.
Tim (Hollebeek) said that OCR is not such a good idea because it has some predictable
errors and has exhibited security problems in the past. He would not wish to see it
Neil also suggested a non-RX serial port output, which also would not allow input into
the Air-Gapped system, or displaying a QR code on a screen which is scanned in via a
mobile phone. To Aaron's question of what problem does the two device issue solve, Neil
replied that it allows post-ceremony analysis of the input materials - if it could not
have been altered by the Air Gapped system by being read-only, the analysis is easy
to make. Alternatively, the same USB device could be read in, then erased. Aaron said
that it depends on whether we desired physical or logical controls to ensure device
integrity. Physical would mean separation of devices, logical could be done by formatting
the device before outputting data.
David asked how this would be audited. He thought that some auditors might have trouble
asking for evidence to establish the unidirectional flow. So what would be enough to
establish that the input drive was indeed free of threat. Ben replied that the formatting
of the output device could be part of the ceremony transcript. Another would be to record
that the input device was prepared in a witnessed fashion so as to include only those
pieces of data required for the ceremony.
David further explained that some CAs use a pre-prepared (executable) script which is
then copied onto the Air-Gapped system and executed to complete the ceremony. He explained
that this is no longer strictly unidirectional. Ben said that for each CA, one would need
a profile document (which is machine readable data). Neil said that a system construction
document would need to be made available to the auditors so they could measure whether
it had been properly built.
Neil asked if such a script would be signed, so that the Air Gapped system would know
that it would not carry undesired data which could harm it.
The issue that Ryan raised was that assurance was needed that no nasty software was
being introduced via the inputs to the Air Gapped system. David was surprised that this
point was raised, as any well run ceremony is not going to allow arbitrary devices to be
plugged into a high trust system. Ben replied that we could say that the ceremony wrapper
could be introduced into the language along with a requirement that the output was
sanitized in some fashion.
Tobi brought up the point of how we can know if the device being sanitized is actually
being erased properly. David said that one could go down endless rabbit holes, and that
he would rather trust to the procedural controls on the ceremony to ensure that
risks were adequately addressed.
As a suggestion, Tobi suggested that we do not read from a file system on a USB drive.
Rather a very simple data stream of length + data would be read from the input device.
Similarly the output would be a simple block device output, rather than a kernel module
which handles file system abstractions. With no file system, there is lower risk
David asked if the file system code is a real concern. Tobi replied that it certainly was.
The Linux kernel used to assume non-adversarial inputs, and would trust that the file
system was properly constructed - which might not be true, causing the applications to
read data other than that which the author intended.
A discussion on auto-run functionality followed, with the consensus being that autorun
would not be enabled in any sane configuration, and that failing to prevent it would
indicate lax controls.
Neil commented further that Ryan's point raised was that a transcribe-and-verify method
was to be preferred (from his opinion) which would necessarily mean that an Air Gapped
system could not have - even temporarily - any device introduced into it which had been
connected to the non Air Gapped system in its life (ie, no risk of contamination could
be present). This seemed to be a tricky thing to achieve in given the amount of data
which would need to travel back and forth. Neil said that if the inputs were sanitized
prior to use (while not attached to the Air Gapped system), then the threat seemed
difficult to see. David concurred, saying that one can always construct threat scenarios
but a reasonable risk acceptance needs to be made. David thought that the highest risk
in a documented ceremony is human error, since many parameters to the to-be-signed
artifact can be set wrongly, therefore adding unwarranted complication to the mix tends to lower the
level of security.
Bruce suggested that Ryan's proposal might be considered out of scope, since this new
ballot introduces no new risks which are not present in any CA's operations anyway.
Neil indicated agreement with this point: all input carries risk. David also suggested
that the ceremonial aspect would act to lower risk because of the rarity of use.
Ben said that he would consider the points raised to see if the documented ceremony
point would assist the ballot wording.
5. F2F document
Neil presented a rough draft of the F2F presentation, adding that a summary
presentation would accompany it for the second day of the F2F.
[The document is on the NetSec Google Drive and is available for NetSec members
to view and comment on]
An open discussion followed regarding the format of the subcommittee day. Neil
said that he did not consider the standard meeting format to be productive for
the F2F meeting, and a review and projection document seemed better. However
he asked for the team's opinion and views on how best to structure our time.
Tobi and David both suggested that, instead of continuing on the theme of ballots
to improve the NCSSRs, which seem to hit technically oriented roadblocks with
regularity, a wider discussion could be entertained to produce an "implementors notes"
document which illustrated a hypothetical CA's deployment (rather than normative
texts), drawing on the text of the NCSSRs, and that future mailing list discussions
could end up amending the technical details of that document, rather than
addressing them in the policy and standards side of things in the BRs or NCSSRs.
Both Tobi and David thought that some members of the SCWG had expectations on
the output of the NCSSRs which could not realistically be met in the main language.
Neil thought this was a very useful way forward, and that he would adjust
the slides accordingly. He asked that others also adjust the slide deck with
their observations and input, and that there would be back and forth on the list
until the F2F.
6. Future Ballots
There was not much time to conduct this section of the discussion.
Clint reported that he had some preliminary language to deal with the issues
which arose out of SC38, with consideration into the 5.4/5.5 log retention periods,
the suspicious application database.
Neil said that he was happy to follow up on this, and would meet with Clint
to continue the development of those ballots.
7. Any Other Business
There was no other business to be discussed.
The meeting was adjourned and will reconvene on the F2F meeting schedule on
More information about the Netsec