Re: [Dime] Ben Campbell's No Objection on draft-ietf-dime-e2e-sec-req-04: (with COMMENT)

"Ben Campbell" <ben@nostrum.com> Wed, 01 June 2016 15:45 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3015B12D1C9; Wed, 1 Jun 2016 08:45:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level:
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
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 dhwQlTAOqV2q; Wed, 1 Jun 2016 08:45:23 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3446912D15F; Wed, 1 Jun 2016 08:45:20 -0700 (PDT)
Received: from [10.10.1.2] ([162.216.46.130]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u51FjHI0019212 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 1 Jun 2016 10:45:18 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [162.216.46.130] claimed to be [10.10.1.2]
From: "Ben Campbell" <ben@nostrum.com>
To: "The IESG" <iesg@ietf.org>
Date: Wed, 01 Jun 2016 11:45:16 -0400
Message-ID: <FA73220E-3AB4-4D9E-84AE-0B641FDD0456@nostrum.com>
In-Reply-To: <20160601152314.16196.25416.idtracker@ietfa.amsl.com>
References: <20160601152314.16196.25416.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
X-Mailer: MailMate (1.9.4r5234)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/AvCTVi8uO8sxphzZ5xx8gVVtZSk>
Cc: draft-ietf-dime-e2e-sec-req@ietf.org, dime@ietf.org, dime-chairs@ietf.org
Subject: Re: [Dime] Ben Campbell's No Objection on draft-ietf-dime-e2e-sec-req-04: (with COMMENT)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jun 2016 15:45:25 -0000

By the way, <kervin.pillay@oracle.com> bounces. Is there an updated address?

Ben.

On 1 Jun 2016, at 11:23, Ben Campbell wrote:

> Ben Campbell has entered the following ballot position for
> draft-ietf-dime-e2e-sec-req-04: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dime-e2e-sec-req/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Substantive:
>
> - I am concerned about the de-emphasis of privacy requirements. While
> there's a mention of confidentiality in Requirement 2, other text
> suggests that integrity is more important (implying privacy is less
> important). There are no privacy considerations. Finally, the  {AVP}k
> convention does not distinguish  hinders discussion about how the set of
> confidentiality-protected AVPs and integrity-protected AVPs might not be
> the same. [Note: I almost balloted DISCUSS over this point. I did not,
> because I don't want to force the working group to add requirements it
> doesn't believe in. But I'd like to see some discussion about this.]
>
> - The "middle to *" models may be useful, but they are not end-to-end.
> Given the focus on those models, I find the title of the draft to border
> on disinformation. The description in the introduction about protecting
> AVPs between "non-neighbor" nodes is more accurate.
>
> - I find it odd to find 2119 keywords in the "motivation" sections. I
> suspect that most of those are statements of fact. If some are really
> requirements, they should be presented as such.
>
> - 4: The listed advantages of the middle-middle model (and also
> middle-to-end and end-to-middle) seem to assume that the number of
> "middles" is smaller than the number of "ends". While this may be true,
> especially for clienty ends, it should probably be explicitly stated.
>
> -- "firewalling Diameter proxy" needs a definition or reference.
>
> - Requirement 1: Does this need discussion on deprecating algorithms when
> vulnerabilities become known?
>
> - Requirement 2: Please elaborate on backwards-compatibiltiy with
> existing applications. Is this intended to motivate the models with
> "middles"?
>
> - Requirement 7: This (along with some text in the introduction) implies
> that non-repudiation is a requirement. If so, that should be listed and
> elaborated as a requirement.
>
> Editorial and Nits:
>
>
> - 1, first paragraph: "mechanisms independent of Diameter (e.g., IPsec)
>    is used."
>
> s/is/are
>
> - Requirement 3: The last sentence seems to ask the reader to draw a
> conclusion that wall-clock time can be used for anti-replay protection.
> If that's the intent, please say so explicitly.