Dear Ben, all, thank you for your review. Please see responses, inline, delimited with <ALEX>. Please let me know if those responses adequately resolve the issues, or clarify problems that you feel have not been adequately addressed.
Thank you and kind regards --- Alex -----Original Message----- From: Chris Lonvick (clonvick) Sent: Wednesday, September 16, 2009 12:20 PM To: Alexander Clemm (alex) Cc: David Harrington; Pasi Eronen Subject: Gen-ART LC Review of draft-ietf-syslog-sign-27 (fwd) Hi Alex, These should be taken as WG-LC comments as well. Pasi, do these need to be addressed for the IESG telechat? (Or has that already happened?) Thanks, Chris ---------- Forwarded message ---------- Date: Tue, 15 Sep 2009 17:26:16 -0500 From: To: [email protected], David Harrington <[email protected]>, [email protected], General Area Review Team <[email protected]> Cc: IETF Discussion <[email protected]>, Pasi Eronen <[email protected]> Subject: Gen-ART LC Review of draft-ietf-syslog-sign-27 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? <ALEX> No, this is not a normative requirement - how to deal with this issue will be implementation specific. We discussed this on the mailing list using a printer as an example. The WG consensus was that a printer would likely signal to an operator via a text message on the display, a blinking light, or perhaps by some other means. Since we don't want the printer to not function while waiting for any response from an operator, it's just a suggestion. </ALEX> 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. <ALEX> For the case that a collector does not know about a Signature Group, adding the following additional text: A collector that receives Signature Block messages of a Signature Group of whose scheme it is not aware SHOULD bring this fact to the attention of the system administrator. The particular mechanism used for that is implementation-specific and outside the scope of this specification. For the case that the collector has a different understanding than the sender about a Signature group: It is implied that if SG="3" is used, there needs to be a predefined arrangement. This option is not intended for deployments which lack such an arrangement. Adding the following text: Note that this option is not intended for deployments which lack such an arrangement, as in those cases a collector could misinterpret the intended meaning of the Signature Group. </ALEX> -- 5.2.1, a. 5. ("U") (Same concern as in previous comment on SG field value of 3) <ALEX> It should be clear that this is installation-specific. It is in effect an "escape clause". If non-installation specific key blobs are desired, another value should be chosen. No text change made. </ALEX> -- 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.) <ALEX> It does not limit a host to a single cert for all signers. It merely implies that the certificate must contain the hostname, but it doesn't say that there can be only one certificate for a hostname. Each signer might have its own. In other words, this should be acceptable; no text change made. </ALEX> -- 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? <ALEX> It is up to the implementer to decide if it is needed, therefore a general guidance should not be required. Note that it may make sense to send Blocks redundantly even in the case of a reliable transport, as a collector might be temporarily offline or even a reliable transport connection might be temporarily released. </ALEX> -- 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. <ALEX> Adding the following text at the beginning of section 7: This section outlines a method for online and a method for offline verification of logs which implementations MAY choose to implement to verify logs efficiently. Implementations MAY also choose to implement a different method; it is ultimately up to each implementation how to process the messages that it receives. </ALEX> -- 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. <ALEX> I am not sure a modification is needed - do you have a suggestion of a clarification that you would like to see? </ALEX> -- Section 8.4: Can you elaborate on how the reviewer detects replay attacks (or reference a section that does so?) <ALEX> Adding the following text: Using the methods for verification of logs outlined in Section 7, a replayed message can be detected by checking prior to writing a message to the authenticated log file whether the message is already contained in it. </ALEX> -- 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. <ALEX> Not sure I understand this comment. There is a "meaning" column. The meaning for all is defined in section 4.2.3, nowhere else in this document, hence no separate column is needed. </ALEX> -- 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.) <ALEX> The assumption is yes as it is being rechartered </ALEX> Nits/editorial comments: -- Section 1, paragraph 4, first sentence: s/use their/uses its <ALEX> doublechecked the grammar, plural is correct </ALEX> -- Section 3, paragraph 2: "... MUST NOT be changed in transit" (2 occurrences) Not clear what element this applies to--suggest restating in active voice. <ALEX> The possibility that messages are changed in transit is also discussed in RFC5424 which this document builds on top of. Not sure a change is needed. </ALEX> -- 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. <ALEX> No, this does not talk about the certificate, just the signature and certificate blocks (used to convey the certificate). To clarify, the following change is introduced to pargraph 3: The syslog messages defined in this document carry the data that is associated with Signature Blocks and Certificate Blocks as Structured Data. Then, the following change to paragraph 4: Therefore, the Signature Block and Certificate Block data do not need to include any additional parameter to identify the machine that orginates the message. (The difference between Certificate Block and the certificate itself should be clear. There is no need for the Certificate Block to identify the originator again - that would be redundant.) </ALEX> -- 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.) <ALEX> Yes, the answer is yes. Inserting an additional statement in parantheses: (By the same token, the same message might be signed by multiple signers.) </ALEX> -- 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? <ALEX> Don't intend to give it a different name at this point. </ALEX> -- 4.2.3, list element "a", "Signature Blocks sign..." s/sign/apply to (or "contain signatures for...") <ALEX> OK, changed to "contain signatures for" </ALEX> -- 4.2.9, paragraph 1: "ld6hg" I don't see that string anywhere in the example <ALEX> Thank you, good catch; fixed </ALEX> -- 6.1.1, last paragraph, last sentence: Suggest "MAY allow" rather than "MAY consider allowing..." <ALEX> OK, changed </ALEX> -- 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. <ALEX> "We" refers to the implementation of the verification procedure. This should be pretty clear, leaving the text as is. </ALEX> -- 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. <ALEX> fixed </ALEX> -- Obsolete informational reference (is this intentional?): RFC 3164 (Obsoleted by RFC 5424) <ALEX> The reference to RFC 3164 is used in the context of describing behavior that serves as a "negative example" which is given in RFC 3164; RFC 5424 specifically rules out such behavior. Therefore, to be able to still refer to this as example for negative behavior, the reference to RFC 3164 is still needed.</ALEX> _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
