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

Robert Sparks <rjsparks@nostrum.com> Mon, 30 May 2016 18:43 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id DA8A312D56F; Mon, 30 May 2016 11:43:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id mjpWMm6AdI-T; Mon, 30 May 2016 11:43:35 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B36312D56C; Mon, 30 May 2016 11:43:31 -0700 (PDT)
Received: from unnumerable.local ([]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u4UIhS50017211 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Mon, 30 May 2016 13:43:30 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [] claimed to be unnumerable.local
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, draft-ietf-mile-rfc5070-bis.all@ietf.org
From: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <15b7d5f0-63e9-15b9-b7d5-47a6be10c760@nostrum.com>
Date: Mon, 30 May 2016 13:43:39 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/KCsipWLgxS3DLLzE8s89h7Ir9qQ>
Subject: [secdir] Secdir review: draft-ietf-mile-5070-bis-22
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 May 2016 18:43:37 -0000

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

1) The document requires that implementations validate documents against the
schema, and reject any documents that fail validation.  In particular, 
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 
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 
schema from IANA registries at runtime.  Perhaps the ADs can provide 
to material generated from those discussions that the group can reference.
Otherwise, the threats need to be described in more detail, and the 
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 
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 
and recipient". This implies that the document cannot be interpreted outside
some out-of-band prior arrangement defining the context in which those 
are meaningful. The document should explicitly mention the need for such 
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 
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 
sender/recipient pair might have _two different_ arrangements about what 
fields mean, especially given the passage of sufficient time.


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