Re: [mile] Feedback on draft-banghart-mile-rolie-csirt-02

["Banghart, Stephen A. (Fed)" <[e-mail]>]

Roman,

Thanks for the review. Comments inline. Several of your points cover sections of the document that are being removed following the decision the group made at IETF100 to trim down the IODEF specific requirements. I'll have the newer version of the document with those changes posted soon.

> -----Original Message-----
> From: mile [mailto:[e-mail]] On Behalf Of Roman Danyliw
> Sent: Monday, November 20, 2017 11:23 AM
> To: [e-mail]
> Subject: [mile] Feedback on draft-banghart-mile-rolie-csirt-02
> 
> Hi Stephen and John!
> 
> >From my reading of draft-banghart-mile-rolie-csirt-02, I have the following
> feedback:
> 
> (1) Section 3, Additional Requirements for the Atom Publishing Protocol
> 
> ** Cite RFC5023 as the reference for Atom Publishing Protocol.
> 
> (2) Section 4,
> ** Cite RFC4287 as the reference for Atom Syndication Format.

Added reference to both of these, thanks.

> (3) Section 3.1.2, User Authorization
> 
> ** In the first sentence, I'd recommend replacing s/When the content model
> .../When the content for the Atom <content> element contains an <IODEF-
> Document>/ for readability.
> ** Also the first sentence states  "... the authorization MUST be adjudicated
> ... per Section 8.1.1".  What specific section in 8.1.1 is being referenced?  Is it
> @restriction?  Is it also worth noting that this adjudication will be done is
> outside the scope of the document -- some sites might treat
> @restriction="need-to-know" differently?
> ** <IODEF-Document> is mentioned but without citation.

Per discussion at IETF 100 this entire requirement has been removed as part of the process of removing IODEF specific restriction on the ROLIE protocol.

> (4) Section 4, Additonal Requirements for the Atom Syndication Format
> ** s/Additonal/Additional/ (typo in the Section title)
> 
> (5) Section 4.1, Additional Requirements for the atom:feed element
> ** s/Additonal/Additional/ (typo in the Section title)

Thanks for catching this, fixed.

> ** The first sentence states "A feed containing IODEF incident content MUST
> contain at least two additional <atom:category> elements."  What does it
> mean to contain "IODEF incident content"?  Is "IODEF incident content" an
> instance of an <IODEF-Document> whose includes at least one <Incident>?
> (6) Section 4.2, Additonal Requirements for the atom:entry element
> ** s/Additonal/Additional/ (typo in the Section title)
> ** The first sentence states "An entry containing an IODEF payload."  What
> does it mean to contain an "IODEF payload"?  Is it an instance of <IODEF-
> Document>?
> 
> (7) Section 4.3.1, The IODEF Document
> 
> ** s/<relatedActivity>/<RelatedActivity>/
> ** s/<history>/<History>/
> 
> (8) Section 5.1, "incident" information type
> 
> ** The fifth bullet uses the language "effect and result information", it might
> be clearer to refer to it as the "incident impact"

All of the above sections have been removed as IODEF specific requirements per IETF100.

> (9) Section 5.3.1, IODEF Format
> 
> ** Cite IODEF with an informative reference

Added.

> ** The last paragraph states that "The use of the IODEF format imposes
> additional requirements on the server."  Where are those requirement
> documented?

Removed this paragraph.

> (10) Section 5.3.2, STIX Format
> 
> ** Cite STIX with an informative reference

Trying to track down a good single reference for this. I suspect that Bret might be able to help us with this.

> 
> (11) Section 6.1, urn:ietf:params:rolie:property:csirt:ID
> 
> ** The first sentence states that csirt:ID "provides an exposure point for an
> identifier ...".  What is an "exposure point"?  Is that a unique reference?
> ** Also, the first sentence states "... identifier from the indicator or incident
> document".  What is an "indicator" or "incident document" in this content?

Rewrote this sentence to:
"Provides an XML element that can be populated with an identifier from the
                    indicator or incident document linked to by an
                    atom:content element."

This is in the context of being a rolie:property element, a general use key:value pairing defined in the ROLIE core.

> (12) Section 8.1.1, Newly registered category values
> ** The second sentence notes that "This IODEF content exposure provides
> ..."  What is meant by "content exposure"?
> ** The second and third paragraphs make references to Section 3.2 of IODEF.

I agree that the terminology "content exposure" isn't very intuitive. I'll think about the wording on this and redo it for the next version.

> Which IODEF -- RFC 5070 or 7970?
> ** I'd recommend removing the attribute value examples (i.e., "e.g, public,
> need-to-know, private, default", "e.g. traceback, mitigation, reporting, or
> other") as these may change with the extension values in the IANA registry
> (assuming RFC7970 is the version of IODEF in question).

We're intending to reference RFC7970. Thanks for the suggestion on the example values, I've removed them.

> (13) Section 10, Security Considerations
> 
> ** The first sentence states that this document is about "us[ing] ROLIE in
> high-security use cases".  I'm not sure what "high security" means in this
> context.
> ** In the same sentence, it says that "added care should be taken to fortify
> and secure ROLIE" -- like what?

I was trying to remain vague, to avoid prescribing actions for CSIRTs to take. With that said references to some of the specific technologies we call out in the ROLIE core document Security considerations would provide some good concrete examples of what "high security" is and how to secure it.

> ** Per the second sentence, I recommend:
> s/The guidance in the ROILE core specification ... is strongly
> recommended/The security and privacy considerations of the ROILE core
> specification [I-D.ietf-mile-roile] are applicable./

Changed.

> ** In the same sentence, it says that "implementers should consider adding
> additional security measures as they see fit" -- like what?

I'll add references to the methods we call out in the ROLIE core here as examples.

> ** The first sentence of the second paragraph references "closed sharing".
> I'm not sure what that means.

How about just "private consortium"? I'm trying to reference any security organization or a group of security organizations that are privately sharing information with eachother.



Thanks for the review, the document is shaping up,
Stephen

> Regards,
> Roman
> 
> _______________________________________________
> mile mailing list
> [e-mail]
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Fmailman%2Flistinfo%2Fmile&data=02%7C01%7Cstephen.banghar
> t%40nist.gov%7C6e5575bf4a4e44340d2008d53033106d%7C2ab5d82fd8fa4797
> a93e054655c61dec%7C1%7C0%7C636467918241204252&sdata=%2FKfhbkT5N
> vuBPE07VUZ3Y3JMJJHPMRMOM8FRqvY9cjc%3D&reserved=0