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 18:38 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 A3A6812D16C; Wed, 1 Jun 2016 11:38:01 -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=unavailable 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 zP1s1JRfqJ_J; Wed, 1 Jun 2016 11:37:54 -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 AF29E12D1E8; Wed, 1 Jun 2016 11:37:54 -0700 (PDT)
Received: from [10.10.1.2] ([162.216.46.76]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u51Ibkqn034317 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 1 Jun 2016 13:37:48 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [162.216.46.76] claimed to be [10.10.1.2]
From: "Ben Campbell" <ben@nostrum.com>
To: "Stephen Farrell" <stephen.farrell@cs.tcd.ie>
Date: Wed, 01 Jun 2016 14:37:46 -0400
Message-ID: <4DFB44FC-3130-4080-9EC6-5CA8E82A9691@nostrum.com>
In-Reply-To: <574F2A47.3060306@cs.tcd.ie>
References: <20160601152314.16196.25416.idtracker@ietfa.amsl.com> <e4f3422d-50ed-cdd0-aed4-00d4cdf14e40@gmail.com> <574F2A47.3060306@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.4r5234)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/JlMD4I0nhC4cQ9MRhaLRPpfZGN0>
Cc: dime-chairs@ietf.org, draft-ietf-dime-e2e-sec-req@ietf.org, dime@ietf.org, The IESG <iesg@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 18:38:01 -0000

I may not have been clear, but my concern was not that I though there 
should be a non-repudiation requirement. It was that the text seemed to 
have an implicit one, and if that was intended, it should be explicit.

I'm also perfectly happy for the draft to not have such a requirement 
(implicit or otherwise.)

Ben.

On 1 Jun 2016, at 14:32, Stephen Farrell wrote:

> 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! :-)
>
> 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.
>
> 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.
>
> Cheers,
> S.