[Dime] AD Evaluation of draft-ietf-dime-rfc4006bis-06

Ben Campbell <ben@nostrum.com> Mon, 12 February 2018 23:33 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 8E3E21271FD; Mon, 12 Feb 2018 15:33:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 cN6icx-MlDKi; Mon, 12 Feb 2018 15:33:16 -0800 (PST)
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 852BF127076; Mon, 12 Feb 2018 15:33:13 -0800 (PST)
Received: from [10.0.1.105] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w1CNXCMr073647 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 12 Feb 2018 17:33:13 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.105]
From: Ben Campbell <ben@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_AE77D6FF-A20A-46A3-9E6C-35DCF4F8861D"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Message-Id: <3C03A895-53C5-44D9-905F-9DD5248D3675@nostrum.com>
Date: Mon, 12 Feb 2018 17:33:11 -0600
Cc: dime@ietf.org, ops-ads@ietf.org
To: draft-ietf-dime-rfc4006bis.all@ietf.org
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/4B9DfwMv2KGrxgajZWjXdcf688A>
Subject: [Dime] AD Evaluation of draft-ietf-dime-rfc4006bis-06
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 12 Feb 2018 23:33:18 -0000

Hi,

This is my AD Evaluation of draft-ietf-dime-rfc4006bis-06. Thanks for the work on this; it’s overall a good update. However, I have one major comment and a few minor or editorial comments. I’d like to discuss the major comment prior IETF last call. The rest can be handled along with any last call feedback.

Note that for all but the major comment, I mostly reviewed the diff from RFC 4006.

Thanks!

Ben.

—————————————

Major Comment:

I strongly suggest that you add more privacy considerations. I realize that it inherits its existing privacy considerations from RFC 4006, but that was published in 2005. The IETF’s focus on privacy has evolved considerably since then, and I think this draft will get objections during IESG review without adding some more.

I suggest the following:
— Create a “Privacy Considerations” section separate from the security considerations.
— Enumerate the AVPs that you think contain user identifiable information, persistent identifiers, or other privacy sensitive data.
— Make some non-normative recommendations concerning data minimization. That is, add a few sentences recommending that clients and servers avoid capturing and/or log personal information beyond that needed for the application's purpose.

Minor Comments:

-Section 12 and subsections: Please clarify that many of these elements were already registered by RF 4006, and are not being “re-registered” here. ( It’s perfectly okay to pull the registration information forward into the bis draft; it just needs clarification.) Also, please consider wether existing registrations should be updated to point to this document rather than 4006.

Appendices: Would any of the example flows benefit from including one or more of the new AVPs?

Editorial and Nits:

-Section 8.34: “ If the Final-Unit-Action AVP is set to RESTRICT_ACCESS or REDIRECT
and the classification of the restricted traffic cannot be expressed
using IPFilterRule, or different actions (e.g., QoS) than just
allowing QoS needs to be enforced traffic, … “

I have trouble parsing the sentence.

-14: "Even without any modification to the messages, an adversary can
   invite a security threat by eavesdropping, as the transactions contain private information about the user.
”
I suggest “ … an adversary can eavesdrop on transactions that contain privacy-sensitive imformation”