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

kathleen.moriarty.ietf@gmail.com Thu, 02 June 2016 12:49 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: mile@ietfa.amsl.com
Delivered-To: mile@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D9512D6EF; Thu, 2 Jun 2016 05:49:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 0C-fFOs6LN4L; Thu, 2 Jun 2016 05:49:12 -0700 (PDT)
Received: from mail-qg0-x243.google.com (mail-qg0-x243.google.com [IPv6:2607:f8b0:400d:c04::243]) (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 AF9BF12D6D4; Thu, 2 Jun 2016 05:49:12 -0700 (PDT)
Received: by mail-qg0-x243.google.com with SMTP id l75so15834619qgd.3; Thu, 02 Jun 2016 05:49:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=LCNxForQ4vwR6Yzu4k+MuTf/4bOYhgKT2RqFyoKFr/Y=; b=GCm8PfCmfrF/KuRA5PITAFNgWIohyaOH/k7t15goPV7no8X2nWpP8z+nMQo8MBOdkV b2lL67QZprFSX4gQFXjnpxdZGBoKGfMMFrCmYY4VGJU+RkpL5q8NglESTU/Ao2wpiuRn kL+HudnIcQiV8PaLDVT25fyOUVdkxWjbzo7JPk7ls1C4ji2aNGdjznffDgJ63CXF6FkJ EyZxORM25quOEuyoS2x7hnKw0r4L5jYd/MWwAS65symx7DaKaNdFT4JluDoDV9SjOiJB GA2CswD0fdsqYmrWli8WcPiq4a9yw3plyAKk4Z8UNDzAWNiw5dUpPAz7sBIqPQdNooZz dGiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=LCNxForQ4vwR6Yzu4k+MuTf/4bOYhgKT2RqFyoKFr/Y=; b=DVfRX7KWiDMpnaDDgfXPxm5cP4hbGk4hP5+It0l0R0fjvpgneWJeHdVcPYXQgszjZg 973EQY+P0vCfaEpWeL0CX4HCMV1rp4ZpRQxi39n4BB5RpfUEBYKQ50or1D0SfsmOrSk9 8pACnjT7G6GoakFFNIYkT8bysw6VsI00h/7ZeY4xpstPm6HJiJQuxrRx6Gim7IGjEcQL tlJYMSesMCkfh0RyyvbHVxlLpvVdHghRy/2hWI8rZ0lmDfUfo/RFqkMfiKo4HRriCBnl IRHXwByM3szfXUE1HkFZ223rgP53gqkmAKjDa9/lmzY5PvFlK0GMRHmfB+DSTNwQ64Hi ifWw==
X-Gm-Message-State: ALyK8tIbmly0bqSS2rgDFGrowPilmh3dQyPkwlmGLXQM9O+moHDqhXjYa+JEJ3Dkg0ND5w==
X-Received: by 10.140.249.5 with SMTP id u5mr43325123qhc.24.1464871751699; Thu, 02 Jun 2016 05:49:11 -0700 (PDT)
Received: from [192.168.1.6] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id e50sm11053804qga.22.2016.06.02.05.49.11 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Jun 2016 05:49:11 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
From: kathleen.moriarty.ietf@gmail.com
Mime-Version: 1.0 (1.0)
Date: Thu, 2 Jun 2016 08:13:01 -0400
Message-Id: <BE4716FB-9630-4862-B688-704C3AD35178@gmail.com>
References: <15b7d5f0-63e9-15b9-b7d5-47a6be10c760@nostrum.com> <359EC4B99E040048A7131E0F4E113AFCD974F81A@marathon> <574FF391.6000806@isode.com>
In-Reply-To: <574FF391.6000806@isode.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
X-Mailer: iPhone Mail (12H143)
Archived-At: <http://mailarchive.ietf.org/arch/msg/mile/x_4VzdNN8jECGDQGRsYuScPr06Y>
Cc: "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-mile-rfc5070-bis.all@ietf.org" <draft-ietf-mile-rfc5070-bis.all@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "mile@ietf.org" <mile@ietf.org>, Robert Sparks <rjsparks@nostrum.com>
Subject: Re: [mile] Secdir review: draft-ietf-mile-5070-bis-22
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mile/>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Jun 2016 12:49:15 -0000

Hello,

Thanks Robert for the detailed and helpful review.  Inline 

Sent from my iPhone

> On Jun 2, 2016, at 4:51 AM, Alexey Melnikov <alexey.melnikov@isode.com>; wrote:
> 
> 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 [mailto:rjsparks@nostrum.com]
>>> Sent: Monday, May 30, 2016 2:44 PM
>>> To: secdir@ietf.org; iesg@ietf.org; draft-ietf-mile-rfc5070-bis.all@ietf.org
>>> 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 (https://www.ietf.org/mail-archive/web/mile/current/msg01885.html) against using validation and the security issues when checking the IANA registry; and that Alexey Melnikov has marked this issue as a DISCUSS (https://datatracker.ietf.org/doc/draft-ietf-mile-rfc5070-bis/ballot/).
>> 
>> 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.

Agreed, SHOULD is a bit stronger.

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

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 www.iana.org 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).

I like Alexey's suggestion as it would greatly reduce the hits to IANA and accomplish the same goal.

Best regards,
Kathleen 

> 
> Best Regards,
> Alexey