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

["Roman D. Danyliw" <[e-mail]>]

Hello!

> -----Original Message-----
> From: Alexey Melnikov [mailto:[e-mail]]
> Sent: Thursday, June 02, 2016 9:53 AM
> To: Roman D. Danyliw <[e-mail]>; Robert Sparks
> <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> 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:[e-mail]]
> > > Sent: Thursday, June 02, 2016 4:51 AM
> > > To: Roman D. Danyliw <[e-mail]>; Robert Sparks
> > > <[e-mail]>
> > > Cc: [e-mail]; [e-mail];
> > > [e-mail]; [e-mail]
> > > 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:[e-mail]]
> > > >> Sent: Monday, May 30, 2016 2:44 PM
> > > >> To: [e-mail]; [e-mail];
> > > >> [e-mail]
> > > >> 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.