Minutes for MILE at IETF-91
minutes-91-mile-2

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