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

Jouni Korhonen <jouni.nospam@gmail.com> Wed, 01 June 2016 17:12 UTC

Return-Path: <jouni.nospam@gmail.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 7F9A812B04D; Wed, 1 Jun 2016 10:12:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 zaLXjmGmODYL; Wed, 1 Jun 2016 10:12:06 -0700 (PDT)
Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (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 E32B712B047; Wed, 1 Jun 2016 10:12:05 -0700 (PDT)
Received: by mail-pf0-x244.google.com with SMTP id 62so4591631pfd.3; Wed, 01 Jun 2016 10:12:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:subject:references:to:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=R9TcFr8D2RTsnve04Uh5eqoG506hBFjA75b2jal0IsU=; b=H4PC+aVGV12Th+gWsWUEG6t+RJkneLWYic3z4k8d9nnbTKpgTV9yruBasgfdNHpQaO iQIUglHKcAyXRm4RaepFYP8mdEoALWv7fBGk2IIx3nj4QeXpbSIYx95DPVRb/NqYLWb2 pubRzcj7HW3YqKrIq/m7dtY6K5MIl44G12cgJAtwI9rRCszy31GmH4gJKy05e2V4pDUG Z6I8ZQ8ZuuFmbDQYtDSuJYMX1nMz/iTdzNgrM1l3oLoeiniOcRq2sRKRX8gQ7MK863M9 V4dgqeNs+EIAO6Awg8at0dqKa7XQ0EkN9Z/6qdJsCVoywqTzmS2wQRbUr2eir6C95k30 IGLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=R9TcFr8D2RTsnve04Uh5eqoG506hBFjA75b2jal0IsU=; b=awebeybtbd8o64DuqxFLExm/rCyhkrWyJwc6xGfhcT8Da10GtfgNYrg3hOwVzt4Rag mC3ivu2IP8zpkgdVk2OAMixBzGvo7Eh7qbJv42DtY5HnYa1KZmnlZL2FnSCjTKhkBr1Y W30Cj2Y/UyUPb6yHToUbxKMPANZmgJavqY/uIwMNsuLYSLSlCflvsYvEHK38lgzkcxhJ R5SO7twRbsx2QLgvbA4tfngibiRysqOEFbrMaW/M5ce+shWEx8FRiroZrMucB8CTzAn4 On/8y8BlFCuRvmKah7klKub3LT3yMEDmyilFur9PhViKIZWOFwimx7RP4hRO5k8av+/C mrYg==
X-Gm-Message-State: ALyK8tKDYGt+lG/IqMCzAl7j1oV9HT0cX92S+XsQKkkqcV9Csge8qneGvfzEFk+07BmE8A==
X-Received: by 10.98.1.6 with SMTP id 6mr10709171pfb.155.1464801125407; Wed, 01 Jun 2016 10:12:05 -0700 (PDT)
Received: from [10.16.65.15] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id c15sm43611739pfj.65.2016.06.01.10.12.03 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2016 10:12:04 -0700 (PDT)
References: <20160601152314.16196.25416.idtracker@ietfa.amsl.com> <FA73220E-3AB4-4D9E-84AE-0B641FDD0456@nostrum.com>
To: Ben Campbell <ben@nostrum.com>, The IESG <iesg@ietf.org>
From: Jouni Korhonen <jouni.nospam@gmail.com>
Message-ID: <aa9dac7a-ffd5-0785-36e4-a23a4b23d867@gmail.com>
Date: Wed, 1 Jun 2016 10:12:02 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <FA73220E-3AB4-4D9E-84AE-0B641FDD0456@nostrum.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/YP443RIHtuqsdw8d6MjvQ3nLRQQ>
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
Reply-To: jouni.nospam@gmail.com
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 17:12:08 -0000

Kervin is not with Oracle anymore. I haven't managed to reach him yet.

- Jouni



6/1/2016, 8:45 AM, Ben Campbell kirjoitti:
> 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.