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

[Alexey Melnikov <[e-mail]>]

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

Best Regards,
Alexey