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

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

Hello Stephen!

> -----Original Message-----
> From: Stephen Farrell [mailto:[e-mail]]
> Sent: Thursday, June 23, 2016 2:44 PM
> 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,
> 
> 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.)

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

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

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

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