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

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

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.
> 
> 1) The document requires that implementations validate documents against
> the schema, and reject any documents that fail validation.  In particular,
> Section
> 5.2 Item 4 requires rejecting documents with an unrecognized element in a
> supported namespace as a syntax error. Section 4.3 requires
> implementations to
> ->dynamically generate the schema used for validation from IANA
> registries<-.
> Section 5.2 Item 5 calls out that this dynamic generation has security and
> performance implications, but does not describe them, and has a very vague
> "SHOULD NOT download schemas at runtime" to guard against them.  I seem
> to recall significant discussion in other contexts of the issues with generating
> schema from IANA registries at runtime.  Perhaps the ADs can provide
> pointers to material generated from those discussions that the group can
> reference.
> Otherwise, the threats need to be described in more detail, and the
> operational complexity of exercising these extension points (particularly
> given the requirement to reject documents that do not validate against the
> content of the
> registries) needs to be spelled out.

To this analysis, I'll also add Stephen Farrell's COMMENT (https://www.ietf.org/mail-archive/web/mile/current/msg01885.html) against using validation and the security issues when checking the IANA registry; and that Alexey Melnikov has marked this issue as a DISCUSS (https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/ballot/).

To the WG: 

Consideration #1
==============

---[ begin Item #4 of Section 5.2 ]---
   4.  Implementations that encounter an unrecognized element in a
       supported namespace MUST reject the document as a syntax error.
---[ end Item #4 of Section 5.2 ]---

** Do we want to weaken the validation requirement in Item #4 of Section 5.2 from MUST to MAY?

IMO, this is a straightforward change that will provide more flexibility for implementations to process even non-conforming documents. 

 One minor concern here is that this may now lead to non-standard extensions.

Consideration #2
==============
Item #5 of Section 5.2 cautions against dynamically regenerating the schema from registry values at run-time; but also from downloading the base schema then too.

---[ begin Item #5 of Section 5.2 ]---
   5.  There are security and performance implications in requiring
       implementations to dynamically download schemas at run time.
       Therefore, implementations SHOULD NOT download schemas at runtime
       unless the appropriate precautions are taken.  Implementations
       also need to contend with the potential of significant network
       and processing issues.
---[ end Item #5 of Section 5.2 ]---

** Do we want to strengthen the caution of not downloading the schema in real-time in Item #5 of Section 5.2 from SHOULD NOT to MUST NOT? 

IMO, yes.

Consideration #3
==============

As Robert suggests, minimally, there needs to be a discussion in the security considerations on how these new enum values will securely be added to the schema/parser.  However, the question remains, what guidance do we provide about how often the IANA registry should be checked.

---[ begin Section 4.3]---
   Furthermore, the
   enumerated values present in this document are a static list that
   will be incomplete over time as select attributes can be extended by
   a corresponding IANA registry per Section 10.2.  Therefore, the
   schema to validate a given document MUST be dynamically generated
   from these registry values.
---[ end Section 4.3 ]---

** Should we modify the last sentence as follows:

"Therefore, the schema to validate a given document MUST be periodically regenerated from these registry values.  It is RECOMMENDED that this SHOULD NOT occur more frequently than xxx"

Kathleen/Alexey/or any reader of this note: do you have a pointer to the prior discussion on dynamically generating a schema from an IANA registry referenced by Robert so that "xxx" can be populated?

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

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


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

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

Good point.  This will be fixed.

Roman