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

Robert Sparks <> Wed, 01 June 2016 13:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1E58612D1B5; Wed, 1 Jun 2016 06:32:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mIxMuX-4lesK; Wed, 1 Jun 2016 06:32:18 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D6E0D12D501; Wed, 1 Jun 2016 06:32:17 -0700 (PDT)
Received: from unnumerable.local ( []) (authenticated bits=0) by (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
X-Authentication-Warning: Host [] claimed to be unnumerable.local
To: "" <>, "" <>,
References: <>
From: Robert Sparks <>
Message-ID: <>
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: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [secdir] Secdir review: draft-ietf-mile-rfc5070-bis-22
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.