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

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

Hello Alissa,

> -----Original Message-----
> From: Roman D. Danyliw [mailto:[e-mail]]
> Sent: Wednesday, June 01, 2016 10:52 PM
> To: Alissa Cooper <[e-mail]>; The IESG <[e-mail]>

[snip]

> > -----Original Message-----
> > From: Alissa Cooper [mailto:[e-mail]]
> > Sent: Tuesday, May 31, 2016 7:24 PM
> > To: The IESG <[e-mail]>

[snip]

> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > The Confidence class as defined in 3.12.5 seems underspecified. It
> > does not specify a max value, so some implementations might use 1 as
> > the max while others might use 100.
> 
> Inherited from RFC5070, there are no ranges specified for a valid numeric
> confidence value.  This was an explicit design choice kept in this draft to
> preserve flexibility.  Acceptable ranges and how this value should be
> interpreted are handled out of band.  This approach is consistent with the
> overall design of the data model.  Consider that almost all of the classes in
> the data model are optional.  The minimal valid document, shown is Section
> 7.1, isn't useful.  Profiling between parties in a data sharing consortium will
> determine which optional-in-the-RFC classes should be mandatory-in-the-
> consortium.  This thinking extends to the semantics of classes like
> Confidence.
> 
> 
> > It's also hard to understand how a single confidence value is supposed
> > to be applied to elements with multiple fields, as in 3.12 and 3.29.
> > What do I do if I have high confidence in my estimate of SystemImpact
> > but low confidence in my estimate of MonetaryImpact?
> 
> If the child classes don't have the same Confidence, then each can be
> expressed in a distinct instance of the parent class.  For the high confidence
> SystemImpact but low confidence MonetaryImpact do the following (per
> Section 3.12):
> 
> <Incident ...>
> ...
>   <Assessment>
>      <SystemImpact>...</SystemImpact>
>      <Confidence rating="low" />
>   </Assessment>
>   <Assessment>
>      <MonetaryImpact>...</MonetaryImpact>
>      <Confidence rating="high"/>
>   </Assessment>
> </Incident>
> 
> This same approach doesn't apply to the Indicator class (Section 3.29).  There
> is no way to granularly express a different confidence for different child
> elements that compose the Indicator.  The value expressed in
> Indicator/Confidence is a reflection of the confidence in the totality of the
> information in that Indicator class.

The following text was added to the Security considerations in -23 to reiterate the need to negotiate certain values out of band.

9.1.  Security
[snip]
   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 Confidence class was added to IndicatorExpression in the -23 draft that will allow confidence to be set for Observable, IndicatorExpression, ObservableReference and IndicatorReference.

The following figure was added to Section 3.29.5 to clarify its use:

    1                          :    <IndicatorExpression operator="or">
    2                          :      <IndicatorExpression>
    3 [O1 with low confidence] :        <Observable>..</Observable>
    4                          :        <Confidence rating="low" />
    5                          :      </IndicatorExpression>
    6                          :      <IndicatorExpression>
    7 [O2 with high confidence]:        <Observable>..</Observable>
    8                          :        <Confidence rating="high" />
    9                          :      </IndicatorExpression>
   10                          :    </IndicatorExpression>

   Equivalent expression: ((O1) OR (O2))

          Figure 70: Varying confidence on particular Observables

> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > (1) Section 1: It would be useful to define "cyber," "cyber indicator"
> > (somewhere before 3.29), "cyber threat," and "cyber event." I chuckled
> > when I wrote that, but I'm serious. The term "cyber" did not appear in
> > RFC 5070. It has clearly taken on some (mythical, perhaps) meaning in
> > venues external to the IETF. I think if this document is going to use
> > the term, it needs to explain what it means. If there are some
> > external definitions to point to or adopt, that would be fine.
> 
> After a search, it would appear that "cyber" is used in the abstract, Section
> 1.0 (Introduction), 1.3 (About the IODEF Data Model), 3.12.1 (SystemImpact),
> 3.12.2 (BusinessImpact), 3.28 (IndicatorData) and 3.29 (Indicator) -- 14 times
> total.  That can be cleaned up.  Specifically:
> 
> ** Section 1.0 uses the term "cyber security event" once.  I'm going to
> assume that isn't controversial.
> ** Sections 3.12.1 and 3.12.2 use the term "cyber physical system" four
> times.  I'm going to assume this isn't controversial.
> ** s/cyber indicator/indicator/g will address four usages of "cyber"-as-an-
> adjective in the abstract; and Sections 1.0, 3.28 and 3.29
> ** s/cyber incident report/cybersecurity incident report/g will address one
> more usage of "cyber"-as-an-adjective in Section 1.0
> ** I'll reword "cyber threats" and "cyber event mitigation" in Section 1.0; and
> reevaluate the use of "cyber intelligence"

The use of cyber was cleaned up in -23.

> > (2) Section 3.19.2: If I want to list the admin contact for a
> > particular domain in a Contact element within a DomainContacts
> > element, do I set the role in the Contact to "admin" or to "zone"? I
> > think this is not entirely clear from how the roles are specified in
> > 3.9 since most of the roles are more generic than "zone."
> 
> I'd say "admin".  You're right about the lack of symmetry of "zone" relative to
> the others.  I'll dig through the mailing list to see if I can recollect why we
> have this value.  At first blush, I'd say delete it.

The "zone" value was deleted in -23 to eliminate confusion.

Thanks for the detailed review.

Roman