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

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

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>

> (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.
 
> ----------------------------------------------------------------------
> 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").

> - 2.5.1, does base64 need a reference and aren't there multiple variants (url-
> encoded, etc, sorry for being vague - I have to look that stuff up afresh every
> time I need to write code to handle it;-)

You're right, there are base64 variants.  However, in this case the text is really specific of which variant to use -- the one used by xs:base64Binary per Section 3.2.16 of [W3C.SCHEMA.DTYPES].  Therefore, I think we are fine.

> - 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).

> - 2.12: What about EAI?

Good point.  I'll change the reference to RFC5336.

> - 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)".

> - 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?

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

> - 3.21 - the hash and signature data are underspecified.
> You could mean any of pgp, smime or dkim. Or you could mean this is just a
> crypto binary value and you don't care about semantics, just pattern
> matching.

Exactly.  This class is the place to drop the crypto blob of your choice.

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

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.

> - section 9: defining how to format privacy sensitive data means that this
> spec absolutely does introduce privacy issues.
> 
> - 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.

> - 9.2: Have there been any cases of people using IODEF for bad reasons? I
> mean that e.g. sending info about attacks or phish emails is good. But using
> this format to send information about tracking an individual for marketing
> purposes would be bad. Has the latter occurred though?  (Just wondering, I
> don't know.) validation.

I'm not aware of such use of IODEF (RFC5070) or this draft.

Roman