Subject: [Syslog] clonvick WGLC Review of draft-ietf-syslog-sign-20.txt

From: Chris Lonvick <[email-masked]>
Date: Mon, 18 Dec 2006 10:19:48 -0800 (PST)

Hi,

In the following,
   [14] is syslog-protocol
   [15] is syslog-transport-udp
   [16] is syslog-transport-tls

===

Last paragraph in the Introduction

    This specification is independent of the actual transport protocol
    selected.  The mechanism is especially suitable for use with the
    syslog protocol as defined in RFC xxxx [14] because it utilizes the
    STRUCTURED-DATA elements defined in that document.  It may also be
    used with syslog packets over traditional UDP [4] as described in RFC
    3164 [10].  It may also be used with the Reliable Delivery of syslog
    as described in RFC 3195 [11], and it may be used with other message
    delivery mechanisms.  Designers of other efforts to define event
    notification mechanisms are encouraged to consider this specification
    in their design.

Would it be better to RECOMMEND this mechanism be used with [14]?  That 
would be consistent with the RECOMMENDation in Section 3.

===

Fourth paragraph in Section 3:

    When used in conjunction with RFC xxxx [14], the syslog messages
    defined in this document carry the signature and certificate data as
    STRUCTURED DATA, as defined, while the MSG part of the syslog
    messages is simply empty - the contents of the messages is not
    intended for interpretation by humans but by applications that use
    those messages to build an authenticated log.

Would it be better to state that the MSG part of the message MUST be 
empty?  It's suggested here but not explicitly stated.

===

>From Section 4.1

    A Signature Block message that is compliant with RFC xxxx [14] MUST
    contain valid APP-NAME, PROCID, and MSGID fields.  Specifically, as
    value for APP-NAME, "syslog" (without the double quotes) MUST be
    used.  As value for MSG-ID, "sig" (without the double quotes) MUST be
    used.  As value for the PRI field, 110 MUST be used, corresponding to
    facility 13 and severity 6 (informational).  The Signature Block is
    carried as Structured Data within the Signature Block message, per
    the definitions that follow in the next section.

Perhaps restructure that as:

    A Signature Block message that is compliant with RFC xxxx [14] MUST
    contain valid APP-NAME, PROCID, and MSGID fields.  Specifically, the
    value for APP-NAME MUST be "syslog" (without the double quotes).
    The value for MSG-ID MUST be "sig" (without the double quotes).  The
    value for the PRI field MSUT be 110, corresponding to facility 13
    and severity 6 (informational).  The Signature Block is carried as
    Structured Data within the Signature Block message, per the
    definitions that follow in the next section.

Similar in Section 5.3.1.

===

Section 4.2.7 gives the definition of the syslog message that needs to
be hashed:

    starting with the < of the PRI portion of the header part of the
    message and ending with the Unicode byte order mask, BOM.

That needs to be changed as the BOM is not the end of the message.

===

The count for ssign is a maximum of 2-bytes and is a value of between 1 
and 99.  This will likely fit into a message with a length of 2048 octets 
as stated in Section 4.2.7 if the hashes are 160-bytes.  Is this 
acceptable to the group?  We started this with the idea that this 
mechanism would be run atop RFC 3164 with a maximum length of 1024 octets. 
However, would a greater efficiency be gained by increasing the length of 
the syslog-sign message and the length of the Count?

===

The word "monotonically increasing" is used in a few places.  I think that 
we're actually trying to say "sequentially increasing".

===

The SD-ID values in Section 9 (IANA Considerations) need to be in tables 
so that the IANA can cut-n-paste.

===

Thanks,
Chris

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: "Rainer Gerhards" <[email-masked]>
Date: Mon, 18 Dec 2006 22:15:10 +0100

Hi,

So far, I have not been able to do a full review. But this triggers my
attention immediately... 

> Similar in Section 5.3.1.

Syslog-protocol does not reserve any specific values for APP-NAME,
PROCID and MSGID. So (at least theoretically), another implementor migth
use the suggested values for any other case.

As an implementor, I would probably like to consistenly use the same
APP-NAME. For example, all messages in rsyslog will be logged as
"rsyslogd".

