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

[Ben Campbell <[e-mail]>]

Hi Charles,

That sounds like a perfectly good plan.

Thanks!

Ben.

> On Mar 10, 2018, at 10:27 PM, Schmidt, Charles M. <[e-mail]> wrote:
> 
> Hi Ben,
> 
> Thank you for the clarification. I'm following you now.
> 
> I agree that I misused "end-to-end" in the description of this requirement. "Confidentiality" would be a better section name. I'm sure the RFC editor will have some additional fixes for me to do, and I'll make the switch in the next draft.
> 
> Thanks,
> Charles
> 
>> -----Original Message-----
>> From: sacm [mailto:[e-mail]] On Behalf Of Ben Campbell
>> Sent: Friday, March 09, 2018 4:22 PM
>> To: Schmidt, Charles M. <[e-mail]>
>> Cc: [e-mail]; [e-mail]; The
>> IESG <[e-mail]>; Karen O'Donoghue <[e-mail]>;
>> [e-mail]
>> Subject: Re: [sacm] Ben Campbell's Discuss on draft-ietf-sacm-nea-swima-
>> patnc-02: (with DISCUSS and COMMENT)
>> 
>> Thanks for the response. I still have a point of confusion, inline. Also, keep in
>> mind that I have cleared my DISCUSS; this is a non-blocking comment and
>> you are welcome to handle it however you please.
>> 
>> Ben.
>> 
>>> On Mar 5, 2018, at 7:11 PM, Schmidt, Charles M. <[e-mail]>
>> wrote:
>>> 
>>> Hi Ben,
>>> 
>>> Thank you for the follow-up. I made some additional modifications (-04
>> draft) that I hope address your remaining comments.
>>> 
>>> Regarding your nit, I moved the Relationship to Other Specifications before
>> the Security Considerations. The last sections are now the three you note.
>>> 
>>> Regarding your comment on 2.4:
>>> 
>>>>>> §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?)
>>>>> 
>>>>> 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.
>>>> 
>>>> I think what is confusing me is the “title” of the non-requirement is “End
>> to
>>>> End confidentiality”. I admit to not knowing the sacm work well enought
>> to
>>>> know what the “ends” are, but am I correct to assume that PT-TLS, like
>> most
>>>> uses of TLS, is hop-by-hop? Does the data every cross more than one
>> hop? Is
>>>> the answer the dame for PT-EAP?
>>> 
>>> Re-reading this section, I agree that the section was confusing. I renamed
>> the section to "Non-SWIMA Requirements" (and renamed the preceding
>> section to "SWIMA Requirements"). Hopefully this clarifies that the
>> specification is not talking about what is and is not required, but simply
>> which requirements need to be addressed by SWIMA and which
>> requirements need to be addressed by other standards.
>>> 
>>> I also changed the text as follows:
>>> 
>>>  There are certain capabilities that users of the SWIMA specification
>>>  might require but which are beyond the scope of SWIMA itself and need
>>>  to be addressed by other standards.  This list is not exhaustive.
>>> 
>>>  End to End Confidentiality:  The SWIMA specification does not define
>>>     a mechanism for confidentiality, nor is confidentiality
>>>     automatically provided by using the PA-TNC interface.  In the NEA
>>>     architecture, confidentiality is generally provided by the
>>>     underlying transport protocols, such as the PT Binding to TLS
>>>     [RFC6876] or PT-EAP Posture Transport for Tunneled EAP Methods
>>>     [RFC7171] - see Section 7 for more information on related
>>>     standards.  The information conveyed by SWIMA is often sensitive
>>>     in nature for both security (Section 8) and privacy (Section 9)
>>>     reasons.  Those who implement SWIMA need to ensure that
>>>     appropriate NEA transport mechanisms are employed to meet
>>>     confidentiality requirements.
>>> 
>>> Hopefully that makes things clearer. To more directly answer your
>> question, PT-TLS is just TLS with some minor added constraints to fit with the
>> NEA architecture. Likewise, PT-EAP is basically just EAP. SWIMA should be
>> agnostic as to whether or not there are hops in the transmission and
>> delegate all responsibility for maintaining confidentiality across any hops to
>> the PT protocol in question. Does this help?
>> 
>> I’m still a bit confused; let me try to come at it from another angle:
>> 
>> The paragraph is labeled “End-to-End Confidentiality”.  The text delegates
>> this to transport protocol, and gives PT-TLS and PT-EAP as examples. In the
>> specific case of TLS: TLS does not normally offer “end-to-end” confidentiality,
>> rather it’s hop-by-hop. If there are intermediaries, TLS does not prevent
>> them from seeing the data.  Now, there are exceptions (e.g. HTTPS proxies).
>> And of course, if there are no intermediaries, then hop-by-hop becomes a
>> trivial case of end-to-end.
>> 
>> So I guess what I am asking is why TLS is listed as an example transport in a
>> paragraph about end-to-end confidentiality? Perhaps the paragraph is just
>> about confidentiality in general? Or there are other aspects of the
>> architecture that make TLS effectively end-to-end?
>> 
>> 
>> 
>>> 
>>> Thanks again for the clarifications. Hopefully the new draft (-04) will
>> address those remaining concerns.
>>> 
>>> Charles
>>> 
>>>> -----Original Message-----
>>>> From: sacm [mailto:[e-mail]] On Behalf Of Ben Campbell
>>>> Sent: Thursday, March 01, 2018 9:19 PM
>>>> To: Schmidt, Charles M. <[e-mail]>
>>>> Cc: [e-mail]; Karen O'Donoghue <[e-mail]>; The
>>>> IESG <[e-mail]>; [e-mail]; draft-ietf-sacm-nea-swima-
>>>> [e-mail]
>>>> Subject: Re: [sacm] Ben Campbell's Discuss on draft-ietf-sacm-nea-swima-
>>>> patnc-02: (with DISCUSS and COMMENT)
>>>> 
>>>> 
>>>> 
>>>>> On Feb 24, 2018, at 1:01 AM, Schmidt, Charles M.
>> <[e-mail]>
>>>> wrote:
>>>>> 
>>>>> Hello,
>>>>> 
>>>>> Thanks a bunch for your feedback. In general I agree with your
>> comments
>>>> and made changes to address them. Some quick clarifications:
>>>>> 
>>>>>> §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?)
>>>>> 
>>>>> 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.
>>>> 
>>>> I think what is confusing me is the “title” of the non-requirement is “End
>> to
>>>> End confidentiality”. I admit to not knowing the sacm work well enought
>> to
>>>> know what the “ends” are, but am I correct to assume that PT-TLS, like
>> most
>>>> uses of TLS, is hop-by-hop? Does the data every cross more than one
>> hop? Is
>>>> the answer the dame for PT-EAP?
>>>> 
>>>> 
>>>> 
>>>>> 
>>>>>> §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?
>>>>> 
>>>>> 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.
>>>>> 
>>>> 
>>>> Okay; I think the mentioned clarifying text would help.
>>>> 
>>>> 
>>>>>> §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?
>>>>> 
>>>>> 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.
>>>> 
>>>> Okay.
>>>> 
>>>>> 
>>>>>> §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?
>>>>> 
>>>>> 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.
>>>> 
>>>> Typically they are the last three “substantive” sections in the main body of
>> an
>>>> RFC, not counting any appendices or “acknowledgements” type sections. I
>>>> don’t think we are consistent in the order among those three.
>>>> 
>>>> Thanks!
>>>> 
>>>> Ben.
>>>> 
>>>>> 
>>>>> Thanks a bunch,
>>>>> Charles
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Ben Campbell [mailto:[e-mail]]
>>>>>> Sent: Wednesday, February 21, 2018 9:10 PM
>>>>>> To: The IESG <[e-mail]>
>>>>>> Cc: [e-mail]; [e-mail]; Karen
>>>>>> O'Donoghue <[e-mail]>; [e-mail];
>>>>>> [e-mail]; [e-mail]
>>>>>> Subject: Ben Campbell's Discuss on draft-ietf-sacm-nea-swima-patnc-
>> 02:
>>>>>> (with DISCUSS and COMMENT)
>>>>>> 
>>>>>> 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?
>>>>>> 
>>>>>> 
>>>>> 
>>> 
>