Re: [mile] Secdir review: draft-ietf-mile-5070-bis-22

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

Hello Robert!

> -----Original Message-----
> From: Roman D. Danyliw [mailto:[e-mail]]
> Sent: Thursday, June 02, 2016 1:03 AM
> To: Robert Sparks <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: RE: Secdir review: draft-ietf-mile-5070-bis-22
> 
> Hello Robert!
> 
> Thanks again for this review.  Comments are inline ...
> 
> > -----Original Message-----
> > From: Robert Sparks [mailto:[e-mail]]
> > Sent: Monday, May 30, 2016 2:44 PM
> > To: [e-mail]; [e-mail];
> > [e-mail]
> > Subject: Secdir review: draft-ietf-mile-5070-bis-22
> >
> > I have reviewed this document as part of the security directorate's
> > ongoing effort to review all IETF documents being processed by the
> > IESG.  These comments were written primarily for the benefit of the
> > security area directors.  Document editors and WG chairs should treat
> > these comments just like any other last call comments.
> >
> > Document : draft-ietf-mile-rfc5070bis-22
> >
> > Summary: This document has minor issues that should be addressed
> > before publication as Proposed Standard
> >
> > This document defines a document format for exchanging information
> > between operational security teams. It points out standardized
> > mechanisms for transporting the documents (RFC6545 and RFC6546), to
> > provide confidentiality, integrity, and authenticity, but does not
> > restrict the use of the format to within those protocols.  Instead, it
> > provides a generic set of "Processing Considerations" in section 4,
> > which are augmented by the Security Considerations in section 9.
> >
> > There are some minor issues with this approach that should be
> > addressed before publication.

[snip]
 
> > 2) The document notes (in Section 9.1) that some fields in the
> > document format may contain executable content. It is not clear which
> > fields are being mentioned, or what _kind_ of executable content is
> > being carried. Explicitly calling out the fields that this document
> > defines at this point, and characterizing their content would help.
> > The precautions you might need to take against a regex are different
> > from those you would take against arbitrary bytecode the recipient might
> be asked to execute.
> 
> The areas of concern would be:
> 
> (1) any classes that can have "binary strings" per Section 2.5 since this would
> allow binary code to be embedded in the document.  The affected classes
> are those of type iodef:ExtensionType and RecordPattern;
> (2) the EmailMessage and EmailBody classes
> (3) the DetectionPattern class, as it could specify a machine readable
> configuration for a device or application
> (4) the URL class that could reference a location containing executable
> content
> (5) the AdditionalData class which contain pretty much anything
> 
> (1) - (4) are places in the data model where binary blobs or text scripts could
> be inserted by design.  With (5), this is a an extension on which there are no
> constraints.  Technically, executable content also be put into any of the
> classes but the parser is unlikely to read them as such.
> 
> Clarifying language referencing these classes can be added to the security
> considerations.

The updated text in -23 reads as follows:

9.1.  Security
[snip]
   Executable content of various forms could be embedded into the IODEF
   document directly or through an extension.  Implementation MUST
   handle this content with care to prevent unintentional automated
   execution.  The following classes are explicitly intended to
   represent content that might be executable:

   o  All classes of type iodef:ExtensionType and the RecordPattern
      class can represent arbitrary binary strings such as legitimate
      software programs or malware.

   o  The EmailMessage and EmailBody classes can represent email
      attachments that can contain arbitrary content.

   o  The DetectionPattern class could specify a machine-readable
      configuration that directs the execution of the corresponding
      tool.

> > 3) There are several fields that are characterized as "meaningful to
> > the sender and recipient". This implies that the document cannot be
> > interpreted outside some out-of-band prior arrangement defining the
> > context in which those fields are meaningful. The document should
> > explicitly mention the need for such prior arrangements in the
> > Security Consideration section, and note the danger of attempting to
> > interpret those fields if the ability to ensure the message falls
> > within that pre-arranged context is suspect. The existing text around
> > ensuring proper authentication of the sender and recipient is a start,
> > but is not sufficient. While considering the problems with
> > interpreting these fields in the wrong context, the document should
> > recognize the possibility that a given sender/recipient pair might
> > have _two different_ arrangements about what these fields mean,
> especially given the passage of sufficient time.
> 
> Agreed.  There needs to be language added to the security considerations to
> discuss profiling and out-of-band arrangements.  In scanning through the
> document, DefinedCOA, is one of those.  What are the other fields you
> caught?

The updated text in -23 reads as follows:

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.

> > Nits:
> >
> > A) Section 2.11 calls out to RFC4519 to defined the syntax of
> > telephone numbers.  The document calls out to E.123, which provides
> > guidelines for representing phone numbers but does not define a
> > rigorous format useful for a protocol field.  If it's important to
> > exchange phone numbers in an interoperable way, consider pointing to
> something with more structure.
> > Do you
> > want the string to conform to E.164?  Would it be useful to have
> > something as structured as a tel: URI?

The updated text in -23 reads as follows:

2.11.  Telephone Number

   A telephone number is represented in the information model by the
   PHONE data type.  The format of the PHONE data type is documented in
   [E.164].

   [E.164]    ITU Telecommunication Standardization Sector, "The
              International Public Telecommunication Numbering Plan",
              ITU-T Recommendation E.164 (02/05), February 2005.

> > B) Section 4.1 says a character encoding MUST be explicitly specified,
> > but then immediately shows an example of a document with no character
> > encoding...
> 
> Good point.  That will be fixed.  Upon further review, the example with no
> encoding also doesn't make sense given the MUST above in the text saying it
> always needs to be specified.  The two examples in this section are from
> RFC5070 but they don't align with the text updated in this draft.

The updated text in -23 reads as follows:

4.1.  Encoding

   Every IODEF document MUST begin with an XML declaration and MUST
   specify the XML version used.  The character encoding MUST also be
   explicitly specified.  UTF-8 [RFC3629] SHOULD be used unless UTF-16
   [RFC2781] is necessary.  Encodings other than UTF-8 and UTF-16 SHOULD
   NOT be used.  The IODEF conforms to all XML data encoding conventions
   and constraints.

   The XML declaration with UTF-8 character encoding will read as
   follows:

   <?xml version="1.0" encoding="UTF-8" ?>

> > C) (micronit) The use of [RFC-ENUM] as a reference number is distracting.
> > Please change the reference tag to [RFC7495].

The updated text in -23 reads as follows:

   [RFC7495]  Montville, A. and D. Black, "IODEF Enumeration Reference
              Format", RFC 7495, January 2015.

Thanks again for your detailed review.

Roman