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

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

Hello!

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Thursday, June 02, 2016 8:13 AM
> To: Alexey Melnikov <[e-mail]>
> Cc: Roman D. Danyliw <[e-mail]>; Robert Sparks
> <[e-mail]>; [e-mail]; draft-ietf-mile-rfc5070-
> [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [mile] Secdir review: draft-ietf-mile-5070-bis-22
> 
> Hello,
> 
> Thanks Robert for the detailed and helpful review.  Inline
> 
> Sent from my iPhone
> 
> > On Jun 2, 2016, at 4:51 AM, Alexey Melnikov
> <[e-mail]> 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:[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
> >>>
> >>> 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.
> >>

The text in -23 was updated as follows:

5.2.  Extending Classes
[snip]
   4.  Implementations that encounter an unrecognized element, attribute
       or attribute value in a supported namespace SHOULD reject the
       document as a syntax error.

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

The text in -23 was updated as follows:

   5.  There are security and performance implications in requiring
       implementations to dynamically download schemas at run time.
       Therefore, implementations MUST 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.

Roman