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)
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf