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

Stephen Farrell <> Wed, 01 June 2016 18:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4EC2D12D18C; Wed, 1 Jun 2016 11:32:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.727
X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KxixpKwU8GvF; Wed, 1 Jun 2016 11:32:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BA83512D0D1; Wed, 1 Jun 2016 11:32:44 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id DA1A5BE35; Wed, 1 Jun 2016 19:32:41 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xJb5vOE2c6dF; Wed, 1 Jun 2016 19:32:40 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 02C5EBE32; Wed, 1 Jun 2016 19:32:39 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1464805960; bh=a35uFcYwXfZyIqSxIlPSnmdgO2aXfoIrUh3hZK+sU0o=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=bqSBMC/JyKu2QYYWU6Z/Osm+dRrp4a3GP7aJKyYBv0JeLA0+j7KSZrypDqpzGIT5U lGaowf/Nxn8VHnvL0bZy3mfuLgTDX6pTqdscf7VH48aWqCs1PdZzlf9IcFfzkzVBJN mJfEkjIQcGmGnaTJqzVGx7nlC8sxM4UzBTvE58b8=
To:, Ben Campbell <>, The IESG <>
References: <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Wed, 01 Jun 2016 19:32:39 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms070401060505070400000800"
Archived-At: <>
Subject: Re: [Dime] Ben Campbell's No Objection on draft-ietf-dime-e2e-sec-req-04: (with COMMENT)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 Jun 2016 18:32:47 -0000

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.