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

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 01 Jun 2016 16:41:50 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-mile-rfc5070-bis-22: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/

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

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

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

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

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

- 2.12: What about EAI?

- 3.13.1 - is CoA expanded somewhere? (See, I just looked
at the diff:-)

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

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

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

- 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

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

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Thu, 2 Jun 2016 03:36:00 +0000

Hello Stephen!

Thanks for the review.  A response to the DISCUSS and COMMENTs is inline ...

> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Wednesday, June 1, 2016 7:42 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; Roman D. Danyliw <[email-masked]>;
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Stephen Farrell's Discuss on draft-ietf-mile-rfc5070-bis-22: (with
> DISCUSS and COMMENT)

[snip]

> 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

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

> 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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 2 Jun 2016 16:53:46 +0100

Hiya,

On 02/06/16 04:36, Roman D. Danyliw wrote:
>> -----Original Message----- From: Stephen Farrell
>> [mailto:[email-masked]] Sent: Wednesday, June 1, 2016
>> 7:42 PM To: The IESG <[email-masked]> Cc:
>> [email-masked]; Roman D. Danyliw
>> <[email-masked]>; [email-masked]; [email-masked];
>> [email-masked]; [email-masked]; [email-masked] 
>> Subject: Stephen Farrell's Discuss on
>> draft-ietf-mile-rfc5070-bis-22: (with DISCUSS and COMMENT)
> 
> [snip]
> 
>> 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
> 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.

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

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

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Mon, 20 Jun 2016 15:34:43 +0000

Hi Stephen!

> Sent: Thursday, June 02, 2016 11:54 AM
> To: Roman D. Danyliw <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; mile-
> [email-masked]
> Subject: Re: Stephen Farrell's Discuss on draft-ietf-mile-rfc5070-bis-22: (with
> DISCUSS and COMMENT)
> 
> 
> Hiya,
> 

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.

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

> > appropriate adjective (e.g., a "cyber-physical system").

This was cleaned up in -23.

[snip]

> 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])?"/>

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

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

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

> > reference and drop it here.

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

[snip]

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

> > dynamically generated schemas.  I'll start the conversation on this

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]

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 22 Jun 2016 15:51:29 -0400

Hi Stephen,

Do the updates address your concerns?

Thanks!
Kathleen

-- 

Best regards,
Kathleen

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 23 Jun 2016 19:43:40 +0100

Hiya,

Sorry for being slow responding. See below for my belated
response:-)

>    semantics may need to be periodically reevaluated.

Hmm. I guess I'm still not convinced that that calls out the
problem I raised sufficiently clearly. I'll also be interested
in your response to Alissa's related discuss. (I think sorting
hers out properly will fix mine for sure though.)

TBH, I wonder if the right thing here is to say that documents
with ambiguous confidence elements MUST be treated as if the
confidence element were omitted.

Would that work?

>            hexadecimal digit(s) in the address or digit(s) in the

Lovely. I cleared that bit.

Cheers,
S.

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Fri, 24 Jun 2016 18:22:47 +0000

Hello Stephen!

> Sent: Thursday, June 23, 2016 2:44 PM
> > 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]

The changes made for Alissa's discuss is described here:

https://www.ietf.org/mail-archive/web/mile/current/msg01939.html

> confidence element were omitted.

Definitely.  Would this last sentence address your concern:

"... 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.  
[start new text]
Ambiguous Confidence elements in a document MUST be ignored by the recipient.
"

It's a restatement of your suggestion to match the existing style of the text.

Roman

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 24 Jun 2016 20:15:10 +0100

Hiya,

> It's a restatement of your suggestion to match the existing style of the text.

That'd work for me. I'd word it more like:

"Ambiguous Confidence elements (where it is unclear to which of a set
of other elements the Confidence element relates) in a document MUST be
ignored by the recipient."

I'd still clear on yours, but saying what we mean by ambiguous would I
think be better. I'm fine if you want to use more words to be even more
precise about that.

Cheers,
S.

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Fri, 24 Jun 2016 21:04:43 +0000

Hi Stephen!

> Sent: Friday, June 24, 2016 3:15 PM

-25 was just posted.  It includes the exact text above.

Thanks for your help in improving the draft.

Roman