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 23:18 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 CDF2712D125; Wed, 1 Jun 2016 16:18:25 -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 6vV_ZIxKNTzk; Wed, 1 Jun 2016 16:18:24 -0700 (PDT)
Received: from mail-pa0-x243.google.com (mail-pa0-x243.google.com [IPv6:2607:f8b0:400e:c03::243]) (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 D7DA012D0CE; Wed, 1 Jun 2016 16:18:23 -0700 (PDT)
Received: by mail-pa0-x243.google.com with SMTP id gp3so1592491pac.2; Wed, 01 Jun 2016 16:18:23 -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=a5ItmRjE/bnax6iPyf9BCcXFuqtVe6DwYdX328vN9RE=; b=IOHuk+7Mm7swVPudWraSNrMSHYJ3pr0e1z9BfAHlTBBn0uKpXNnQHN1n3H9Byt0fHb O0xuXKckzG8ZAT6bqsWgUmr2687jtVJQTJnRy3UPFipCKdD8lqyMCz4io21xjw1PPIOZ Eo+39Nejr+VHEc1pm1K6i6Ir8ERCsSrdlegVcF4qevQlWPRistIZI1pjBN8v6GCqClSS +oFLsPi+hDG4WeuWby5IKtY0NGi75HwRlHk9brJw7mK3dCKBudRKux5MABFSqBO65FKd dsioQGehZ0ax34wSgr4f4moB15FHP8xcOzr1QU1WYIItu9M7TLHiWuKX7ohkVr1zkuOf JQpQ==
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=a5ItmRjE/bnax6iPyf9BCcXFuqtVe6DwYdX328vN9RE=; b=OFdaatcjwxWCm8LAGdpy8O9LOY85AtK2LdtMqUXnDPT4abdYoERj9XCsoagK+HrKkW Ifx05mbXzhVb4K2kAJ6bQSuMFA8VO5GCtE5J9wyC1MerbU7WlmzZkfuBrSWq2jA2RlXV 7+xhnzWSAZKhy3ieVMwpcnmzIJ4umq3UKe+uU+czRCUrlDI7YN5/sa2TM8JtuJudgei9 CTXSxRBG7axNd1+jS+cml5XHxVWMHcYaZiZvNZR87T5wP5KMAw6qpCUvq246R1DxQnT5 71r1mUk3UfAizVO7/kW/hRsjtVZb7iuVcHPhmc+B8Exg5PoiLmwsvgEB8bqcpLqGKW4F tp0g==
X-Gm-Message-State: ALyK8tJKZZ+IS4pz45n6ouFvgpiYe8LcaEyOj4toO0lU1gdJ8BM1aaQaSd/ergO5uOGvZw==
X-Received: by 10.66.180.49 with SMTP id dl17mr850967pac.131.1464823103426; Wed, 01 Jun 2016 16:18:23 -0700 (PDT)
Received: from [10.16.65.15] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id 66sm50521756pfb.64.2016.06.01.16.18.22 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2016 16:18:22 -0700 (PDT)
References: <20160601152314.16196.25416.idtracker@ietfa.amsl.com> <e4f3422d-50ed-cdd0-aed4-00d4cdf14e40@gmail.com> <574F2A47.3060306@cs.tcd.ie>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Ben Campbell <ben@nostrum.com>, The IESG <iesg@ietf.org>
From: Jouni Korhonen <jouni.nospam@gmail.com>
Message-ID: <14db6b63-9e08-4fb9-b4bb-b04403889b2e@gmail.com>
Date: Wed, 1 Jun 2016 16:18:20 -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: <574F2A47.3060306@cs.tcd.ie>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/ttg1uaQcyrOT_rQbrx_x8ANzOZs>
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 23:18:26 -0000

Hi Stephen,

6/1/2016, 11:32 AM, Stephen Farrell kirjoitti:
>
> Thanks all for the discussion. I've one thing to add... as you
> may detect, it's a thing about which I'm not neutral:-)
>
> On 01/06/16 19:14, Jouni Korhonen wrote:
>>
>>> - 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.
>>
>> I believe tnon-repudiation is already covered by the requirement #2,
>> which says "..integrity, and data-origin authentication."
>
> I'll put a DISCUSS on this if anyone adds non-repudiation as
> a requirement! :-)

Bummer ;-)

> Non-repudiation is not a network service, even though it has been
> described as one for decades. (Blame the security addendum to the
> OSI reference model - afaik, that's where it started;-)
>
> If one wants to provide what was claimed to be provided by
> non-repudiation then one needs signed timestamps for pretty much
> everything (and with counter signing for algorithm changes) and
> distributed logs with signed events (and log integrity) for things
> that happen at all nodes, and much else. None of that is useful for
> Diameter and it therefore ought not be mentioned. Even were it
> claimed to be useful, one would need to define a whole bunch of
> new AVPs to try (but fail) to provide that fictional service.
>
> Jouni is IMO correct that data origin authentication and data
> integrity are the network security services that are relevant
> and that can be offered here.

Phew..

>
> All that said, this is likely just a terminology thing, since
> some people do still use the NR term when they mean integrity
> and DAO with signatures, but it is *really* not a good idea to
> add the NR term to the mix as it has distracted and misdirected
> folks for literally decades and going back to that would be a
> bad plan.

Okay, I'll clean non-repudiation away, since origin authentication and 
integrity protection is really meant here.

- Jouni


>
> Cheers,
> S.
>