Re: [secdir] Secdir review: draft-ietf-mile-rfc5070-bis-22
Robert Sparks <rjsparks@nostrum.com> Wed, 01 June 2016 13:32 UTC
Return-Path: <rjsparks@nostrum.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E58612D1B5; Wed, 1 Jun 2016 06:32:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIxMuX-4lesK; Wed, 1 Jun 2016 06:32:18 -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 D6E0D12D501; Wed, 1 Jun 2016 06:32:17 -0700 (PDT)
Received: from unnumerable.local (inet-141-146-6-188.oracle.com [137.254.4.60]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u51DWEvH071338 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Wed, 1 Jun 2016 08:32:15 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host inet-141-146-6-188.oracle.com [137.254.4.60] 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
References: <15b7d5f0-63e9-15b9-b7d5-47a6be10c760@nostrum.com>
From: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <c85e0bbe-d3f1-bee0-0eac-84a455071a51@nostrum.com>
Date: Wed, 01 Jun 2016 09:32:09 -0400
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
In-Reply-To: <15b7d5f0-63e9-15b9-b7d5-47a6be10c760@nostrum.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/8vV9Hg7rm3epQ6f8MEwMFjsG_sw>
Subject: Re: [secdir] Secdir review: draft-ietf-mile-rfc5070-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: Wed, 01 Jun 2016 13:32:30 -0000
Retransmitting to fix a typo in the Subject to make this easier to find when searching on the draft name. Apologies for the extra noise. On 5/30/16 2:43 PM, Robert Sparks wrote: > 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. >
- Re: [secdir] [mile] Secdir review: draft-ietf-mil… Roman D. Danyliw
- Re: [secdir] [mile] Secdir review: draft-ietf-mil… Roman D. Danyliw
- Re: [secdir] Secdir review: draft-ietf-mile-5070-… Roman D. Danyliw
- [secdir] Secdir review: draft-ietf-mile-5070-bis-… Robert Sparks
- Re: [secdir] Secdir review: draft-ietf-mile-rfc50… Robert Sparks
- Re: [secdir] Secdir review: draft-ietf-mile-rfc50… kathleen.moriarty.ietf
- Re: [secdir] Secdir review: draft-ietf-mile-5070-… Roman D. Danyliw
- Re: [secdir] [mile] Secdir review: draft-ietf-mil… Alexey Melnikov
- Re: [secdir] [mile] Secdir review: draft-ietf-mil… Roman D. Danyliw
- Re: [secdir] [mile] Secdir review: draft-ietf-mil… kathleen.moriarty.ietf
- Re: [secdir] [mile] Secdir review: draft-ietf-mil… Alexey Melnikov