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

"Roman D. Danyliw" <rdd@cert.org> Mon, 20 June 2016 14:21 UTC

Return-Path: <rdd@cert.org>
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 6D4A612D0DD; Mon, 20 Jun 2016 07:21:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
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 pUgqFkV4KocG; Mon, 20 Jun 2016 07:21:38 -0700 (PDT)
Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B62E12D113; Mon, 20 Jun 2016 07:21:38 -0700 (PDT)
Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1543) with ESMTP id u5KELb88025354; Mon, 20 Jun 2016 10:21:37 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1466432497; bh=TCrX4etbnuGhSdLa0Cxm3g/aNAsefcAxGXcIW1XKa1Y=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To; b=YuQ8uuht4GPpc+qqZnJpuu9vWowxBOP0NV+MRjRZSi73bnrI6LNQBZ1I74D3BkTUv 5KfuMmUH8NSyPuPQ2cf5+M1zuME5KNweEN65sbYUsZeZu0WCB5PS0T54YHjAaHljw8 pgpGhwlnxLfKdfKrJ2RJ1eNrFxqNjSk7KriaqrUo=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by timber.sei.cmu.edu (8.14.4/8.14.4/1543) with ESMTP id u5KELbeB004373; Mon, 20 Jun 2016 10:21:37 -0400
Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0279.002; Mon, 20 Jun 2016 10:21:36 -0400
From: "Roman D. Danyliw" <rdd@cert.org>
To: Alexey Melnikov <alexey.melnikov@isode.com>, Robert Sparks <rjsparks@nostrum.com>
Thread-Topic: [mile] Secdir review: draft-ietf-mile-5070-bis-22
Thread-Index: AQHRuqVpyhJwvFfMKk6M7OkSPkYlWZ/VizoAgACacYD///tLAIAAWNWAgBwMt4A=
Date: Mon, 20 Jun 2016 14:21:36 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFCD976680D@marathon>
References: <15b7d5f0-63e9-15b9-b7d5-47a6be10c760@nostrum.com> <359EC4B99E040048A7131E0F4E113AFCD974F81A@marathon> <574FF391.6000806@isode.com> <359EC4B99E040048A7131E0F4E113AFCD9750115@marathon> <1464875555.1299466.625917257.2D46286E@webmail.messagingengine.com>
In-Reply-To: <1464875555.1299466.625917257.2D46286E@webmail.messagingengine.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.22.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mile/cz8_ZoyVYZX88QUoqeEgZQFUrYE>
Cc: "mile@ietf.org" <mile@ietf.org>, "draft-ietf-mile-rfc5070-bis.all@ietf.org" <draft-ietf-mile-rfc5070-bis.all@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
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: Mon, 20 Jun 2016 14:21:40 -0000

Hello!

> -----Original Message-----
> From: Alexey Melnikov [mailto:alexey.melnikov@isode.com]
> Sent: Thursday, June 02, 2016 9:53 AM
> To: Roman D. Danyliw <rdd@cert.org>;; Robert Sparks
> <rjsparks@nostrum.com>;
> Cc: mile@ietf.org; draft-ietf-mile-rfc5070-bis.all@ietf.org; iesg@ietf.org;
> secdir@ietf.org
> Subject: Re: [mile] Secdir review: draft-ietf-mile-5070-bis-22
> 
> Hi,
> 
> On Thu, Jun 2, 2016, at 01:49 PM, Roman D. Danyliw wrote:
> > Hi Alexey!
> >
> > > -----Original Message-----
> > > From: Alexey Melnikov [mailto:alexey.melnikov@isode.com]
> > > Sent: Thursday, June 02, 2016 4:51 AM
> > > To: Roman D. Danyliw <rdd@cert.org>;; Robert Sparks
> > > <rjsparks@nostrum.com>;
> > > Cc: mile@ietf.org; draft-ietf-mile-rfc5070-bis.all@ietf.org;
> > > iesg@ietf.org; secdir@ietf.org
> > > Subject: Re: [mile] Secdir review: draft-ietf-mile-5070-bis-22
> > >
> > > 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
> >
> > [snip]
> >
> > > > 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.)
> >
> > Understood.  Thanks for channeling the historical wisdom.
> >
> > > 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).
> >
> > What about language like the following in Section 4.3:
> >
> > ---[ begin Section 4.3]---
> >
> > -- Therefore, the schema to validate a given document MUST
> > -- be dynamically generated from these registry values.
> > ++ Therefore, IODEF implementations MUST periodically update their
> > ++ schema and MAY need to update their parsing algorithms to
> > ++ incorporate newly registered values added to the IANA registries
> > ++ specified in Section xx.
> 
> I think this is an improvement. But also see Kathleen's reply.

The following is the updated text in -23:

4.3.  Validation

   IODEF documents MUST be well-formed XML.  It is RECOMMENDED that
   recipients validate the document against the schema described in
   Section 8.  ...  These MUST also
   be considered by an IODEF implementation.  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, IODEF
   implementations MUST periodically update their schema and MAY need to
   update their parsing algorithms to incorporate newly registered
   values.

> > ---[ end Section 4.3 ]---
> >
> > In addition, add text to the security considerations that this
> > updating needs to be done securely.

The following text was added in -23:

9.1.  Security
[snip]
   Per Section 4.3, IODEF implementations will need to periodically
   consult the IANA registries specified in Section 10.2 to discover
   newly registered enumerated attribute values.  These implementations
   MUST communicate with IANA in a way that ensures the integrity of the
   values and the authenticity of the source.  HTTPS over TLS
   [RFC2818][RFC5246] provides such security.