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

[Stephen Farrell <[e-mail]>]

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.

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

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

That's fine - what about leap seconds?

The rest below is fine,
Cheers,
S.

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