Subject: [sacm] Ben Campbell's Discuss on draft-ietf-sacm-nea-swima-patnc-02: (with DISCUSS and COMMENT)

From: Ben Campbell <[email-masked]>
Date: Wed, 21 Feb 2018 19:09:31 -0800

Ben Campbell has entered the following ballot position for
draft-ietf-sacm-nea-swima-patnc-02: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sacm-nea-swima-patnc/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(This is related to one of Ekr's comments, but I don't think it's quite the
same.)

In the first paragraph of §7.2, the conclusions seem to be based on the
following sentence:

"This is generally not considered to be problematic, as
   those with access to the endpoint can usually learn of everything
   disclosed by that endpoint’s records simply by inspecting other parts
   of the endpoint."

This doesn’t seem like a reasonable assumption. Multiuser endpoints may well
have access controls that prevent a given user from seeing all software
packages installed on the system. This leads to the conclusion that the records
on the endpoint are not sensitive. I do not think this document should draw
that conclusion. Even if this were provably true for all existing systems, such
an assumption could be problematic for future systems.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Substantive Comments:

§2.4: This seems to assume there is never a need to hide information from
intermediaries. Is that the intent? (Or maybe there aren't any intermediaries?)

§3.4.3,
-- first paragraph: What is the expected scope of uniqueness for record
identifiers? -- In the sentence "The Record Identifier SHOULD remain unchanged
if that record is modified.", why is the SHOULD not a MUST? What would happen
if the identifier did change?

§3.4.4:

-- "However, if that directory is shared by other software products, the
"location" SHOULD be the location of the primary executable
   associated with the software product."
I'm confused by the the condition, since sharing a directory with other
products doesn't seem to introduce the ambiguity that the rest of the sentence
assumes. Perhaps this was meant to be about situations where a software package
is installed across multiple directories?

-- "Even a probable location for a software product is preferable to using a
zero-length locator." This could use elaboration; do you expect the collector
to guess?

§7.1: " Some tools might not be designed to update records in the Software
Inventory Evidence Collection in real time,..." Wasn't there a normative
requirement that they be capable of this?

§8,
-- 2nd paragraph: It’s worth mentioning that in some contexts this sort of
information could expose the user to severe personal risk, including the risk
of death. -- Last paragraph: "For this reason, privacy safeguards might be
necessary for collected inventory information." Can this be stated more
strongly than "might be necessary"?

Editorial Comments and Nits:

§3.8.5, first paragraph: "As noted in Section 3.6 SWIMA-PCs MUST ..."
Please reserve 2119 keywords for the authoritative statement of a requirement;
that is, please do not use them to refer to requirements defined elsewhere.
(Note that this pattern occurs multiple times in the draft.)

§9: Nit: is there are reasons to violate the convention that IANA, security,
and privacy considerations are the last substantive sections in in the body of
an RFC?

---

From: "Schmidt, Charles M." <[email-masked]>
Date: Sat, 24 Feb 2018 07:01:17 +0000

Hello,

> intermediaries. Is that the intent? (Or maybe there aren't any

This is not the intent. NEA has multiple parts and the intent is to clarify that the SWIMA part isn't the part dealing with data confidentiality. The portion that handles confidentiality is the PT layer of the NEA architecture. (PT-TLS and PT-EAP) All I'm trying to do is emphasize that, if confidentiality is an issue, make sure your NEA architecture is set up to support that. 

> if the identifier did change?

It is SHOULD rather than MUST because, under some tracking conditions it might not be possible to distinguish between a record being modified and a record being deleted and a new record being created. Will add clarifying text to this effect. If the system thinks that a modification is actually a delete/create action, it would be treated as such with a new record identifier being assigned to the "created" record.

> requirement that they be capable of this?

A subtle difference: The SWIMA-PC MUST detect changes to the Software Inventory Evidence Collection in near real time, but the data sources might not update the Software Inventory Evidence Collection in real time. I reworded to clarify the difference between the SWIMA-PC reading the Evidence Collection and the tool updating the Evidence Collection.

> and privacy considerations are the last substantive sections in in the body of

I'm happy to reorder these - a quick random sample of RFCs seems to provide a number of different orderings. I just followed the PA-TNC spec, since I had that open most. Just let me know what the expected order is.

Thanks a bunch,
Charles

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: Wednesday, February 21, 2018 9:10 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; Karen
> O'Donoghue <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]
> Subject: Ben Campbell's Discuss on draft-ietf-sacm-nea-swima-patnc-02:
> (with DISCUSS and COMMENT)
>