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

["Ben Campbell" <[e-mail]>]

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.