Re: [mile] Stephen Farrell's Discuss on draft-ietf-mile-rfc5070-bis-22: (with DISCUSS and COMMENT)

["Roman D. Danyliw" <[e-mail]>]

Hi Stephen!

> -----Original Message-----
> From: Stephen Farrell [mailto:[e-mail]]
> Sent: Thursday, June 02, 2016 11:54 AM
> To: Roman D. Danyliw <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]; mile-
> [e-mail]
> Subject: Re: Stephen Farrell's Discuss on draft-ietf-mile-rfc5070-bis-22: (with
> DISCUSS and COMMENT)
> 
> 
> Hiya,
> 
> On 02/06/16 04:36, Roman D. Danyliw wrote:
> > Hello Stephen!
> >
> > Thanks for the review.  A response to the DISCUSS and COMMENTs is
> > inline ...
> >
> >> -----Original Message----- From: Stephen Farrell
> >> [mailto:[e-mail]] Sent: Wednesday, June 1, 2016
> >> 7:42 PM To: The IESG <[e-mail]> Cc:
> >> [e-mail]; Roman D. Danyliw
> >> <[e-mail]>; [e-mail]; [e-mail];
> >> [e-mail]; [e-mail]; [e-mail]
> >> Subject: Stephen Farrell's Discuss on
> >> draft-ietf-mile-rfc5070-bis-22: (with DISCUSS and COMMENT)
> >
> > [snip]
> >
> >> ----------------------------------------------------------------------
> >>
> >>
> DISCUSS:
> >> ----------------------------------------------------------------------
> >>
> >>
> >>
> (1) 3.6: Does one confidence value apply to all of these?
> >> That seems wrong. And over-confidence is attributing threat actor
> >> identity is a real issue with real consequences, hence the discuss
> >> to make sure we bottom out on this. I think it's just too
> >> error-prone to be ablve to associate one confidence value with two
> >> things about which one can have very different concreteness. Mixing
> >> up high confidence in a campaign with a lack of confidence in
> >> threat actor identification is precisely the kind of thing that
> >> goes wrong, or that could be deliberately manipulated (for
> >> eventual media/marketing reasons). (This overlaps with but isn't
> >> quite the same as Alissa's 2nd discuss point. In this case, I'm
> >> explicitly worried about the threat actor identity confidence, as
> >> that has possibly severe impacts, so the resolution here could
> >> differ from what results from Alissa's discuss.)
> >
> > The RelatedActivity class (Section 3.6) does have the ability to
> > provide a single confidence value on all of the child classes in it.
> > Per your example, yes, a single confidence value could be made both
> > on the campaign and the actor.  However, if more granularity was
> > desired, one can express different confidence values for both the
> > campaign and actor as follows (ThreatActor with low confidence but
> > the Campaign with high confidence):
> >
> > <Incident ...> ... <RelatedActivity> <ThreatActor>...</ThreatActor>
> > <Confidence rating="low" /> </RelatedActivity> <RelatedActivity>
> > <Campaign>...</Campaign> <Confidence rating="high"/>
> > </RelatedActivity> </Incident>
> 
> Right, it's clear one can do the right thing, but it's not clear
> what semantics apply when one does not do that. You could address
> that in various ways, but I think in particular for the confidence/
> threat-actor combination, the draft does need to say how to interpret
> whatever the document contains.

The following was added to the Security Considerations of -23 to explicitly call out that confidence assessment should not necessarily be trusted.

9.1.  Security
[snip]
   An IODEF implementation may act on the data in the document.  These
   actions might be explicitly requested in the document or the result
   of analytical logic that triggered on data in the document.  ...

  The recipient may
   interpret the contents of the document differently based on who sent
   it; or vary actions based on the sender.  While the sender of the
   document may explicitly convey confidence in the data in a granular
   way using the Confidence class, the recipient is free to ignore or
   refine this information to make its own assessment.

   Certain classes may require out-of-band coordination to agree upon
   their semantics (e.g., Confidence@rating="low" or DefinedCOA).  This
   coordination MUST occur prior to operational data exchange to prevent
   the incorrect interpretation of these select data elements.  When
   parsing these data elements, implementations should validate, when
   possible, that they conform to the agreed upon semantics.  These
   semantics may need to be periodically reevaluated.

> >> (2) 3.18.1 - you provide a way to specify e.g. an address and
> >> netmask, or v6 prefix. But you don't specify any way to say that
> >> some of the address (or prefix) bits are not real or are
> >> additionally masked for privacy reasons. E.g. If everyone in
> >> 2001:1:1:beef::/64 is misbehaving, but I don't (yet) want to
> >> specify the exact prefix, I might want to say " some
> >> 2001:1:1:xxxx::/64" is misbehaving, meaning one /64 in
> >> 2001:1:1::/48 is being bad and not the entire /48. Why is support
> >> for that not required?  (IPFIX does have that as an option, and
> >> it's been added to CDNI too.) Same idea can apply to other address
> >> forms too.
> >
> > Makes sense.  A few new Address@category enumerated value can be
> > created, say "ipv6-net-sanitized" and "ipv4-net-sanitized" where "x"
> > has the significance of masking bits in an otherwise valid
> > address/prefix.
> 
> So I think supporting something like that would be a good thing. If
> the WG consider it but decide to not add it, I'll just clear.

The following was added to -23 to provide comparable capability:

3.18.1.  Address Class
[snip]
      6.   ipv4-net-masked.  A sanitized IPv4 address with significant
           bits per "ipv4-net" but with the character 'x' replacing any
           digit(s) in the address or prefix.
[snip]
      10.  ipv6-net-masked.  A sanitized IPv6 address and prefix per
           "ipv6-net" but with the character 'x' replacing any
           hexadecimal digit(s) in the address or digit(s) in the
           prefix.

> >> ----------------------------------------------------------------------
> >>
> >>
> COMMENT:
> >> ----------------------------------------------------------------------
> >>
> >>
> >>
> >>
> - My review is based on [1]
> >> [1]
> >> https://tools.ietf.org/rfcdiff?url1=rfc5070&url2=draft-ietf-mile-rfc5070-
> bis-22
> >>
> >>
> >>
> - "cyber" galore - yuk! Which of the fourteen (14!) uses of that ill-defined
> >> marketing term are useful or even well defined?  RFC5070 had zero
> >> uses of such terms. Why is it a good plan for us to damage the RFC
> >> series via the use of such marketing nonsense? Someone may answer
> >> that this is accepted in industry these days, and that is true, but
> >> is nonetheless not a good enough reason for us to assist with the
> >> promulgation of anti-scientific non-concepts. My suggestion is to
> >> try s/cyber//g and then to see what if anything is less clear -
> >> perhaps we'll find that things are more clear. (And yes, it's a bit
> >> of a bugbear of mine:-) The use of "cyber indicator" instead of
> >> just "indicator" in 3.19 is a good example of how that phrase makes
> >> the spec less clear.
> >
> > Alissa commented on the same thing.  Please see my response there
> > (https://www.ietf.org/mail-archive/web/mile/current/msg01886.html).
> > Long story short, IMO, there are a few instances where cyber is the
> > appropriate adjective (e.g., a "cyber-physical system").

This was cleaned up in -23.

[snip]

> >> - 2.8: So you don't like leap-seconds? It's often good to be clear
> >> if that bit of ABNF is expected to be enforced along with schema
> >> validation or not.
> >
> > As currently specified, if the schema is validated, this regex will
> > be enforced.  It's baked into the schema with the iodef:TimezoneType.
> > Whether the schema should be validated is a separate issue that you
> > also brought up in another COMMENT (see below).
> 
> That's fine - what about leap seconds?

The regex in -23 was updated to be:

    <xs:simpleType name="TimezoneType">
      <xs:restriction base="xs:string">
        <xs:pattern
         value="Z|[\+\-](0[0-9]|1[0-4]):[0-5][0-9](:[0-5][0-9])?"/>

> 
> The rest below is fine,
> Cheers,
> S.
> 
> >
> >> - 2.12: What about EAI?
> >
> > Good point.  I'll change the reference to RFC5336.

The text in -23 now reads:

2.12.  Email String

   An email address is represented in the information model by the EMAIL
   data type.  The format of the EMAIL data type is documented in
   Section 3.4.1 of [RFC5322] and Section 3.3 of [RFC6531].

> >> - 3.13.1 - is CoA expanded somewhere? (See, I just looked at the
> >> diff:-)
> >
> > The write-up of the class in 3.13.1 says "DefinedCOA = Zero or more.
> > STRING.  An identifier meaningful to the sender and recipient of this
> > document that references a course of action."  I can make that
> > clearer by saying "... references a course of action (COA)".

The text in -23 now reads:

   DefinedCOA
      Zero or more.  STRING.  An identifier meaningful to the sender and
      recipient of this document that references a course of action
      (COA).  This class MUST be present if the action attribute is set
      to "defined-coa".

> >> - 3.18.1 - I think it'd be good to refer to the RFC for wriing down
> >> IPv6 addresses and prefixes. I forget it's number though:-) And who
> >> uses ipv6- net-mask? Don't we all use prefixes?

The text in -23 now reads:

      8.   ipv6-addr.  IPv6 host address per Section 4 of [RFC5952].

      9.   ipv6-net.  IPv6 network address, slash, prefix per
           Section 2.3 of [RFC4291].

> > Ipv6-net-mask is a hold over form rfc5070.  I'll find the right
> > reference and drop it here.

Yes, it was a cut-and-paste from RFC5070.  Address@type="ipv6-net-mask" is now removed.

[snip]

> >> - 4.3 - I also think that recommending schema validation of input
> >> documents is a bad plan. (Even if that was already in 5070.)

Schema validation is now just RECOMMENDED per -23.  A full discussion as it relates to the security review is at:

https://mailarchive.ietf.org/arch/msg/mile/cz8_ZoyVYZX88QUoqeEgZQFUrYE

https://mailarchive.ietf.org/arch/msg/mile/uPHPtq_PvUvxKTP4jKA5x6_y2Jg

> > Robert Sparks security review
> > (https://www.ietf.org/mail-archive/web/mile/current/msg01869.html)
> > and Alexey's review hinted at this issue but in the context of
> > dynamically generated schemas.  I'll start the conversation on this
> > issue on that thread.

The discussion and changes made in -23 to address the concerns with dynamically generated schemas can be found at:

https://mailarchive.ietf.org/arch/msg/mile/cz8_ZoyVYZX88QUoqeEgZQFUrYE

[snip]

> >> - 9.1: you could not here the DoS and possible other attacks (e.g.
> >> spoofed .xsd files loaded over port 80) that follow on from on-line
> >> schema
> >
> > Good point.  If the underlying schema is to be dynamically generated,
> > there is an IANA-to-schema-generator channel to secure that should be
> > covered here.  This will need new text, the substance of which will
> > depend on the clarifying conversation that needs to happen on how
> > these dynamic updates should be handled.

These is addressed in the links to the security review in the previous item.

[snip]

Thank you for the detailed review.

Roman