I have just quickly read the IANA section (9.1): there is no such
registry like "APP-NAME". It might eventually be a good idea to create
one, but I am not sure if it is worth the trouble. In any case, I think
that must be spelled out in -protocol (else I can implement somthing
compliant to -protocol but not -sign). Same goes for MSGID.

My recommendation (without a full read of the document...) is to remove
any dependencies on APP-NAME, PROCID and MSGID and use structured data
fields for them. Otherwise, I foresee that I need a lot of hardcoded
exception inside a syslog implementation to "mangle" this fields so that
the happen to be right for -sign while they are invalid from the overall
application point of view.

--

Version field: I recommend renaming it to something like "Sig-Version"
to avoid mistaking -protocol VERSION and -sign Version.

--

I hope I will be able to do a full review by the end of the week.

Rainer

---

From: Chris Lonvick <[email-masked]>
Date: Tue, 19 Dec 2006 13:18:09 -0800 (PST)

Hi Rainer,

> application point of view.

We're going to have "ssign" and "ssign-cert" as the SD-IDs used for 
syslog-sign.  I don't think that there are any dependencies on APP-NAME, 
PROCID and MSGID for the proper working of syslog-sign; they're just there 
to make sure that these messages are placed consistently into the right 
bins.  The "ssign" and "ssign-cert" SD-IDs will be reserved for this.

There are actually two "Version" fields.  The first is an SD-Param called 
"VER" in the SD-ID of ssign.  The second is an SD-Param, also called 
"VER", in ssign-cert.  This type of duplication is acceptable in the rules 
of syslog-protocol.  I can't think of any way that it could be confused 
with the version number in the header of the syslog message.

Looking forward to it.

Thanks,
Chris

---

From: "Rainer Gerhards" <[email-masked]>
Date: Tue, 19 Dec 2006 22:35:56 +0100

Chris,

> -----Original Message-----
> From: Chris Lonvick [mailto:[email-masked]] 
> Sent: Tuesday, December 19, 2006 10:18 PM
> To: Rainer Gerhards
> Cc: [email-masked]
> Subject: RE: [Syslog] clonvick WGLC Review of 
> draft-ietf-syslog-sign-20.txt
> 
> Hi Rainer,
> 
> PROCID and MSGID for the proper working of syslog-sign; 

>From the quoted text above:

>>     value for ####APP-NAME MUST be "syslog"#### (without the double
quotes).
>>     The value for ####MSG-ID MUST be "sig"#### (without the double

If APP-NAME and MSG-ID *MUST* contain something specific, I think there
is a strong dependency.

> they're just there 

I do not see how this addresses the concerns I mentioned above. I can
not implement it without interfering with my application design in a way
that I do not find justified. How does mandating a specific APP-NAME and
MSG-ID make sure that they are put into the right bins? Many stock
syslogds can not even filter on these fields...

Rainer

---

From: Chris Lonvick <[email-masked]>
Date: Wed, 20 Dec 2006 06:36:49 -0800 (PST)

Hi Rainer,

Ahh..  I see your point now.  (Sorry - being a little slow this week.)

All:  I'm tending to agree with Rainer's point that no value should be 
specified for APP-NAME.  Does anyone think that the document should 
suggest something for fixed-function devices such as printers which might 
not have a syslogd?  Currently syslog-protocol allows a NILVALUE if 
nothing better can be used.

Similarly, PROCID may be NIVALUE in syslog-protocol if the device cannot 
produce it.  I'm OK with that for syslog-sign as well.

Finally, I'd still like to keep "sig" for the MSGID.  This should allow 
for parsers (automated and manual searches) to find syslog-sign messages 
quickly.  This won't be the only mechanism to identify a syslog-sign 
message.  I believe that a syslog-sign message would have to:
- be sent to PRI = 110
- have MSGID = "sig"
- contain an SD-ID with the SD-PARAM of "ssign" or "ssign-cert"
I don't think that we need a registry of MSGIDs for this.

If anyone has issues with any of this, please speak up now.  I'd like to 
get this settled so we can update and send this to the IESG when the WGLC 
ends.

Thanks,
Chis

---

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 20 Dec 2006 15:51:25 +0100

Chris,

