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

[Stephen Farrell <[e-mail]>]

Hiya,

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

On 20/06/16 16:34, Roman D. Danyliw wrote:
> 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.

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?

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

Lovely. I cleared that bit.

Cheers,
S.


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