Re: [Syslog] Document shepherd report of AD concerns

[[e-mail]]

>[tom.petch]
> <rant>
> Fundamentally, someone else should be doing this, a policies in 
> security working
> group, perhaps a spinoff from pkix or tls (which I know ekr will reject 
out of
> hand:-).  We are the wrong people, IMO, to be proposing resolutions to 
such
> questions; it should be being done for us by those whose primary role is
> security, not network management.
> </rant>
>

I wasn't part of that group, but I am part of the policy world.  It makes 
sense for the syslog group to jointly with some policy people propose that 
"this is a reasonable risk analysis for the use cases that drive our 
protocol".  The purpose of this risk analysis is the derivation of the 
underlying protocol requirements.  But then, it is just the protocol 
requirements that remain normative.  The risk analysis lives on for 
reviewers, so that they have context, and for future users so that they 
can assess whether their real world implementation risks are significantly 
different.  If the real world is different, it just means that you need to 
re-assess whether syslog-tls will meet your needs, will need some extra 
mitigations, or whatever.  This keeps the policy and risk assessment 
portion non-normative.  So when I review something like this for policy I 
want to see the analysis, but not see it become normative.

Real normative policy work does not belong in SDOs at all.  It belongs in 
legislatures, regulatory groups, and business management.  I've seen far 
too many efforts (past and present) where people attempt to use SDOs to 
bypass the public political process.  They think that making it standard 
lets them bypass the ugly and difficult problems of dealing with the 
parliamentary process.  It doesn't work.  It just means that the standards 
become inconsistent with laws and regulations.  That means that 
implementations become inconsistent.  The SDO policy thought needs to 
reflect instead the consideration "what are the range of potential 
policies that will apply" and make sure that the protocol is able to 
support the bulk of those policies.  The extra from the IESG seems to be 
that there be some reasonable baseline policy that is a reasonable subset 
of the bulk of the policies, and mandate that at least that much be 
supported.

That's where I end up with the basic notion of having the various 
certificate stores, some sort of certificate store management, and 
protocol enforcement of certificate verification.  That leaves a baseline 
mandatory policy assumption that there will be bidirectional certificate 
verification within the protocol.  All the rest of policy becomes the 
rules around certificate stores and store management.  Those don't belong 
in syslog standard beyond the requirement that they exist somehow.  Yes, I 
wish there were more agreement on the policies and the resulting needs for 
stores and store management.  I can see syslog contributing it's use cases 
and examples to those needs.  I don't see it incorporating them into the 
standard, or being the right group to define them.

I would not divorce the policy work completely.  Most of the security 
policy work in SDOs has been dealing with human identity management for 
various authentication and authorization purposes.  That is a very 
different application than syslog.  Those use cases do not map well onto 
the automated machine logging application.

R Horn
_______________________________________________
Syslog mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/syslog