> Sent: Wednesday, December 20, 2006 3:37 PM
> To: Rainer Gerhards
> Cc: [email-masked]
> Subject: APP-NAME, PROCID and MSGID in syslog sign - was: RE: [Syslog]
> clonvick WGLC Review of draft-ietf-syslog-sign-20.txt
> 
> Hi Rainer,
> 

I think they should use whatever the use with other messages. For
example, they might use "router". Sure, this is not intelligent. But my
point is that this should not be of concern for syslog-sign.

> quickly.  

I do not object it, as long as we caution implementors that a MSGID of
"sig" does not necessarily indicate this is a syslog-sign message. We
can not guarantee that, because we did not reserve any message ids at
all. So it may be a clue, but it is nothing to rely on. Which brings me
to the point: what is the advantage of an unreliable indicator?

>This won't be the only mechanism to identify a syslog-sign

For me, the SD-ID is the only valid indicator that this is a syslog-sign
message. We can not rely on PRI as operators like to reconfigure PRI.
Even if we mandate a fixed PRI in the specification, real-world
implementations will ignore that requirement and still allow the
operator to override it (and this for a good reason). On the other hand,
SD-IDs *are* under IANA control and the absolutely positively identify
the element that they are contained in. This is what we designed them
for. So why not use them for their design purpose?

With RFC 3164 syslog, we obviously can not totally be assured that the
SD-ID will be valid. But we should keep in mind that we most probably
will try to obsolete 3164 either via -protocol or a follow-up RFC. I
already questioned the point in supporting this (informational!)
document in a new standard. Is this really a wise idea?

Rainer

---

From: "tom.petch" <[email-masked]>
Date: Thu, 28 Dec 2006 12:39:37 +0100

I think that there are a number of places where the language is not quite
English and could do with editing. There are also several places where I am
unclear about the meaning.  Taking the more significant ones and trying not to
overlap with previous comments

It would be easier for the RFC Editor (and me) if the three references were to
proposed RFC were to xxxx, yyyy, zzzz as opposed to all being xxxx

3 'it is imperative .. ' seem unnecessary when it is followed by 'MUST NOT'

'Signature Group' seems as much a special term as Signature Block or Certificate
Block and so should be capitalised.

I find the mix of byte, decimal and character confusing.  As already commented,
I think octet should replace byte and, in most places, character.  For me,
saying a field is decimal is imprecise; I would like you to specify that in ABNF
as Rainer does.  Also, I you should give guidance on leading zeroes (omit
them!).

4.2.2 "between 0 and 9999999999"  I assume that this is an inclusive range, ie 0
and 9999999999 are valid values.

"If the value  latches at 9999999999"
I am unclear about this and other uses of 'latches'.  I expect a specification
to say whether or not a value latches at its maximum value (and so needs to be
reset by special action eg manual intervention).  Saying 'if it latches'
confuses me; is this at the choice of the implementor?.

4.2.3 "how to divide up the processing //of/ syslog messages "

"The ability to /to// associate"

"with flexibility /to/in/ that regard."

4.2.4
"In the case in which the reboot session ID is in fact 0 and persisting of
   reboot session IDs is not supported, when the global block counter
   latches, it resumes at 0 also in this case but the reboot session ID
   MUST NOT be incremented and remains at 0."

I struggle to parse this.  Is it more like

 "When the reboot session ID is 0 ( ie persistent reboot session IDs are not
supported) and the global block counter reaches its maximum value, then the
global block counter is reset to 0 and the reboot session ID MUST remain at 0."

4.2.7
How is the message padded?

5.2
"each reboot session has only one Payload Block"
I get confused in this section; my sense is, and I struggle for the right
wording, that the contents of the Payload Block are fixed for a reboot session
(regardless of whether or not persistent session IDs are supported) but that the
Payload Block may appear as many times as the sender thinks fit.

5.3
"refe/re//rred to as a Certificate Block"

Should a Certificate Block have a minimum length?  is it valid to send a large
number of such blocks with zero length (DOS attack)?

6
I would like to see suggested values for this customisation.

Given the number of comments from Chris and Rainer, I would like to see a
reissue and the chance to read it again before this goes to the IESG.

Tom Petch