Last Call Review of draft-ietf-mile-rfc5070-bis-16
review-ietf-mile-rfc5070-bis-16-secdir-lc-sparks-2016-06-02-00
Request | Review of | draft-ietf-mile-rfc5070-bis |
---|---|---|
Requested revision | No specific revision (document currently at 26) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2016-05-31 | |
Requested | 2016-05-19 | |
Authors | Roman Danyliw | |
I-D last updated | 2016-06-02 | |
Completed reviews |
Secdir Last Call review of -16
by Robert Sparks
(diff)
|
|
Assignment | Reviewer | Robert Sparks |
State | Completed | |
Request | Last Call review on draft-ietf-mile-rfc5070-bis by Security Area Directorate Assigned | |
Reviewed revision | 16 (document currently at 26) | |
Result | Has issues | |
Completed | 2016-06-02 |
review-ietf-mile-rfc5070-bis-16-secdir-lc-sparks-2016-06-02-00
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. 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. 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. 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... C) (micronit) The use of [RFC-ENUM] as a reference number is distracting. Please change the reference tag to [RFC7495]. Note: I did _not_ verify that the schema was well formed or that it matched the prose.