Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

[Juergen Schoenwaelder <[e-mail]>]

On Fri, Aug 19, 2016 at 12:55:53PM -0400, Susan Hares wrote:
> Andy: 
> 
>  
> 
> The easy of reviewing per leaf – is why I suggested the per leaf.  
> 
> I also agree it is important to mention this non-secure/secure requirement to the PUSH work team we are both on. 
> 
>  
> 
> Should I change: 
> 
> Old: /
> 
>    A non-secure transport can be used for publishing telemetry data or
> 
>    other operational state that was specifically indicated to non-
> 
>    confidential in the data model in the Yang syntax. /
> 
> New: 
> 
> /   A non-secure transport can be used for publishing telemetry data or
> 
>    other operational state that was specifically indicated to non-
> 
>    confidential in the data model. /
>

Tagging something in the data model as 'non-confidential' remains a
flawed idea. What can be considered 'non-confidential' depends on the
deployment scenario. It is even worse to standardize some piece of
information as 'non-confidential'. How can the IETF claim that
something is always 'non-confidential'? (And note, a non-secure
transport is not just about confidentiality, it also implies that
boxes on the path can arbitrarily change the information.)

In case this is not clear: What we have done for ~30 years is to have
the decision which information goes into an insecure transport be
taken by an access control model. This makes the decision runtime
configurable and thus things can be deployment specific. This has
worked for 30 years and I have no problem with this. What I am
struggling with is the idea to standardize parts of YANG data models
as 'non-confidential'.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>