A YANG Data Model for Syslog Configuration
draft-ietf-netmod-syslog-model-32

On the specific question in the Shepherd writeup:
---
Was there anything in WG process that is worth noting? For 
  example, was there controversy about particular points or 
  were there decisions where the consensus was particularly 
  rough?

    Yes, the model initially had defined support for configuring
    Syslog over TPC (RFC 6587).  However, after reviewing the
    reasoning for why RFC 6587 was made HISTORIC, as decided to
    remove the support.  Some stated that their companies support
    Syslog over TCP and now they would have to augment this model
    with a vendor-specific extension.  There may be a subtle
    distinction between IETF defining an insecure protocol versus
    defining a data model to configure, amongst other things, an
    insecure protocol.  We believe we did the right thing, from
    an IETF perspective, but please double-check this.
---

I *personally* would have preferred that Syslog over TCP be included, as it is something which is in use by people, and having a single standard (with notes on why you might not want to use this) is better than an augmented one -- but, if the WG discussed this, then process was followed, and my preference is in the rough...

One quick comment on the model for the console:

            +--rw console! {console-action}?
            |  +--rw facility-filter
            |  |  +--rw facility-list* [facility severity]
            |  |     +--rw facility            union
            |  |     +--rw severity            union
            |  |     +--rw advanced-compare {select-adv-compare}?
            |  |        +--rw compare?   enumeration
            |  |        +--rw action?    enumeration
            |  +--rw pattern-match?     string {select-match}?

Syslog can be (and frequently is) configured to log to "console" on a non-default tty. It's not clear from this model how this would be configured or indicated. Is the assumption here that all non-default-console tty logging would be handled by the "file" portion of the tree? If so, it would be worth indicating so explicitly, and noting that such an approach is limited to those systems that present ttys as a part of the filesystem. Alternately, it might make sense to add a tty field to the "console" subtree to report/configure this value.

Thank you for this document.

I agree with Kathleen that risks of disabling syslog logging in order to hide system compromise needs to be discussed.

I also prefer for TCP to be documented, if used in real world.

Some minor comments:

1) Please add a Normative Reference for the file: URI RFC (RFC 8089) when you mention it for the first time.

2) On page 19:

Example: compare->equals and action->no-match means
messages that have a severity that is not equal to the
specified severity will be logged.";

Do you mean "action->block" instead of "action->no-match"?

3) When logging to file: how is the file name constructed from the name file: URI if multiple files are preserved by the system? E.g. if the log file is rotated daily and 5 last files are preserved, how does each individual filename look? If I understood how this is used, this needs more clarification.

4) Nit: on page 18, typo in "spectify"

https://mozphab-ietf.devsvcdev.mozaws.net/D4614

It's not a problem with this document, but I took a quick look at draft-ietf-netconf-tls-client-server and I've got some concerns. Here are a few examples:

- You can set the cipher suite but not key sizes and groups You can
- say sort of incoherent things in TLS like "I support TLS 1.0 and TLS
 1.2 but not TLS 1.1" (there is no way to negotiate this in TLS 1.2)

I'll try to get a chance to give this a real review, but I wanted to mention it before I forgot.


   We are using definitions of syslog protocol from [RFC5424] in this
   RFC.
Not a big deal, but this introduction feels like it ought to say what the document is about, not just about syslog.



   The severity is one of type syslog-severity, all severities, or none.
   None is a special case that can be used to disable a filter.  When
   filtering severity, the default comparison is that messages of the
This seems to be the first use of the term filter to mean this entity



         subtree, implementations MUST NOT specify a private key that is
         used for any other purpose.
It seems like the data that syslog writes is sensitive, so the ability to write a destination reflects a high degree of risk.

I agree with the SecDir review and thanks for responding to the review.  I have one additional suggestion to make sure the points made from this review are clear to the reader.  Thanks in advance!

SecDir Review text & response:
    Security Comments
    
    * I think almost all writable data nodes here are sensitive, because a network
    attacker's first move is to block any logging on the host, and many of the data
    nodes here can be used for this purpose.

[clw1] I will reword the security section to include all writeable nodes as sensitive.
[KMM]  Thank you, I think it would be helpful to also note the reason is this case with an extra sentence or two.

Something to the effect of:
Logging in particular is used to assess the state of systems and can be used to indicate a network compromise.  If logging were to be disabled through malicious means, attacks may not be readily detectable.

    * Re: readable data nodes, I'm not
    sure which are sensitive, and the document should give an example or two rather
    than just say "some". Otherwise the security advice is not actionable. One
    example: "remote" sections leak information about other hosts in the network.

[clw1] This text was lifted from another model. I will review the readable nodes and update.
[KMM] Thanks

    * Write operations... can have a negative effect on network operations. - I would
    add "and on network security", because logs are often used to detect security
    breaches. 

[clw1] I will add this phrase.

[KMM] I see this was added, thanks.  Please consider the above 2 sentences.

    * Also add an advice, similar to the one on "pattern match", that the
    private key used for signing log messages MUST NOT be used for any other
    purpose, and that the implementation of this data node must ensure this
    property (I'm not sure how). The rationale: if the TLS private key is used, for
    example, this could result in a signing oracle for TLS and eventually a MITM
    attack.

[clw1] I will add this advice.

[KMM] Thanks for adding this advice.