Re: [secdir] SecDir review of draft-ietf-dime-app-design-guide-19

Jouni Korhonen <jouni.nospam@gmail.com> Wed, 18 September 2013 13:39 UTC

Return-Path: <jouni.nospam@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E00C11E82BE; Wed, 18 Sep 2013 06:39:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D10E-emxBb6N; Wed, 18 Sep 2013 06:39:11 -0700 (PDT)
Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) by ietfa.amsl.com (Postfix) with ESMTP id D142311E8287; Wed, 18 Sep 2013 06:39:09 -0700 (PDT)
Received: by mail-lb0-f171.google.com with SMTP id u14so6681624lbd.16 for <multiple recipients>; Wed, 18 Sep 2013 06:39:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4fr5zhZ3sS45YkTbQNA48JODgP0r3IGhcoDz+55KWao=; b=Ro1/g54fl+fLFni6l/vaXiQrz6MncVEn79a1jwTsOIRvXEeDhCUHywOiIq4HKH5D5o ygXUTUlJ62Rg7xPzx+sWZl5rxAdgVeYOhxC/wuwCD2oMw6fqaOGIjsOlJ8yrSGvEnmLE 0YIbNmLv5c07mwLrZr5O2IletivqrElQxU/oyJp773GsIpsIQ1YV5sa9j0u2ADV4/82Y ibHy+V214kZ3/+XavhYO1xb2x+uiObtZqc+st7OZHe4daSUpYzmg/rm/dmBdsakmyx5v NYbmzWV58P71BWxcEucGhvxu2yi1T7QQMTEww6BmIbCBwZuAIlmd0pczHwuPwqn8HPmh sHoQ==
X-Received: by 10.152.5.162 with SMTP id t2mr34802810lat.1.1379511548598; Wed, 18 Sep 2013 06:39:08 -0700 (PDT)
Received: from [10.37.20.54] ([77.95.242.69]) by mx.google.com with ESMTPSA id vx8sm1576409lbb.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Sep 2013 06:39:08 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen <jouni.nospam@gmail.com>
In-Reply-To: <6D79E5E4-BE74-4EDC-BAAC-E0A28FB0609E@checkpoint.com>
Date: Wed, 18 Sep 2013 16:38:56 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <2BC814F7-6863-4CD1-AE08-CEDB7F1F2575@gmail.com>
References: <6D79E5E4-BE74-4EDC-BAAC-E0A28FB0609E@checkpoint.com>
To: Yoav Nir <ynir@checkpoint.com>
X-Mailer: Apple Mail (2.1510)
Cc: "draft-ietf-dime-app-design-guide.all@tools.ietf.org" <draft-ietf-dime-app-design-guide.all@tools.ietf.org>, The IESG <iesg@ietf.org>, "<secdir@ietf.org>" <secdir@ietf.org>
Subject: Re: [secdir] SecDir review of draft-ietf-dime-app-design-guide-19
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Sep 2013 13:39:12 -0000

Thanks Yoav,

I'll make sure the authors provide enough reasoning if they intend keeping IKEv1 in the document.

We also try to figure out whether expanding security considerations on the points you mention would be justified within the context of this document.

- Jouni

On Sep 18, 2013, at 2:10 PM, Yoav Nir <ynir@checkpoint.com> wrote:

> Do not be alarmed.  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.
> 
> Summary: The document is ready for publication
> 
> This informational document provides guidance on extending Diameter applications and on creating new ones. It contains advice such as to re-use existing commands and AVPs, considerations for adding and deleting commands and AVPs, and accounting.
> 
> Section 5.11 talks about Diameter security mechanisms: (D)TLS or IPsec. Some might dislike that it still mentions IKEv1. I'm not sure why this section is necessary at all, as these security mechanisms apply to the base protocol rather than any particular extension.
> 
> There is a 2-page section dealing with registration considerations, but only a very short paragraph for security considerations. That section pretty much says that extensions may be related to security functionality, but the document does not give guidance on enhancing Diameter with respect to security. I agree that this is OK, and new security functionality should specify its own considerations. I do wonder, though, whether it makes sense to include advice about the content in new data and applications as it relates to security, specifically as it relates to data leakage or data aggregation or user privacy.
> 
> 
> Nit:
> 
> Second sentence in the security considerations section:
> OLD:
> Although such an extension may related to security functionality,
> NEW:
> Although such an extension may be related to security functionality,
> 
> Yoav