Subject: [Gen-art] Gen-ART LC Review of draft-ietf-syslog-sign-27

From: Ben Campbell <[email-masked]>
Date: Tue, 15 Sep 2009 17:26:16 -0500

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

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)