Re: [secdir] Secdir review: draft-ietf-mile-rfc5070-bis-22 Wed, 01 June 2016 14:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D421512D50A; Wed, 1 Jun 2016 07:07:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bBZDJVDEKiul; Wed, 1 Jun 2016 07:07:40 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F2F9D12D550; Wed, 1 Jun 2016 07:07:39 -0700 (PDT)
Received: by with SMTP id y126so15116385qke.1; Wed, 01 Jun 2016 07:07:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=woEwIpTA/NBkAJfe35IwBPRP0DUifUSPbC4fQFjZRLQ=; b=CY+CanVnWN6WnkLuQTJ4v7HbAGPo9atpb5TYcgh3LCvvi0EiGQrUSnxLudMgu4Z/4C FfAhFdNJLHxUH33XJ0PJk0m9TWULYg7TmGKYjoeNwoq9Ko6s85D69WKlBs281BalUsRH 9O2aa2u5eOYcaDuzY0USeeFnmfwVTLqy5QyO4UGPkPO8CDKfcPdUgTm/XXt2b2Ic+GSW u+rTTHupnP4oC2Auiob01qygIrSG9sCEw+d/Bm6t08jVVhW6darjVh13M5adZTGNAFac h/ahqgxzYB/aNSSHKXgbWesBlRE5xW9OwOvJQLWl4ZDjxn1piwCzBMEzkKiW9Qyt7E79 s7pA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=woEwIpTA/NBkAJfe35IwBPRP0DUifUSPbC4fQFjZRLQ=; b=JWYUPTEn/Ol2jLgjmhfySUuiwP1MUN9Cg627TNAlGzb99Vufq6Sjz3fiVRf0ytOAtC RRZt//oIA8jx9v6WfXRT+94mNy5rrFj/GIFsSpTLF4hRFwx3DgVxAzI4aveEaXrdk71U r9BkNNHMxvqWcsQpwK3JvHz3ClMBFGT6aNcXpX3hOw3r4h0u1mQCg2SSfEeQWmdDUmSY 5f2/WgrYrZylEL6CJBUdu7AcPMOq7t7LjRaOkA4LHcEKjRyff5s/v5vprl0dJfPt8Dzn xsD2+lNNxY4fnwJO1U2addpYj5NyYWVWRlsOBwhLL2kHZAkxgnA/LB+rAk7KFkz97snw AjWA==
X-Gm-Message-State: ALyK8tJI8x0c+CtTf9qwG46BwsysMgRrz9BCowPeQ7nMpQ8cUI/bWdj6WxZLi1cZB4T8ow==
X-Received: by with SMTP id l23mr3729346qtc.81.1464790058936; Wed, 01 Jun 2016 07:07:38 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id s7sm5672051qhe.46.2016. (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2016 07:07:38 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
X-Mailer: iPhone Mail (12H143)
In-Reply-To: <>
Date: Wed, 01 Jun 2016 10:07:37 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Robert Sparks <>
Archived-At: <>
Cc: "" <>, "" <>, "" <>
Subject: Re: [secdir] Secdir review: draft-ietf-mile-rfc5070-bis-22
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 Jun 2016 14:07:42 -0000

Thanks, Robert for the review and re sending it.

Sent from my iPhone

> On Jun 1, 2016, at 9:32 AM, Robert Sparks <> wrote:
> Retransmitting to fix a typo in the Subject to make this easier to find when searching on the draft name.
> Apologies for the extra noise.
>> On 5/30/16 2:43 PM, Robert Sparks wrote:
>> 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.
>> 2) The document notes (in Section 9.1) that some fields in the document format
>> may contain executable content. It is not clear which fields are being
>> mentioned, or what _kind_ of executable content is being carried. Explicitly
>> calling out the fields that this document defines at this point, and
>> characterizing their content would help. The precautions you might need to take
>> against a regex are different from those you would take against arbitrary
>> bytecode the recipient might be asked to execute.
>> 3) There are several fields that are characterized as "meaningful to the sender
>> and recipient". This implies that the document cannot be interpreted outside
>> some out-of-band prior arrangement defining the context in which those fields
>> are meaningful. The document should explicitly mention the need for such prior
>> arrangements in the Security Consideration section, and note the danger of
>> attempting to interpret those fields if the ability to ensure the message falls
>> within that pre-arranged context is suspect. The existing text around ensuring
>> proper authentication of the sender and recipient is a start, but is not
>> sufficient. While considering the problems with interpreting these fields in
>> the wrong context, the document should recognize the possibility that a given
>> sender/recipient pair might have _two different_ arrangements about what these
>> fields mean, especially given the passage of sufficient time.
>> Nits:
>> A) Section 2.11 calls out to RFC4519 to defined the syntax of telephone
>> numbers.  The document calls out to E.123, which provides guidelines for
>> representing phone numbers but does not define a rigorous format useful for a
>> protocol field.  If it's important to exchange phone numbers in an
>> interoperable way, consider pointing to something with more structure. Do you
>> want the string to conform to E.164?  Would it be useful to have something as
>> structured as a tel: URI?
>> B) Section 4.1 says a character encoding MUST be explicitly specified, but then
>> immediately shows an example of a document with no character encoding...
>> C) (micronit) The use of [RFC-ENUM] as a reference number is distracting.
>> Please change the reference tag to [RFC7495].
>> Note: I did _not_ verify that the schema was well formed or that it matched the
>> prose.