Document: draft-ietf-syslog-sign-27
Reviewer: Ben Campbell	
Review Date: 2009-09-15
IETF LC End Date: 2009-09-17
IESG Telechat date: (if known)

Summary:

This document is almost ready for publication as a draft standard. I found a few minor issues that may need to be considered, and have a few editorial comments

Major issues:

None

Minor issues:

4.2.2, 2nd to last paragraph: "It is up to implementations to ensure that such a reset does not go undetected, for example by requesting operator acknowledgment when a reset is performed upon reboot."

Does this imply a normative requirement?

4.2.3, list element "d": "There has to be some predefined arrangement between the originator and the intended collectors..."

This makes me wonder how you ensure a collector does not receive messages with an SG field of 3 that use some different mechanism than the expected one. Does a "3" mean you have to have a single vendor?  
Some "trusted peer" relationship that only includes signers with the same "3" interpretation?

Even if there's nothing normative here, it's worth a paragraph on the issues of shared proprietary mechanisms when you might someday see messages from arbitrary sources.

-- 5.2.1, a. 5. ("U")

(Same concern as in previous comment on SG field value of 3)

-- 5.2.2, a. "Comparing other forms of HOSTNAMEs is beyond the scope of this specification."

Does this limit a host to a single cert for all signers? Or at least require them all certs from the same host to match all possible signers on that host? Is this acceptable? (Occurs elsewhere in the draft as well.)

-- 6, 1st paragraph: "...when syslog messages are sent over unreliable transport..."

I assume from this it is possible to send syslog over reliable transports. Should there be guidance over whether to send redundant blocks when using reliable transports?

-- Section 7, general:

I don't seem to find any normative language on the verification of signed messages. I don't expect every procedural step to say MUST or SHOULD, but at least a "collector" or "processor" MUST/SHOULD follow these steps:" sort of assertion would be good.

-- Section 8, 2nd paragraph:

If I understand correctly, you need _some_ kind of external verification of the certificate sent by a signer--either via a shared CA, or an explicitly configured trust assertion by the operator. This paragraph seems to obscure that.

-- Section 8.4:

Can you elaborate on how the reviewer detects replay attacks (or reference a section that does so?)


-- Section 9.3, "SG Field"

It would be nice to have a "meaning" column with some comment indicating action meaning, and a separate "defined by" reference column.

-- Section 10, working group mail list:

Is this address sufficiently long-lived to be a contact point in an (assumedly immortal) RFC? (I think there has been some past IESG guidance on this sort of thing, but don't remember what it was.)

Nits/editorial comments:

-- Section 1, paragraph 4, first sentence:

s/use their/uses its

-- Section 3, paragraph 2: "... MUST NOT be changed in transit"  (2
occurrences) 

Not clear what element this applies to--suggest restating in active voice.

-- Section 3, 2nd to last paragraph: "Therefore, the signature and certificate data do not need to include any additional parameter to identify the machine that orginates the message"

Should I read this to mean you are saying a certificate need not have the relevant identity fields filled in? Give than binding an identity to a public key is the most fundamental things certs do, I don't think you meant that--but it's easy to read it that way.

-- Section 3, last paragraph:

Can multiple signers sign the same message? (I think the answer is yes, as I don't see how the mechanism could stop them, but it's worth a mention.)

-- 4.2.3, 4th paragraph: "... as the name might suggest."

Given that the text acknowledges that the SG field name is confusing, is it too late to give it a less confusing name?

-- 4.2.3, list element "a", "Signature Blocks sign..."

s/sign/apply to  (or "contain signatures for...")

-- 4.2.9, paragraph 1: "ld6hg"

I don't see that string anywhere in the example

-- 6.1.1, last paragraph, last sentence:

Suggest "MAY allow" rather than "MAY consider allowing..."

-- section 7, general:

This section uses the form "We do...". I suggest changing "we" to the relevant element or actor. Otherwise there is some risk of obscuring the responsible party for each step.

-- IDNits reports the following:


   Checking nits according to http://www.ietf.org/ID-Checklist.html:
    
----------------------------------------------------------------------------

   ** There are 8 instances of too long lines in the document, the longest one
      being 1 character in excess of 72.


   -- Obsolete informational reference (is this intentional?): RFC 3164
      (Obsoleted by RFC 5424)