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

Alexey Melnikov <> Thu, 02 June 2016 08:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C460B12D0F8; Thu, 2 Jun 2016 01:51:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.427
X-Spam-Status: No, score=-3.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Oi6Xt1WmF_16; Thu, 2 Jun 2016 01:51:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 25B5C12D5DD; Thu, 2 Jun 2016 01:51:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1464857510;; s=selector;; bh=aKrMg5vAaQQXCfEe+yHg8F9m+GoQNLU1Bfu7d0iqSF8=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=iboXYlbx5QPSa4VAB9hycllGi1RRIDb3UJyX6+oe6NxcnaGZp9E6ah7xM9aQjwzplk9ykR WL4PU22ESXKQGP2HP3mPYFeEhgryIcMk5zeBM55NJ9sGyLs97pKSYaRvTP5EhVSx4QWrsD tPA4UkWdVx08O8I3HDr/MZrN/U7zwzY=;
Received: from [] ( []) by (submission channel) via TCP with ESMTPSA id <>; Thu, 2 Jun 2016 09:51:49 +0100
To: "Roman D. Danyliw" <>, Robert Sparks <>
References: <> <359EC4B99E040048A7131E0F4E113AFCD974F81A@marathon>
From: Alexey Melnikov <>
Message-ID: <>
Date: Thu, 02 Jun 2016 09:51:29 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
In-Reply-To: <359EC4B99E040048A7131E0F4E113AFCD974F81A@marathon>
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc: "" <>, "" <>, "" <>, "" <>
Subject: Re: [secdir] [mile] Secdir review: draft-ietf-mile-5070-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: Thu, 02 Jun 2016 08:51:53 -0000

Hi Roman,

On 02/06/2016 06:03, Roman D. Danyliw wrote:
> Hello Robert!
> Thanks again for this review.  Comments are inline ...
>> -----Original Message-----
>> From: Robert Sparks []
>> Sent: Monday, May 30, 2016 2:44 PM
>> To:;;
>> 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 ( against using validation and the security issues when checking the IANA registry; and that Alexey Melnikov has marked this issue as a DISCUSS (
> 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.
I don't mind, but I can also live with SHOULD here.
>   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?
I have no idea about reasonable "xxx" values. This was never done 
before. (When it was suggested before IESG persuaded authors to change 
their documents.)

While talking to directly from devices/programs is 
tempting, it might be better if vendors periodically download new values 
from IANA and then devices/programs talk to vendor's websites (or use 
vendor's update mechanisms).

Best Regards,