IETF 91 MILE Notes November 10, 2014 ==[ Introduction ]== Presenter: Chairs (Alexey Melnikov and Takeshi Takahashi) Additional facilitator: Secretary (David Waltermire) Minutes: Roman Danyliw and Chris Inacio Slides: http://www.ietf.org/proceedings/91/slides/slides-91-mile-2.pdf The chairs provide status on working group milestones and draft status. ==========[ draft-ietf-mile-enum-reference ]== Presenter: David Black Draft: draft-ietf-mile-enum-reference-format-09 Slides:http://www.ietf.org/proceedings/91/slides/slides-91-mile-4.pdf David Black updated the working group on the draft status and discussed the two remaining issues. Slides: Q: (David Black) Should the IANA registry values of the draft redirect through a URL other locations for values? A: (Kathleen Moriarty) Not a good idea. A: (Paul Hoffman) Not a good idea. Q: (David Black) Does anyone think this is a good idea? A: no answer Q: (David Black) Should the enum draft update RFC 5070 or just be used for RFC 5070bis? A: no one in the room supported the back-port to RFC 5070 A: (David Waltermire) Should confirm this on the list ==========[ draft-ietf-mile-5070bis ]== Presenter: Roman Danyliw Draft: draft-ietf-mile-rfc5070-bis-10 Slides: http://www.ietf.org/proceedings/91/slides/slides-91-mile-1.pdf Roman Danyliw presenter on the updates to the draft and remaining issues to reach WGLC. As to the new IANA registries to support extensions: Q1: (Roman Danyliw) Should the sub-registries be under IODEF or explicitly use a v2 registry? Currently a new v2 registry is used. A: (Paul Hoffman) Since v1 and v2 aren't compatible, it would create confusion to use a v1 registry for v2 sub-registries Q2: (Roman Danyliw) Is the naming convention of registries acceptable? A: (Kathleen Moriarty) What do developers think? No response. Q3: (Roman Danyliw) Per previous working group direction, the "ext-value" attributes have been removed. Is everyone still comfortable with this change? A: (Takeshi Takahashi) Using IANA registries is fine, but maybe keep the "ext-" as well for organizations that won't create IANA entries A: (Chris Inacio) With IPFIX it hasn't been a problem to have registries but this spec has private element IDs as well A: (Alexey Melnikov) Let's add text that if an unknown element is seen it should be ignored A: (Roman Danyliw) Possible, but it would be a change to current rigid validation requirement A: (David Waltermire) How would implementers know it's time to update their schema. When they find an unknown value? A: (Paul Hoffman) IANA shouldn't have to tell implementers that there is an update A: (Kathleen Moriarty) CODEMATCH is an effort to address this issue as it sends updates out for RFC errata. It needs developers. A: (Paul Hoffman) We need to decide between push and pull. Pull is easier than push. An ATOM/RSS-like mechanism should be sufficient. A: (Roman Danyliw) Need to bring this discussion back to the mailing list. The group needs to revisit whether to (a) revert back to just the "ext-value" style of extensions; (b) keep the current IANA registry-only way; or (c) use both. If (b) or (c) are chosen, providing guidance on when the schema should be updated from IANA needs to be provided. Q4: (Roman Danyliw) Are the fields in the registry sufficient? A: No suggestions of new fields Q5: (Roman Danyliw) Is the allocation policy of expert review adequate? A: Various discussion between Alexey Melnikov and Kathleen Moriarty. Yes, this is adequate. A: (Alexey Melnikov) IANA will create a web page for reference for expert review if the group would also want "Specification Required". As to the redesign of HashData: Q1: (Roman Danyliw) Are the XMLSig classes appropriate? A: (Jim Shot) Use ds:CannonicalizationMethod for new HashData class even if it is just the identify method A: (Jim Shot) Use ds:CanonnicalizationMethod for new Signature class A: (David Waltermire) C14N is the most commonly use. He will send a note to the mailing list about common canonicalization methods Q2 (Paul Hoffman) Why have fuzzy hashes? A: (Roman Danyliw) Used to characterize malware A: (Paul Hoffman) Each fuzzy hash is tool version dependent. A: (Roman Danyliw) Indeed. That's why we have an Application class. A: (Roman Danyliw) Does the working group want to specify a better format than AdditionalData for fuzzy hashes? A: No one spoke up. The issue will be taken to the list. Q3: (Roman Danyliw) Is ds:X509Data sufficient to represent a certificate? A: No one raised concern Q4: (Roman Danyliw) Do we want to capture the type of a file? A: (Alexey Melnikov) This could be easily done with IANA's registry for Media Types A: (Roman Danyliw) Any concern with adding this to the spec? A: No one raised concern Q5: (Roman Danyliw) Currently FileData, WindowsRegistryData, and CertificateData can't be associated with a given System. Is that a problem? A: (David Waltermire) Can you clarify the use case A: (Roman Danyliw) For an incident report, you can't tell from what System the indicator was derived. A: The issue will be taken to the list As to the HashData@valid attribute: Q1: (Jim Shot) Why is it there? A: (Roman Danyliw) Not sure. A: (Jim Shot) Perhaps it should be removed A: (Chris Inacio) Might be useful in pDNS because capturing DNS signatures is expensive and wasteful A: (Paul Hoffman) It's an "invalid bit". Get rid of it. A: (David Waltermire) It was intended to convey that a certificate was found to be invalid. Concur to drop. A: A question as to whether to drop this attribute will be put on the list. As to the iodef:SoftwareType ... Q1: (Roman Danyliw) Last mailing list discussion on clarifying iodef:Software produced no result. What does the group want to do? A: (David Waltermire) Extensibility is key dimension. Consider just using swid and reference the ISO standard. Alternatively, redefine the class to be AdditionalData. A: (Adam Monteville) Reiterated the importance of extensibility A: Isn't swid support already in the spec? A: (Roman Danyliw) There is an attribute named "swid" but this comes from RFC5070 which just happened to use this name without reference to the ISO standard. A: (Takeshi Takahashi) IODEF-SCI can embed SWID and CPE as well, but the context is different; it is added under AdditionalData. If we need the data here, we could make a model here like the SCI draft does. As to the RelatedDNS class ... Q1: (Roman Danyliw) We need to decide if "dig output" is how we are going to describe a DNS record. A: (Paul Hoffman) I have an independent draft on a JSON format. A pointer will be sent to the list A: (David Waltermire) Can this be handled in SCI? A: (Takeshi Takahashi) It could support it by adding an entry to the IANA table. A: This issue will be taken to the list after a review of the related pointers can be made. ==========[ draft-ietf-mile-implementation ]== Presenter: Daisuke Miyamoto Draft: draft-ietf-mile-implementreport-00 Slides: http://www.ietf.org/proceedings/91/slides/slides-91-mile-3.pdf Daisuke Miyamoto presented on the updates to the draft specifically highlighting two new implementers -- Collaborative Incident Management System (NATO) and N6 (CERT Polska). Q: (Daisuke Miyamoto) Are there better categories than "Vendor"/"Proprietary" in Section 6 A: (David Waltermire) Is the issue open source vs. closed source? A: (Paul Hoffman) NATO implementation isn't proprietary since it uses RT